IP Precedence and DSCP Values

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

Source - https://www.savvius.com/networking-glossary/tcp_ip_overview/ip/ip_tos/

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

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

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

Hi Lazaros,
I understood what Precedence is and also Differentiated services but after that I am totally confused about the remaining.
If possible please simply it to me.

Hello Muhammad

The rest of the lesson deals with Per Hop Behaviour. Essentially, this just refers to the way or the behaviour with which each router (per hop) will deal with a packet when it receives it based on the code point values found within the DS field. So when we talk about PHB it really means how the router will handle the particular packet compared to all the rest it receives whenever there is congestion.

The default PHB has a DSCP value of zero or 000000. Such packets are treated as best effort, meaning, first come first serve. No special treatment or priority is given to theses.

The next three sections simply talk about ways in which the DS field is used and interpreted.

Class-Selector PHB is a way in which the new structure of the field can be compatible with the old IP Precedence structure described earlier in the article. Class selector PHB separates the DS field into two 3-bit sections. The first three bits are only used, just like in IP Precedence, thus making it compatible.

Assured Forwarding PHB is a set of predefined DSCP values that are placed into four queues (or classes) with three levels of drop precedence. This just means that there are three different levels that packets can be defined with that will either make the eligible to be dropped (or not) if congestion occurs. These are simply another set of defined parameters.

Expedited forwarding PHB is just an additional construct that is used to mark packets that are sent into a priority queue, this is a queue in addition to the other four mentioned in Assured Forwarding PHB. Packets marked with EF (or 101110 in binary) will be placed into this priority queue to be sent before all other queues.

These are just definitions of how the specific field in the IP packet is being used and interpreted. They are predefined methodologies of applying QoS to packets that correspond to specific values in the DSCP field.

I hope this has been helpful!

Laz

Hi

In DS field drop

Class 1 .2.3.4

What’s AF11 , AF21& etc and 6 binary numbers ? I can’t understand it

AF21 = 010010

32 16 8 4 2 1
0 1 0 0 1 0

16+2 = 18 . It,s not 21 i’m confused

Thanks

Hello Abdul

The designation of the various AF values allows for a specific method of classification. The classes (first three bits) are separated into 4 and each class has a different drop probability (second three bits). All of this however simply translates into a six bit number which can be expressed either as a decimal or using the AF notation.

In the lesson, Rene states that the AF values can be converted to their decimal values by using the forumla:

decimal value = 8x + 2y where X=class value and Y=drop value.

So in your case of AF21 which is 010010, we have X = 010 or 2 in decimal and Y = 010 or 2 in decimal once again.

So the decimal value of AF21 = 8 * 2 + 2 * 2 = 20

Note here that the resulting decimal value has nothing to do with the number after the “AF” designation. The AFXY designation simply shows the position of the Assured Forwarding (AF) definition in the table. Take a look at the table again:


Notice AF22 is in class 2 (column 2) and drop medium (row 2). AF 43 is in class 4 (column 4) drop high (row 3).

So for AFXY, X=class and Y=drop precedence. This is also confirmed in RFC3260.

I hope this has been helpful!

Laz