MPLS TE traditionally avoids QoS class types however, MPLS DiffServe TE (DS-TE) brings that capability. This can be useful for QoS guarnatees such as voice. This enables sensitive traffic to be traffic engineered at a per-class level instead of on a global level. Differentiated Service classes can be mapped to a discting LSP to enable traffic and business requirements.
DiffServ-TE, created as RFC 3564 and has many functionalities, firstly it has the concept of Class Types (CT) where a DS-TE protocol must be able to keep track of available bandwidths for each class of traffic using CTs. A given DS-TE tunnel can belong to the same CT on all links, where the CT ranges from CT0 - CT7 having 8 total values. DS-TE LSP carries traffic from only a single CT, and if a network supports both voice and data seperate queues can be created and mapped to different LSPs. Naturally CSPF is used with DS-TE to create paths that include computation such as bandwidth and link attributes. DS-TE adds available bandwidth at each CT as a constraint that can be applied to a path. Ideally the IGP would carry bandwidth information of 8 CTs at 8 priority levels being 64 values per link LSA. RSVP-TE uses 8 priority levels to determine which LSPs get bandwidth first when requesting a new LSP. When CT is used, bandwidth is specified within sub-TLVs per CT class. So now for instance, CT0 for Best Effort could have a bandwidth pool of 500mbps where as CT2 could have one for 200 Mbps, then the priority values are used to determine which LSPs have an allotment based on the pool bandwidth resource. The combination of a CT value and Priority value create a TE class which has 8 different classes TE0 - TE7 which are chosen from 64 different CT priority combinations. The IGP carries the TE class information in the Unreserved Bandwidth sub-TLV which is present in the Link Information of the TLV LSA. CSPF then uses this information (bandwidth, link attributes) to create user-constraints to generate a path and once the path is setup, RSVP is used to signal it. RFC 4124 defines a new RSVP object for carrying the CT information called CLASSTYPE. This is carried within RESVP path message and has a range of 1-7 where 0 is the global tunnel. If the LSP is established for a CT value of 0, the CLASSTYPE object is not carried in the path message thus allowing for backwards compatibility. Each LSR along the path records the CLASSTYPE object and when establishing the LSP for a CT the LSR performs admission control considering the bandwidth available for the CT. If an LSR doesn’t support DS-TE extension for RSVP, the path is not established. Admission control is a process that happens during RSVP RESV and PATH phases where each LSR decides whether it can accept a new LSP request based on available bandwidth and constraints. The percentage of links the bandwidth takes up is called Bandwidth Constraining (BC). There are a few models that determine how this works, specifying the maximum number of BCs, which CTs each BC applies and how, and whether a CT can be applied to either a BC or a set of BCs. Some common methods are Maximum Allocation Model (MAM) and Russian Dolls Model (RDM). The MAM architecture is one that maps a BC to CT one to one, and doesn’t permit CTs from other classes to use reserved BCs. This means that if a CT has extra BC it’s not using, it goes to waste, which isn’t very efficient. RDM on the other hand allows for sharing of BCs between CTs, where CT5-7 for instance could share BC3. It also allows for reserving of BC for only one CT like MAM does which could be useful for priority traffic.
DS-TE/MAM/RDM all define how to set up the TE tunnel and bandwidth is allocated but not how packets should be mapped in the case of multiple LSPs. RFC 3270 proposes two different methods to ensure different CTs get the correct scheduling and QoS treatment when choosing between LSPs. EXP-inferred LSP (E-LSP) uses the EXP bits of the MPLS header and each LSR along the path interprets them to determine the PHB. However since there are only 3 MPLS EXP bits, only 8 different PHBs are possible. This enables both queuing treatment and drop precendence to be conveyed via the EXP bits. LSP-inferred LSP (L-LSP) uses the label itself to determine the queuing and scheduling behavior. It uses the EXP bits for drop precedence not queuing, thus alowing for more than 8 PHBs. Both E-LSP and L-LSP are an attempt to map the DSCP bits from IP packets onto the label, the AF and drop precedence both need to be mapped, and since the EXP is limited to 3 bits some loss occurs. The direct mapping approach, E-LSP fails to capture some of the data from DSCP, but in L-LSP this is mitigated by the drop precedence being stored in the EXP bits and the assured forwarding in the label itself.
There are three different DS-TE modes which define how routers communicate DS-TE information across the network. The Prestandard mode is considered legacy and only supports RDM and not RSVP-TE extension for DS-TE. The Migration Mode is used to upgrade the IETF to standard DS-TE. Routers still signal DS-TE using prestandard but also advertise TE-class mapping and accept IETF-standard DS-TE advertisements from other routers. The fully compliant Liberal IETF Mode generates IGP advertisements for RSVP-TE signalling, is backwards compatiable and supports both MAM and RDM. The RSVP-TE extensions for DS-TE invovles support for CTs and TE classes to be shared. This enables differentiation between different classes. Without RSVP-TE extensions, RDM CTs must be manually configured by the network engineer, but it’s still advertised via IGP. With Liberal IETF mode, these capabilities are automatically signaled and configured by the router.
Class-Based Tunnel Selection (CBTS) is a way to load balance between multiple tunnels created from headend to tailend. There is one master tunnel created for multiple member tunnels with the same destination, this set of tunnels is called a bundle. This doesn’t inherently solve routing, a static route or autoroute announce is still required for connectivity. So when the headend router receives a packet, the CBTS decides which tunnel member to send the packet out of baed on the DiffServe mechanisms configured using the EXP bits of the MPLS header.
Lastly Policy-Based Tunnel selection (PBTS) allows tunnels to be selected based on pre-defined criteria in a policy. This is used in XR heavily, where markings/classification can be done using class maps, and rules can be created for each one. For different TE tunnels the route-policy configured can select a different TE tunnel i.e one for voice and a separate one for BE traffic. A TE interface can be associated with a FEC which then gets exported to the routing protocol and associated with a FIB entry. When the packet is matched, the TE process passes the packet to the LSd process as part of the label rewrite for the tunnel head. PBTS supports up to 8 forwad classes and 8 tunnels within each forward class, to a maximum of 32 tunnels per route. Forward class configurations do not apply to FRR backup tunnels that will be ignored.