The last article I wrote discussed the need to consider the provider's Quality of Service (QoS) architecture when determining the framework of your QoS architecture. In this article I will discuss the MPLS experimental bits.
MPLS experimental bits are used to provide QoS capabilities by utilizing the bits set in the MPLS labels. To briefly review QoS, remember that IP traffic can be classified and marked with IP Precedence or DSCP bits. The router can then be configured to give prioritization of one traffic type over another based on the assigned markings. The MPLS experimental bits provide a mechanism for marking MPLS traffic with the bits contained in the labels that are assigned. Remember MPLS is a label switching protocol. By classifying and marking with the experimental bits found in the label, the routers can infer QoS utilizing the EXP bits in the MPLS label. This is required as the MPLS label switch routers do not examine the IP header during the forwarding process during label switching.
The MPLS EXP bits are found in the MPLS shim header. The MPLS shim header is the header that is placed in packets that carry label information. The MPLS shim header is defined in RFC 3032. Don't let the name experimental bits confuse you. When RFC 3032 was originally developed, 3 bits were reserved for experimental purposes. The bits reserved are 0, 1, and 2. This can provide 8 different classifications of traffic and coincidentally maps to IP precedence or Layer 2 COS bits.
MPLS label switch routers can provide QoS in 2 different ways. The LSR can infer the QoS treatment by the EXP bits only or by the EXP bits and the packet label. The first mechanism is referred to as E-LSP and the second is the L-LSP.
The E-LSP allows for multiple classes of service per LSP and the L-LSP allows for defining a QoS policy per LSP. The two methods align with the different QoS models Diffserv and IntServ. Diffserv provides per hop behavior based on the markings while Inserv provides a signaling protocol (RSVP) to set up the parameters before transmission. In the Intserv model (L-LSP), the class association is signaled with RSVP during LSP establishment and the LSR uses the label to infer packet classification. The main differential between the two is that with E-LSP you can only have 8 classes of traffic (only uses 3 EXP bits), with the L-LSP you can have many more classes of traffic due to the combination of EXP bits and labels. The E-LSP model is limited to the 8 classes and even less if you want to infer a drop precedence for traffic within a class. Most service providers are deploying 3-4 classes of service, therefore the E-LSP method is most widely deployed.
So how do you map EXP bits to DSCP and IP precedence bits? As with all QoS implementations this is set by the end user. The priority given to a particular class of traffic is totally dependent on how you configure the router. You can give traffic marked with a zero (best effort), the highest priority if you wish by placing this traffic in the high priority queue. This is not recommended as you will want to conform to industry standards. Below is a sample mapping that shows EXP mappings to DSCP mappings1.
Class DSCP EXP
Reserved for control plane traffic Class Selector 7 7
Reserved for control plane traffic Class Selector 6 6
Class 1 (real-time traffic) EF 5
Class 2 in-profile AF31 4
Class 2 out-of-profile AF32, AF33 3
Class 3 in-profile AF11 2
Class 3 out-of-profile AF12, AF13 1
Class 4 (best effort) Default 0
As can be seen from the table, the mappings are pretty straightforward.
This article provides an overview of MPLS EXP bits and their association with IP Precedence and DSCP. Once you understand the usage of the EXP bits it is a matter of configuring the LSR to deliver the desired QoS. The next technical tip will discuss some of the configurations for MPLS EXP bits on Cisco routers.
1 Courtesy Cisco Systems – Quality of Service For MPLS Networks
Robbie Harrell (CCIE#3873) is the National Practice Lead for Advanced Infrastructure Solutions for SBC Communications. He has over 10 years of experience providing strategic, business, and technical consulting services to clients. Robbie resides in Atlanta, and is a graduate of Clemson University. His background includes positions as a Principal Architect at International Network Services, Lucent, Frontway and Callisma.
