MPLS TE QoS (DS-TE)

Up until this point, QoS for MPLS has essentially been the same as QoS for IP, except marking and classification is only based on the EXP field.

DiffServ-aware TE (DS-TE) is the process of setting up LSPs based on traffic class bandwidth requirements instead of a single bandwidth value (as in normal MPLS-TE).

To understand the need for DS-TE we need to look at what might happen without DS-TE. Examine the diagram below:

A customer has ordered an L3VPN service for 20mb total bandwidth and pays for 5mbps guaranteed LLQ for voice traffic, as long as they mark their voice traffic with EF. In the MPLS core, all links are 100mb, and all interfaces have a 8mbps LLQ for voice traffic. Remember that LLQ implements a policer, so any voice traffic above 8mbps is dropped to prevent voice traffic from starving out other queues.

For this example we will focus only on traffic going in the direction from CE1 —> CE2, which is R1 —> R5.

Let’s imagine that MPLS-TE is in use, and R1 creates an LSP to R5 which requires a 20mb bandwidth reservation. This follows the IGP shortest path R1-R2-R5 by default.

Sometime later, a second L3VPN service is added with R1 and R5 as the PEs. This customer pays for 30mbps total bandwidth and 5mbps guaranteed LLQ for voice traffic. R1 setups up another LSP to R5. This one requires 30mb bandwidth. The problem is that this follows the same path as before:

Remember that all interfaces only have 8mbps for the LLQ. If both customers try to send voice traffic at 5mbps at the same time, they will start to be policed!

This is the shortcoming of regular TE. With DS-TE, we can create additional “sub pools” of bandwidth available for reservation. So all interfaces in this example could have a max bandwidth reservation of 100mb, and a max sub-pool reservation of 8mb.

This time when R1 sets up the two TE tunnels, each LSP requires 5mbps of sub-pool bandwidth. The first path is signalled via R1-R2-R5. Now only 3mbps is left for the sub-pools of the interfaces on R2. The second path, when signalled with the requirement of 5mpbs sub-pool bandwidth, takes the path R1-R3-R4-R5, because the path R1-R2-R5 cannot meet the sub-pool bandwidth constraint.

In this simplistic example, we have now solved the issue we had before where both LSPs used a path that could not gaurantee a combined total of 10mbps LLQ for voice traffic. This is the basic premise behind DS-TE.

Class Types

Having only a single subpool in addition to the main overall bandwidth is somewhat limiting. The concept of class types adds support to RSVP for up to 8 different class types for the purpose of bandwidth allocation. By using up to 8 class types, you can roughly correspond each class type to an EXP value or IPP value. (Although it is not required to set it up like that).

Just like bandwidth and the sub-pool, bandwidth reservation per class type is a control plane mechanism only. Reserving bandwidth on an interface, sub-pool, per class type does not do anything to the data plane. It is used to prevent too many traffic flows from using certain paths and to gaurantee that traffic flows will have enough bandwidth. Class Types allows you to extend this bandwidth gaurantee on a more granular level for the purpose of gauranteeing bandwidth for DiffServ.

Class Types also support priority values. Each TE-Class is a combination of a class type (CT0-CT7) and a corresponding preemption priority value (0-7). Although this would allow a maximum of 64 combinations (one CT can have up to eight priority values), RSVP only supports a maximum of eight TE classes. On each device you will want to make sure you have the same correspondance of TE class to CT and priority. This is an example of a TE-Class setup you could use:

TE-Class	CT	Priority
0	0	7
1	0	6
2	1	7
3	1	6
4	2	5
5	3	4
6	4	3
7	5	2

When defining TE tunnels that require a bandwidth reservation, it is made per CT. There are two main bandwidth allocation models which we will look at next: MAM and RDM.

One note before moving on: IOS only allows you to use two class-types: CT0 and CT1. CT0 is the default “global” bandwidth pool of an interfaces. So while the RFC specifies support for up to eight classes, just be aware of this when implementing DS-TE on IOS. DS-TE on IOS essentially behaves as the very first example we looked at where there was a global bandwidth value and a single sub-pool bandwidth allocation.

Bandwidth Constraint Models

MAM (Maximum Allocation Model)

Each class gets its own reserved bandwidth. No other classes can encroach on other classes’ reserved bandwidth, even if it is not in use.

Here, voice gets 30% bandwidth always. If it is only currently using 10%, then 20% bandwidth is wasted and unused.

BC refers to Bandwidth Constraint, and is used to define the way bandwidth is allocated to each CT. In MAM, each BC directly corresponds with the CT as following:

Bandwidth Constraint

Class-Type

BC7

CT7

BC6

CT6

BC5

CT5

BC4

CT4

BC3

CT3

BC2

CT2

BC1

CT1

BC0

CT0

CT0 is really the total maximum reservable bandwidth minus the sum of CT1-CT7 bandwidths. CT0 is what is “left over” after all other bandwidths have been reserved.

As you can see, each BC is completely separate from another. This is why CTs cannot encroach on the bandwidth reservation of other CTs in MAM.

RDM (Russian Dolls Model)

In RDM, bandwidth pools apply to one or multiple classes. This way, if a single class is not using much bandwidth, other classes can use that unused bandwidth.

Here, voice gets 30% as before. However, BC1 is premium plus voice. If voice is using only 10%, now premium can use up to 40%. The unused bandwidth by voice does not go wasted.

In RDM, a BC refers to the sum of all CTs at that level and higher:

Bandwidth Constraint

Class-Type

BC7

CT7

BC6

CT7 + CT6

BC5

CT7 + CT6 + CT5

BC4

CT7 + CT6 + CT5 + CT4

BC3

CT7 + CT6 + CT5 + CT4 + CT3

BC2

CT7 + CT6 + CT5 + CT4 + CT3 + CT2

BC1

CT7 + CT6 + CT5 + CT4 + CT3 + CT2 + CT1

BC0

CT7 + CT6 + CT5 + CT4 + CT3 + CT2 + CT1 + CT0

CT0 is the default bandwidth allocation. The default class type can use up any bandwidth of “higher” class types if they are not in use. However, each higher class type has its own amount of reserved bandwidth.

In RDM, CT0 can use up to 100% of the maximum reservable bandwidth. In MAM, CT0 can only use up (mamximum reservable bandwidth) - (sum of all class type reservations).

In IOS you can specify the bandwidth constraint model using the following command:

Router(config)#mpls traffic-eng ds-te bc-model ?
  mam  BC Maximum allocation model
  rdm  BC Russian doll model

Test Your Understanding

Scenario 1

Link costs are all the same. TE metric is based on IGP cost.
All interfaces have a CT0 bandwidth of 100Mbps and CT1 bandwidth of 10Mbps allocated.
No existing LSPs are present.

An LSP is setup requiring 70Mbps of CT0 bandwidth. It takes the path R1-R2-R5.

Another LSP is setup requiring 25Mbps of CT0 bandwidth. It is setup using the path R1-R3-R4-R5.

Question: What model is in use?

Answer: MAM (Maximum Allocation Model). The second LSP could not be setup on the T1-R2-R5 path, so we can deduce that the CT1 bandwidth could not be encroached. Only 20Mbps was left for CT0 on the top path. If RDM (Russian Doll Model) was used, the LSP would have been setup on the top path because the CT1 bandwidth is not being utilized right now.

The (Unofficial) CCNP-SP Study Guide