Cisco Cisco IOS Software Release 12.0(23)S
MPLS Traffic Engineering (TE)—Link and Node Protection, with RSVP Hellos Support
Bandwidth Protection Considerations
87
Cisco IOS Release 12.0(23)S
Note
Only one pool can be selected (that is, the backup tunnel can explicitly reserve bandwidth from either
the global pool or the sub-pool, but not both).
the global pool or the sub-pool, but not both).
The mpls traffic-eng backup-bw command allows you to specify the bandwidth pool to which the
traffic must belong for the traffic to use this backup tunnel. Multiple pools are allowed.
traffic must belong for the traffic to use this backup tunnel. Multiple pools are allowed.
There is no direct correspondence between the bandwidth pool that is protected and the bandwidth pool
from which the bandwidth of the backup tunnel draws its bandwidth.
from which the bandwidth of the backup tunnel draws its bandwidth.
Example: In this example, assume the following:
•
Bandwidth protection is desired only for sub-pool traffic, but the best-effort traffic using the global
pool does not require bandwidth protection.
pool does not require bandwidth protection.
•
Scheduling is configured so that sub-pool traffic uses the priority queue, and global pool traffic is
served at a lower priority.
served at a lower priority.
Bandwidth protection for 10 Kbps of sub-pool traffic on a given link can be achieved by any of the
following combinations:
following combinations:
•
tunnel mpls traffic-eng bandwidth sub-pool 10
tunnel mpls traffic-eng backup-bw sub-pool 10
•
tunnel mpls traffic-eng bandwidth global-pool 10
tunnel mpls traffic-eng backup-bw sub-pool 10 global-pool unlimited
•
tunnel mpls traffic-eng bandwidth global-pool 40
tunnel mpls traffic-eng backup-bw sub-pool 10 global-pool 30
Using Backup Tunnels Signaled with Zero Bandwidth
Frequently is desirable to use backup tunnels with zero signaled bandwidth, even when bandwidth
protection is required. It may seem that if no bandwidth is explicitly reserved, no bandwidth guarantees
can be provided. However, that is not necessarily true.
protection is required. It may seem that if no bandwidth is explicitly reserved, no bandwidth guarantees
can be provided. However, that is not necessarily true.
In the following situation:
•
Only link protection is desired
•
Bandwidth protection is desired only for sub-pool traffic
For each protected link AB with a max reservable sub-pool value of S, there may be a path from node A
to node B such that the difference between max reservable global and max reservable sub-pool is at least
S. If it is possible to find such paths for each link in the network, you can establish all the backup tunnels
along such paths without any bandwidth reservations. If there is a single link failure, only one backup
tunnel will use any link on its path. Since that path has at least S of available bandwidth (in the global
pool), assuming that marking and scheduling is configured to classify the sub-pool traffic into a priority
queue, the sub-pool bandwidth is guaranteed.
to node B such that the difference between max reservable global and max reservable sub-pool is at least
S. If it is possible to find such paths for each link in the network, you can establish all the backup tunnels
along such paths without any bandwidth reservations. If there is a single link failure, only one backup
tunnel will use any link on its path. Since that path has at least S of available bandwidth (in the global
pool), assuming that marking and scheduling is configured to classify the sub-pool traffic into a priority
queue, the sub-pool bandwidth is guaranteed.
The above approach allows sharing of the global pool bandwidth between backup tunnels protecting
independent link failures. The backup tunnels are expected to be used for only a short period of time
after a failure (until the head-ends of affected LSPs reroute those LSPs to other paths with available
sub-pool bandwidth). The probability of multiple unrelated link failures is very small (in the absence of
node or SRLG failures, which result in multiple link failures). Therefore, it is reasonable to assume that
independent link failures. The backup tunnels are expected to be used for only a short period of time
after a failure (until the head-ends of affected LSPs reroute those LSPs to other paths with available
sub-pool bandwidth). The probability of multiple unrelated link failures is very small (in the absence of
node or SRLG failures, which result in multiple link failures). Therefore, it is reasonable to assume that