IETF DS-TE with MAM
Last updated
Last updated
Load mpls.te.base.config.with.ospf.cfg
Configure DS-TE in IETF mode so that the interfaces along the two bidirectional paths, CSR8-CSR6-XR12-XR11 and CSR8-CSR9-CSR10-XR11, have 100M BC0 bandwidth available and 10M BC1 bandwidth available, with 110M total bandwidth.
Configure three bidirectional TE tunnels between R8 and XR11 as follows:
One which requests 8M BC1 bandwidth at priority 0
One which requests 8M BC1 bandwidth at priority 7
One which requests 95M BC0 bandwidth at priority 7
The IETF standardized DS-TE in 2008, after Cisco’s traditional DS-TE had already existed. The traditional DS-TE mode only supports two pools: a global pool and a sub-pool. The IETF mode adds support for more pools but with some additional complexity.
In the IETF mode, there are 8 class types (CT). Each CT corresponds to a BC (bandwidth constraint). So CT0=BC0, CT1=BC1, CT2=BC2, etc. The bandwidth constraint is the pool of bandwidth for the traffic class. Cisco only supports CT0 and CT1. CT0 maps to the global pool and CT1 maps to the sub pool in the IGP advertisement.
We must specify on all routers that they are using the IETF mode of DS-TE instead of the default “traditional” mode.
There is another layer of complexity: TE classes. A TE class is a CT and a priority value. For example, TE class 3 might be CT0 with priorty 5. There are 64 possible combinations of TE classes (8 CTs and 8 priority levels), but only up to 8 at a time can be defined in a network. Each router in the network must agree on the meaning of each TE class (through configuration). This allows the IGP to re-use what was previously the 8 priority levels of global bandwidth, as TE classes.
By default, IOS-XE and IOS-XR use the following TE classes. In this lab, we leave the defaults as they are. Note that you can change this by entering the mpls traffic-eng ds-te te-classes configuration mode (on either IOS-XE or IOS-XR).
TE-Class
CT
Priority
0
0
7
1
1
7
4
0
0
5
1
0
TE-Class 0 means CT0 with priority level 7. (Etc. for the other TE classes).
RSVP now carries a new object called CLASSTYPE. This is used in the PATH message to define which TE class the LSP is requesting bandwidth from. Note that when CT0 is used, there is no CLASSTYPE object, for backwards compatibility. The CLASSTYPE object, together with the LSP priority, define what TE class the bandwidth will be reserved from. (The TE class is not explicitly signalled in the PATH message, which is why all routers must agree on the TE class definitions).
Finally (if this was not confusing enough!), we have two bandwidth allocation models. First is MAM (Maximum Allocation Model), which we are configuring in this lab. In this model, each CT has its own independent bandwidth allocation (bandwidth constraint). Because we are only using CT0 and CT1 in Cisco, this is a bit easier to comprehend. CT0 cannot use any of CT1’s bandwidth. BC0=CT0 and BC1=CT1. This provides protection to CT1.
In the RDM (Russian Dolls Model), CT0 is allowed to use unused CT1 bandwidth. So BC0=CT0+CT1 and BC1=CT1. This provides better use of bandwidth, but at the possibility of CT1 not finding a path unless its LSP priority is low enough to preempt a CT0 and “take back” its CT1 bandwidth.
We must define the same model on all routers in our network as well. Both IOS-XE and IOS-XR use RDM by default. However, IOS-XR does not explicitly let you configure RDM as the bc-model, since it is the default. So if you want to change to MAM, then you specify the command below.
Finally, we must change the RSVP bandwidth on an interface to use the MAM model:
The TE tunnel defines the TE class by the combination of the tunnel prioirty and the signalled-bandwidth. For example, this tunnel would use TE class 4 (CT0 and priority 0).
If you use a priorty and CT pair that is not already defined as a TE class, the tunnel will fail to establish, because the path is invalid. Additionally, it appears that both the setup and the hold priority have to be valid priority levels that have a corresponding TE class. So by default, you can mismatch setup/hold but only if they are both either 7 or 0. The hold priority is used for the reservation.
Just like with regular MPLS-TE, bandwidth reserved from a higher priority takes away available bandwidth from the lower priority. This happens no matter which model is used. So within CT0, a priority 0 LSP removes available bandwidth from CT0 priority 7.
However, when using MAM, CT1 traffic allocation does not remove available bandwidth from CT0. In MAM, CT0 and CT1 have completely separate available bandwidth pools.
Before configuring any TE tunnels, notice that the TED looks different now. There are 8 TE classes instead of priority levels.
Why do the BC0 and BC1 values appear twice at class 0/1 and class 4/5? This is due to the default TE class definition. We can see this using the following show command. TE-Class 0 and TE-Class 1 use priority 7, while TE-Class 4 and TE-Class 5 use priority 0.
Let’s now setup the first TE tunnel from R8 to XR11.
In the PATH message we see that the class-type is 1. This means the bandwidth allocation is from BC1. This is needed, because the priorty and bandwidth level are not enough to determine whether CT0 or CT1 is used. Note that when CT0 is used, this CLASSTYPE object is missing, which provides backwards compatibility for the CT0 class with other RSVP routers not running IETF mode.
Using the command show mpls traffic-eng link-management advertisements, we can see the current IGP advertisement for local TE information. Notice that R8 has removed 8M of available bandwidth for CT1 from both priority levels 0 and 7. Since this first LSP has a priority of 0, it removes available bandwidth from level 7 as well.
We’ll setup the next TE tunnel, which also requests 8M of BC1 bandwidth. This will have to go over a completely separate path compared to the previous tunnel.
We can see that 8M was only removed from priority level 7 on CSR8 this time. This should be intuitive, as it is no different than normal MPLS-TE behavior, in which a reservation at a given priority level removes available bandwidth at all priority levels above it. The difference is that you need to know what priority level is used by which TE class.
Next we setup the third tunnel which requests 95M of BC0 bandwidth. We will have 100M of BC0 on all links, so there are multiple candidate paths for R8 to choose from.
Configuration of the TE tunnels on XR11 is essentially the same, and works the same way. Once all three are setup, we can verify that tun0 and tun1 take a different path, and that available bandwidth is similar to what we saw on R8.
All tunnels are up:
Tun0 and Tun1 use a different path:
Link ID 0 on XR11 has 8M subtracted from CT1 priority level 7 (TE Class 1). This is used by tunnel 1.
Link ID 1 on XR11 has 8M subtracted from TE Class 5, which also subtracts from TE Class 1, due to tunnel 0 using priority 0. It also has 95M subtracted from TE-class 0 due to tunnel 2 which uses priority 7.
Let’s remove all TE tunnels on XR11 and only configure RSVP bandwidth on a single interface.
Gi0/0/0/0.501 now has 5M max reservable, 4M BC0 available, and 3M BC1 available.
We’ll configure a 3M TE tunnel using BC1 priority 0.
As expected, the setup is successful, and 3M is subtracted from available BC1 bandwidth at both priority levels. However, notice that the BC0 available bandwidth at each priority level is now only 2M. This is because 5M-3M used up by BC1 leaves only 2M available for BC0.
The same thing happens if we change the tunnel to use class-type 0 bandwidth instead.
Only 2M is available on the link now. So either BC1 can use up this 2M, or BC0 can still use up 1M. (BC0 had 4M available and 3M used now).
If you look at the TED, this actually counts as 1M allocated towards TE class 1 and 5.
If you try to setup a second TE tunnel that requests 3M from CT1, it will fail to setup.
In MAM with oversubscription, CT1 cannot “take back” bandwidth from CT0. For this reason, you would likely not see this scenario with MAM, where max BW is less than BC0+BC1. The whole point of MAM is that CT0 and CT1 bandwidth is competely separate from each other. So typically Max BW = BC0 + BC1.
Interestingly, this “oversubscription” is what happens with RDM. BC0 is the combination of available bandwidth for CT0 and CT1, so essentially BC0 is the max bandwidth on the interface. This allows BC0 to borrow from BC1.
In MAM:
Max BW = BC0 + BC1 (typically)
In RDM:
Max BW = BC0
This allows BC0 to borrow from BC1
You cannot define the max BW in RDM, instead it is simply the BC0 value.
