# IP Precedence and DSCP Values

What does in mean by CU here , You haven’t explained that last 2 bits though

“Some vendors prefer to use decimal values instead of AF11, AF32, etc. A quick way to convert the AF value to a decimal value is by using the 8x + 2y formula where X = class and Y = drop probability. For example, AF31 in decimal is 8 x 3 + 2 x 1 = 26.”

In above statement you have used “1” as drop probability , Since the binary 010 it should be 2 right?
So it should be 83+22=28

Correct me if im wrong.

Hi Ajay,

The two CU bits are currently unused and ignored.

When you look at AF, the first three bits are the class and the 4th + 5th bit are the drop probability. You can ignore the 6th bit.

AF31 = 011 010

011 = 3
01 = 1

That’s why AF31 is 26 in decimal.

Rene

*Edit* A previous typo of “110” was corrected to “011”

I still didnt understand how did you interpret AF31 as 110010 though i understand the 8x+2y calculation.

Ajay,
Rene had a typo in his response. This is the corrected version:
------------------
AF31 = 011 010

011 = 3
01 = 1

That’s why AF31 is 26 in decimal.
------------------

Does that make more sense now?

Yes ANdrew , Thanks.Now i understand.

19 posts were merged into an existing topic: IP Precedence and DSCP Values

The text below has also to be corrected.

_> The first 3 bits are used to define the class and the next 3 bits are used to define the drop probability. Here are all the possible values that we can use:_

Only 2 bits are used for drop probability, the 6th bit is ignored.

Hello Maodo

According to RFC2474 it speaks about the DS field:

``````   Implementors should note that the DSCP field is six bits wide.  DS-
compliant nodes MUST select PHBs by matching against the entire 6-bit
DSCP field, e.g., by treating the value of the field as a table index
which is used to select a particular packet handling mechanism which
has been implemented in that device.  The value of the CU field MUST
be ignored by PHB selection.
``````

It says that the entire 6-bit field must be used. The bits in question are bits 0 to 5 (a total of six bits). Bits 6 and 7, also known as the CU bits, are currently unused. Could this be the “6th bit” that you mention should be ignored?

Even in RFC791 (IP Header Structure) which precedes the above RFC, the then called Type of Service or ToS field used all six bits as can be seen from the link.

I hope this has been helpful!

Laz

Hi Lagapides,

According to the numbering you used, 5th bit must be ignored. Let’s go back to the example given by Andrew.

AF31 = 011 010

011 = 3 (0-2 bits sequence)
01 = 1 (3-4 bits sequence)

If 5th bit is considered, 3-5 bit sequence will be 010 (2 in decimal) or 011 (3 in decimal). Then ; if the next 3 bits are used to define the drop probability, as said in the lesson, we’ll have something different : AF32 or AF33.

Hello Maodo

Specifically, when converting the AFXX values to decimal values, yes, you ignore the 6th bit, or bit number 5 (if you start counting from 0). However, when taking the DS field into account, devices MUST use the full 6 bit field to determine DSCP values.

I hope this has been helpful.

Laz

Hi Lazaros,
Thanks for explaining this however why should we ignore the 6th bit? The device will never ignore the 6th bit (5th bit when it count from 0) & RFC says so , in that case 6th bit should be taken under consideration right? Does it always 0?

Hello Ajay

When a device reads the DS field, it will read all 6 bits. This is because of the way the DF field has been designed. It will look at the value including all 6 bits. This is why the RFC says that it takes all bits into account. For example, a Low drop probability in class 1 will give a value of 001010 = 10. If the device ignores bit 6 (or 5 counting from 0) then we will have 00101 = 5. So from the device’s point of view, you cannot ignore this bit. It is true however, that this bit is always 0 for all of the possible values that can be used.

We, as humans, when we look at the field, we see again, all six bits, however, because the 6th bit (or 5th when counting from 0) is always 0 we can use the term “we ignore the bit” but in essence you can’t do that.

I hope this has been helpful!

Laz

Question about EF. You said:
The DSCP value is normally called “EF” and in binary it is 101110, the decimal value is 46.

Is that the only value for EF? Theres no 101010 (decimal value 42) or 101100 (decimal value 44)?

Hello Jason

The values of DSCP can be anything you set them to. They can be any value between 000000 and 111111 and will be compared accordingly with other DSCP values. However, when translating between DSCP values and IP Precedence values, there are specific values that can be used. 42 for example will not translate directly to an IP precedence value, but it will translate to the closest available which is 40 which translates to IP precedence value of 5.

Having said that, the EF value is used specifically used to employ Queueing and Policing. Only EF will be used for these purposes. Any other values will not be interpreted as Expedited Forwarding functionality.

I hope this has been helpful!

Laz

Real Story behind TOS:

A. DOD DD173 Precedence/Priority Filed Explanations (Lowest-Highest):

Routine: ® “…is used for all messages that justify transmission by electrical means unless the message delivery is of sufficient urgency to require higher precedence.”
Priority: § “…is used for all messages that require expeditious action by the addressee(s) and/or furnish essential information for the conduct of ongoing operations.”
Immediate (O) “…is reserved for messages relating to situations that gravely affect the security of National/Allied forces or populace.”
Flash (Z) “…is reserved for initial enemy contact messages or operational combat messages of extreme urgency.”
Flash Override (X) “… is reserved for messages relating to the outbreak of hostilities and/or detonation of nuclear devices.”
CRITIC/ECP “…stands for “Critical and Emergency Call Processing” and should only be used for authorized emergency communications, for example in the United States Government Emergency Telecommunications Service (GETS), the United Kingdom Government Telephone Preference Scheme (GTPS) and similar government emergency preparedness or reactionary implementations elsewhere.”

When you look at a packet capture in Wireshark, it seems the “CU” bits seem to be used for ECN.

Hello Chris

Yes, this is the case. According to the following Cisco documentation:

the last two Currently Unused (CU) bits in the DiffServ field were not defined within the DiffServ field architecture; these are now used as Explicit Congestion Notification (ECN) bits.

I hope this has been helpful!

Laz

Dear Rene,
Your topic make me better, I’m still confusing some more:

1. What is the relationship between Class-Selector PHB and AF/EF PHB? do you have to choose one of them when you talk to device?
2. When we use Class-Selector PHB, we only use three first bits of DS field. Am I right?
3. AF PHB same as CS1 to CS4 but AF PHB uses more 3 bits for Drop Probability?
4. EF PHB same as CS5, CS6, CS7? If that, no have any priority among CS5 and CS6 and CS7?

Hello Thejohn

The definition of these two PHBs is such that both older devices, which only “understand” IP Precedence and newer devices that support AF and EF can coexist on the network. Older devices would only take into account the first three bits in the DS field and ignore all the rest. The devices that understand AF and EF take the additional bits into account and apply the classes and drop probabilities using 6 bits instead of 3. This way, any packet that arrives on either an older or newer device can still be processed based on the markings and based on the capabilities of the device in question.

So you don’t choose which to use, but the capabilities of the device you are configuring dictates which bits will be taken into account.

Yes that is correct.

Yes. If a device takes the drop probability into account, it will use that information. If it cannot read such information, it will ignore it. But AF does only use the values associated with CS1 to CS4.

EF is the same as CS5 only. If you get a packet with CS6 or CS7, then it will be dealt with only using Class-Selector PHB mechanisms.

I hope this has been helpful!

Laz