Configuring MPLS experimental bits

How to configure QoS using experimental bits.

This article will discuss the mechanisms and commands for configuring MPLS experimental bits on a Cisco router.

As I had discussed two articles ago, EXP bits are the bits set in an MPLS label that are used to infer the Class of Service for that particular traffic.

There are only 3 EXP bits therefore the MPLS label can only support 8 classifications of traffic. The breakdown of bits is shown below:

000 – 0
001 – 1
010 – 2
011 – 3
100 – 4
101 – 5
110 – 6
111 – 7

The EXP bits correspond directly to the IP precedence bits as both mechanisms utilize 3 bits. It makes sense to map MPLS EXP to IP precedence when developing a QoS architecture. Once the MPLS EXP bits are aligned with the IP precedence, DSCP classifications can be mapped. Below is an example of MPLS EXP bits mapped to DSCP.

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

So now that there is a clear understanding of the mappings of MPLS to IP precedence and DSCP, how do you configure the MPLS routers to enable QoS? MPLS enabled routers support the following:

  • Packet Classification via committed access rate using the ToS bits in the IP header
  • Congestion Management
  • Congestion Avoidance

The configuration of the MPLS QoS can vary from IOS to IOS but in general consists of the following steps:

  • Configuration of traffic classes to classify packets using class maps
  • Configuration of the service policies for each class map
  • Attach service policy to an interface

Basically this provides a logical step for the processing traffic and applying MPLS EXP classification, marking, scheduling and delivery of the traffic. Within an MPLS VPN, different QoS policies can be configured for each VPN and for the varying traffic classes within the VPN. Below are some configuration examples.

Create Class Maps
VPN A – PE Router
PE1(Config)# class map VPNA
PE1(config-cmap)#match input interface s0/0/0 (Classification)
PE1(config-cmap)#match IP Precedence 6 (Classification)

Create Service Policies
VPN A – PE Router
PE1(Config)# policy-map VPNA_Policy
PE1(config-pmap)#class map VPNA
PE1(config-pmap)#bandwidth 1544 (Guaranteed bandwidth for interesting traffic)
PE1(config-pmap)#queue-limit 60 (queue limit for interesting traffic/# packets)
PE1(config-pmap)#set MPLS experimental 4 (sets all traffic in this class to EXP 4)

Attach Service Policies to interfaces
VPN A – PE Router
PE1(Config)# interface serial 0/0/0
PE1(config-int)#service-policy input VPNA_Policy

These configurations set the QoS at the PE (edge) router. The core routers must be configured to identify and process the packets that are classified and marked by the edge policies. The core is configured with a certain number of classes, usually four. The traffic is placed in the specific class as determined by the MPLS EXP bit set at the edge. Below is the configuration for the core router.

P1(config)# class-map Realtime_traffic
P1(config-cmap)#match MPLS experimental 4

Now the P router must be configured to act on the traffic in the Realtime_traffic class. This is again the service policy for the class, in this case all traffic marked with EXP 4.

P1(config)# policy-map four_classses
P1(config-pmap)#class Realtime_traffic
P1(config-pmap-c)#bandwidth 512
P1(config-pmap-c)#queue-limit 90
P1(config-pmap)#class Class 2
P1(config-pmap-c)#bandwidth X
P1(config-pmap-c)#queue-limit Y
P1(config-pmap)#class Class 3
P1(config-pmap-c)#bandwidth X
P1(config-pmap-c)#queue-limit Y
etc, etc

Attach core service policy to input interfaces

P1(Config)# interface serial 0/0/0
P1(config-int)#service-policy input Realtime_traffic_Policy

Once the edge (PE) and core (P) routers and all service policies have been created and attached to interfaces you are good to go.


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.
This was first published in December 2004

Dig deeper on Managed services

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchNetworking

SearchUnifiedCommunications

SearchTelecom

SearchSDN

Close