# IP Precedence and DSCP Values

(Rene Molenaar) #23

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”

(Ajay R) #24

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

(Andrew P) #25

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?

(Ajay R) #26

Yes ANdrew , Thanks.Now i understand.

(Shantel - Networklessons.com) split this topic #27

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

(MAODO T) #28

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.

(Lazaros Agapides) #29

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

(MAODO T) #30

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.

(Lazaros Agapides) #31

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

(Ajay R) #32

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?

(Lazaros Agapides) #33

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

(Jason W) #34

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)?

(Lazaros Agapides) #35

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

(rudresh b) #36

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.”

(Chris N) #37

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

(Lazaros Agapides) #38

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

(Thejohn N) #39

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?
(Lazaros Agapides) #40

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

(Samer A) #41

I keep seeing Rene saying " they are just markings and it’s up to you to configure your routers/switches to act upon these different markings." is this mean the dropping probability on the classes and priority by RFC we don’t have to take it in the consideration and focus more on the action that we all apply for each marking? meaning in reality af21 no difference af31 just depends on the action in the policy map that I will apply on , is the ef queue is different than other marking? please, let me know I’m confused a little bit here??
please, I saw also some configuration is mixing up cs and af is this normal? like

``````class-map match-any ABC
match dscp cs3
match dscp cs6
match dscp af31``````
(Lazaros Agapides) #42

Hello Samer

You can mark your traffic with various DSCP markings such as af21 and af31 as you mention. But if you don’t configure your routers to respond to such markings, nothing will happen. The traffic will just be served on a first come first serve basis. The RFC mentions how each DSCP value should be dealt with, however, the configuration of such mechanisms are up to the administrator of the network itself.

Yes, this is absolutely correct.

Yes this is normal. Standard DSCP values include AF, CS and EF codes. These can be found at the following link where the specific DSCP values are also indicated:

I hope this has been helpful!

Laz