DSCP or IP Precedence...do you understand the difference?

I was recently asked a question by an INE client who was confused about the differences between DSCP and IP Precedence (when it came to the application of QoS markings to an IPv4 (or IPv6) packet). In the event that others have similar confusion, I thought I'd share my response with a wider audience.

Here is what I wrote...

******************************

Both IP Prec and DSCP are terms used when setting some of the bits to "1" within the ToS (Type of Service) field of an IPv4 packet (or "Traffic Class" field in an IPv6 header). However, while IP Prec only had the capability of setting up to three bits to define priority...DSCP can set up to six bits.

It's like this:

Here are all the bits of the ToS byte:

__ __ __ __ __ __ __ __

Here are the bits that IP Precedence can set (denoted with "P"):

P??P??P?__ __ __ __ __

Here are the bits that DSCP can set (Denoted with "D"):

D?D?D?D?D?D?__ __

Clearly, DSCP is superior because it gives you far more combinations of priority that you can utilize (up to 64 values if you include the value of zero). However, some versions of older software don't support DSCP; on those devices, your only option is to mark a packet via IP Precedence.?

In order to make DSCP "backward compatible" with older IP-Precedence-only devices, you have the option (when implementing QoS) to have DSCP only mark the first three bits of the ToS byte (the same bits that IP Precedence can mark/read).?Within the world of DSCP these first three bits are called the "Class Selector" bits and?are the only bits that should be set if you know that you have some older devices in your network that only support IP Precedence.?

The next 2-bits that DSCP could set within the ToS byte (in an all-DSCP environment) are called the "Assured Forwarding" bits. And the sixth bit (which could also be used for DSCP priority) doesn't have a name that I'm aware of. So instead of writing all the bits with "D's" as I did above, technically, DSCP really looks like this:

C = Class Selector bit

A = Assured Forwarding bit

N = No-name bit

C?C?C?A?A?N?__ __

(by the way, the last two bits of the ToS byte DO have a meaning for DSCP, but they are not used to indicate the relative priority of a packet).

• So setting a packet with DSCP markings to represent "CS1" would look like this:?00100000 (and an IP-Precedence device would recognize that as IP Precedence "1").
• So setting a packet with DSCP markings to represent "CS5" would look like this:?10100000 (and an IP-Precedence device would recognize that as IP Precedence "5").

When setting the "A" bits along with one or more of your CS bits, your combined marking value is called an "AF" value.?AF values always are denoted with two digits "XY" where "X" denotes the decimal value of the "CS" bits and "Y" denotes the decimal value of the "AF" bits (and the "N" bit is set to zero).

• So setting a packet with DSCP markings to represent "AF11" would look like this:?00101000 (and an IP-Precedence device would not recognize that value and possibly drop that packet).
• So setting a packet with DSCP markings to represent "AF32" would look like this:?01110000 (and an IP-Precedence device would not recognize that value and possibly drop that packet).

You also have (at least on Cisco devices) the ability to set the DSCP value to simply a number between 0 and 63 which then allows you to make use of that "No-Name" bit if you need the full range of values. So for example a DSCP value of "37" would render in binary as 10010100.

You may also have heard the term "drop probability" as related to DSCP. In theory, CS1 through CS4 each have three sub-levels of drop probability. For example, within CS1 you have the following three sub-levels of Assured Forwarding:

• AF11 = 0010100
• AF12 = 0011000
• AF13 = 0011100

Drop probability (in the DSCP RFC) means that the higher/greater the AF value, the MORE likely that packet will be dropped if it hits an interface that is congested and needs to discard a packet. So a packet marked as AF13 would have a higher drop probability than another packet marked as AF12. And AF12 would be more likely to be dropped than a packet marked as AF11.

Cisco devices don't enforce AF drop probability by default. In actual practice, different AF values might end up in different interface queues when times of congestion occur, but there are no Policers that are automatically applied to ensure that one AF value has a higher or lower drop probability than another. You'd have to configure that manually if you wanted to do that.

I hope that clears up some of your confusion!

Keith