DSCP QoS Over MPLS Thoughts

QoS to MPLS Maps

I have been working on the edge of MPLS networks for several years and had a basic understating of DSCP QoS values that I was sending into the cloud and expecting them to pop onto the LAN at the other side the same. The QoS queues on the CE’s were already setup and I have had no reason to change then until recently for a new VOIP project; this and my studying for CCIE SP written has prompted me to understand DSCP in depth but also understand how this LAN QoS maps to MPLS QoS.

There where two things that jumped out at me when reading how QoS is carried by IP and how QoS is carried in Labels. DSCP which is used in IP has 6 bits (2 x 3) and EXP in Labels has 3. So right away there is a mismatch therefore going from IP to MPLS we must lose something.

Quick Evolution of DSCP

Here is a quick run down op the evolution of QoS on IP, there was possibly a few other RFC along the way† but these would appear to be the significant steps along the way.

• RFC 791 September 1981 ñ Type of Service 8 Bits (3=Precedence , D-Drop, T=Throughput, R=Reliability ,0,0)
• RFC 1349 July 1992 – ToS bits ñ 3-Precedence, 4 Bits for TOS

                  1000   --   minimize delay
                  0100   --   maximize throughput
                  0010   --   maximize reliability
                  0001   --   minimize monetary cost
                  0000   --   normal service

• RFC 2474 December 1998.† DS- Field 6Bits ñ This obsoletes 1349
  • NOT backward compatibility with DTR( RFC 791)
  • IS backward compatible with IP Precedence bits 0-2.

A key factor to take away when considering these RFCís is that they are all based on IP and not MPLS therefore in a vacuum† MPLS has no direct attachment to DSCP.

Focusing in DSCP.

If we look at a Cisco Call Manager document they made a change to call signalling were QoS was originally AF31 then changed to CS3. This is much the same for other current VOIP solution like Nortel where CS3 is how signalling should be handle.

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00801ffe28.shtml

Note: Prior to Cisco CallManager 4.0, voice control traffic defaulted to a DSCP value of 26 / AF31. In Cisco CallManager 4.0 and later, this was changed so that voice control traffic is marked with DSCP 24 /CS3 by default. This change reflects the fact that voice control traffic should never be dropped whereas DSCP AF31 traffic can be dropped in certain instances.

So what does the mean when we need to send CS3 across the WAN instead of AF31?

Let compare the binary Vaues for CS3 and AF31

Well most likely nothing but lets look at why.

CS3 looks like 011000 and AF31 looks like 011001. The key difference being AF31 has a drop probability associated with it I.e the last 3bits 001 where as cs3 has no drop probability.

So where can this drop probability apply, since it DSCP is ip based it can only be applied on IP packets, on output interface where traffic policing has been applied and WRED is enabled.

In a MPLS network this is normally on the CE device and it will be on traffic heading towards the cloud, not on the LAN.

Now what is drop probability? On an IP based network where traffic policing is configured on outgoing interface it is possible to configure policing to use WRED weighted random early detect where it will begin to drop tcp traffic before the output queue fills.

Based on weight , which is found the last 3 bits of the DSCP value where 001 low 010 Medium 011 is high. So since MPLS does not use DSCP and only has 3 bit to use for QoS (exp) so AF31 or other af classes cannot be truly represented over MPLS.

This may seem a strange point to make, but when this new VOIP project insisted on CS3 across the WAN, I had a hard time convincing them there was no such thing! †The best we can do is assign the traffic to the appropriate traffic class, which was the same a previous voice signalling under AF31.

Service Provider Classes

In fact in MPLS the is no automatic translation of ip QoS values into EXP values. Instead these need to be manually mapped at the PE and how different classes of traffic is treated is dependant on what classes your service provider is offering. For example as service provide I work with offers 6 classes which can†approximately†be mapped to the equivalent DSCP value.

Class 1 =CS6

Class 2 = CS5,EF

Class 3 = CS3, AF41,AF42,AF43

Class4 = AF31,AF32,AF33

Class5 = AF21,AF22,AD23

Class6=AF11,AF12,AF13

The truth is I have had an impossible time tracking down what this really means with regards to packet loss, delay and jitter. What I can tell is that if voice is not in Class 2 then it gets broken very quickly, if citrix is not in class 4 then it can be un-responsive. From talking to them class 3,4 and 5 are the same in this SP network, class 1 is used for management traffic †and class 6 is used for Standard Traffic, and if you are not in one of these classes then you get default†scavenger†class †which is not†explicit†defined but means lots of drop.

It is therefore important when engaging with a WAN service provider that you can map your QoS requirement not necessarily your DSCP values into equivalent MPLS traffic classes.

Summary

IP QoS to MPLS QoS is not a 1:1 mapping, it is great having ideas about how you are going to design QoS on the LAN and MAN, however if the QoS has to cross a MLPS WAN then you also need to consider †how you are going to map these to the WAN. In the end you are†at the mercy of the service provider providing the appropriate traffic classes to meet you network needs.