IP Precedence and DSCP Values

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

1 Like

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

Hi Team,

Very well explained as are all the lessons I’ve looked at so far. I am confused about something though regarding the AF marking. I am reading in some places that AF1 has less priority than AF4 and in other places I am reading that there is no preferential treatment for an AF class over another. So for instance, in one network AF4 could be more important than AF1 but then passing to another router in a different network, AF1 could more more important than AF4.

Could you just clarify for me please.

Thanks

Hello Shaun

You must remember that all of these values found within the DS field are simply markings within the IP header. What a device does with them and how it interprets them are up to the administrator of the particular network through which they are being transmitted.

For example, a packet may traverse various networks that are administrated by separate entities.
One such network may be configured to provide higher priority to AF1 than AF4, another a higher priority to AF4 rather than AF1, and another network may ignore these markings all together. The Assured Forwarding PHB definitions do however have an expected default behaviour of vendor equipment for such markings, and these are described in RFC 2597. This document is actually quite an easy read, and describes how these classes are expected to be dealt with by default.

I hope this has been helpful!

Laz

1 Like

Awesome, thank you very much Laz.

Shaun

1 Like

Hey Everyone, the QOS is very very interesting. I have an infrastructure with Cisco jabber installed on phones Android and IOS. I saw in the Cisco Jabber there is an Option DSCP that you can enable. My questions is when the frame leaves the Wireless Device to the AP ( Lightweight ), is the Frame will be tagged with DSCP EF? and what about browsing web in the Phone? Does the AP can differ both Traffic? And then there is a Capwap tunnel to the WLC with i think will have the same DSCP. I know there is NBAR2 , but should i configure also the interface between the switch and the AP for QOS Voice.
Thanks and the forum is really good, i am learning many things.
Mina

Hello Mina

It’s great to hear that you like the forum and the lessons!!

The implementation of QoS on voice applications installed on a mobile device such as an Android or iOS phone involves various parameters. Specific DSCP values are configured on the Cisco Unified Communications Manager (CUCM). When you enable the DSCP option on Jabber, it then retrieves those preconfigured DSCP values from the CUCM and applies them directly to the IP headers of the RTP media packets.

This will take place only on the voice packets sent from the Jabber application on the phone. This will not affect the DSCP values of other traffic (web, email, etc) that originate from the phone. Remember however that DSCP values are at Layer 3. This means that DSCP values will only actually have any effect when they reach the next router in their journey, which may be beyond the AP, and well within the wired network.

Therefore, these DSCP values must then be translated to some form of QoS that will kick in for the wireless portion of the network, which is at Layer 2. Now in order for this to function correctly, the phone must support 802.11e which is a standard that defines QoS enhancements for Wi-Fi. This is sometimes referred to as Wi-Fi Multimedia (WMM). This and must also be supported by the Wi-Fi network. The Android phone (or any wireless device for that matter) must have this capability in order to ensure QoS for the wireless portion of the journey.

Now you must also configure APs, the controller, as well as the wired network to respond to these QoS values as well. You can see some example QoS configurations at the following Cisco documentation:

You may also find this Cisco community thread useful as well:

I hope this has been helpful!

Laz

Hey Laz,
thank you so much for this great explanation.
i read so many articles to understand what is exactly WMM and CAC. I am trying to understand what are these features. I think my brain shutdown. I will try to read it again another day.
Mina

1 Like

Thank you for well explained lesson. But I just confused after reading this in the forum.
“meaning in reality af21 no difference af31 just depends on the action in the policy map that I will apply on
Yes, this is absolutely correct.”
Rene says in the AF PHB section that “Class 4 has the highest priority. For example, any packet from class 4 will always get better treatment than a packet from class 3.”
So, as I understand there should be difference AF21 and AF31. Ok, They have same low drop probability but they have also different class priority marking. And, if each administrator define different policy to these classification there will be no standardization. Am I right? Or not?
Thank you.

Hello Ike

When it comes to QoS, there are various distinct mechanisms taking place. The first is classification. This involves identifying (or classifying) traffic so we know what it is (voice, web, video, file transfer etc…)

Second comes marking, which is where the IP Precedence and DSCP values come in. This process chooses among the classified traffic, what priority, or what IP precedence and DSCP values each class of traffic should have, and it is applied to that traffic.

Now up to this point, we’ve only identified and put labels on our packets. If a router is not actually instructed to respond to these labels, it will treat them all the same, using “best-effort”.

Differentiated services, as described in this lesson, involves a series of standard responses to these markings, and these are defined within various RFCs. These RFCs define how to interpret the 8-bit DS field found within the IP header, and also define a “default” or standardized predetermined treatment of the various values found within it.

On a Cisco device, if queuing is enabled, (i.e. if a service policy is applied to an interface), then the markings will by default be treated as described in this lesson.

By default, the class defines which queue the packet will be placed in while the drop probability defines how likely it will be dropped in the event that the queue becomes full. But, these default behaviours can be adjusted and changed however you like, by changing the policy maps associated with the queuing.

I hope this has been helpful!

Laz

Thank you very much Laz for clarification. As I understand, this is kind of passport queue while entering in a country. If anybody has diplomatic passport ( cs5 value ) , by default they have higher priority but passport control management can decide in which queue they will enter and how they will be treated (snacks, refreshments…). If there’s no policy enabled, everybody will be in the same queue and treated with FIFO.
Thank you again.

Hello Ike

Yes, that’s a perfect analogy, and easy to understand. Thanks for sharing that!!

Laz