Difference between DSCP, AF, and CS

Unanswered Question
Mar 16th, 2009

What is the difference between these when coloring traffic on an ingress port?

I'm under the assumption that AF sets individual queues up, and each one of those queues can have something done to it by a match statement.

I'm not clear on what the CS values are for. Maybe L2 CoS?

The DSCP value: When you use "set dscp ?", you'll get <0-some number>, all af values, ef, and all cs values.

I've noticed that if I mark with an AFxx, I get a chart when doing a show policy-map <name>, but if I just do a "set dscp 2", then that particular queue looks a little different under the show command.



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.9 (8 ratings)
Giuseppe Larosa Mon, 03/16/2009 - 07:01

Hello John,

DSCP is a 6 bit field, the DSCP byte takes the place of the older TOS byte.

IP precedence bits are only 3 the most meaningful (= leftmost) in the TOS byte definition.

A class selector has set the first 3 bits in an attempt to be backward compatible with IP prec.

So CS3 and IP precedence 3 have the same meaning and CS3 can be understood by a device that doesn't handle the whole DSCP field.

The CS happens to be also easily mapped to 802.1p 3 bits wide CoS but the reason is backward compatibility with IP Precedence.

AFxy implement a differentiated drop probability from queues.

It is likely that the output of sh policy-map changes if using a CS value or an AF value

Hope to help


John Blakley Mon, 03/16/2009 - 07:05


Are the AF values themselves arbitrary? There are 4 classes of AFs with 3 drop probabilities:

AF11, 12, 13

AF21, 22, 23

AF31, 32, 33

AF41, 42, 43

Are all of these essentially equal? What is the desirable scenario to use AFxy instead of DSCP or IP Prec values?



Giuseppe Larosa Mon, 03/16/2009 - 07:19

Hello John,

in AFxy the x index is roughly the class selector, y the drop probability.

the difference is in how they are treated in a DiffServ model.

AF33 is processed in queue with AF31 AF32.

AF33 < AF32 < AF31 drop probability is better for AF31 then for AF32 then for AF33.

AF33 can be treated better then any AF2y.

AF2y can be treated better then any Af1y.

note: if you use AFxy you are using DSCP indeed.

with DSCP you have more granularity up to 64 different classes can receive a differentied treatment.

With IP Prec taking in account that IP Prec 7 is not used, IP prec 6 is reserved to routing protocols you can accomodate up to 6 classes: 0,1,2,3,4,5.

Hope to help


John Blakley Mon, 03/16/2009 - 07:23

By you saying "treated better then", do you mean by want I place in the policy map that the class is assigned to?

Are the AFxy classes better than IP Prec? I understand that I can have more classes, but is one more preferred (technology-wise) over the other? Would I use one in a certain scenario over the other?

Thanks Giuseppe!


Edison Ortiz Mon, 03/16/2009 - 07:34

Hi John,

You will usually see CS (Class Selector) used on call-signaling. As Giuseppe stated, using AF is intended for flows that could be subject to markdown and aggressive dropping of marked-down values.

Marking down and aggressively dropping Call-Signaling could result in noticeable delay to dial tone (DDT) and lengthy call-setup times, both of which generally translate into poor user experiences, thus the general recommendation is to use CS3 for call-signaling.




John Blakley Mon, 03/16/2009 - 07:48

Thanks Edison

Aside from those, when is a good time to use "set ip prec" commands under a policy map or using "set dscp <0-63>" vs. "set dscp af31"?

Like Giuseppe said, there are 64 values for DSCP <0-63>; are these arbitrary? The router doesn't do anything with these numbers other than the action that I tell it to perform under my policy map, right?



Edison Ortiz Mon, 03/16/2009 - 08:04

When defining end-to-end QoS, it's recommended to follow pre-defined guidelines often found in RFCs.

There isn't a rule to use one type of marking over another but when configuring an enterprise network, you often will have to deal with other entities where they will also have QoS.

If both entities followed a pre-defined guideline on how packets should be marked, any QoS implementation between these entities will be much easier.

One thing about the values, as I mentioned on another post on this thread, the values mean something as switches have a table-map as to where to place these packets based on their values.




Jon Marshall Mon, 03/16/2009 - 07:45



where x = the class

y = the drop probability

The higher the x is the better treatment the traffic gets but note that is a convention. There is nothing within the AF classes that inherently supplies QOS so it is up to you. The convention states that AF41 gets better treatment that AF31 but that treatment is defined by your policy so there is nothing stopping you giving better treatment to AF31 than AF41 if you really wanted to.


John Blakley Mon, 03/16/2009 - 07:51

That's what I'm seeing :-)

I'm taking from this thread that the numbers for all of the classes really mean nothing, and it's more for the engineer to be able to look at most configs and say "that's a higher number, so it must be a higher priority class." Either way, the numbers don't do anything other than "label" the traffic type for the engineer looking at it. You would actually set your policy however you wanted to be able to do whatever you wanted to whatever number you want.

Sound right?



Jon Marshall Mon, 03/16/2009 - 07:55

"and it's more for the engineer to be able to look at most configs and say "that's a higher number, so it must be a higher priority class."

Kind of yes. You could not really look at the DSCP values in isolation and say which has better treatment. As i say convention dictates that EF is better than AF41 which is better than AF31 etc... but you really need to check the policy map to find out how this traffic is being treated eg. you usually map EF to the prioriry or LLQ but you can if you want to confuse everybody map AF11 to that queue :-).


Edison Ortiz Mon, 03/16/2009 - 07:59

The numbers mean something as the internal pre-defined QoS values in switches will use those numbers as a reference for packet->queue placement.




Jon Marshall Mon, 03/16/2009 - 08:06


Good point. But what i was getting at was that you can override these values if you want to so that they mean entirely different things. So again it is convention rather than any inbuilt QOS for the values.

Or do you mean something else ?


Edison Ortiz Mon, 03/16/2009 - 08:10


If you want to change every single switch cos-dsp map or prec-dscp map setting to something unique in your network, by all means go ahead :)

What happens when you are sending those markings to switches that you have no control of?

What happens if you are sending those markings to, say, MPLS providers where they have their own established markings?

We are basically saying the same thing but I wanted to point out the values mean something as some of those values are already pre-defined by RFCs - i.e. EF = voice.



Jon Marshall Mon, 03/16/2009 - 08:16


"If you want to change every single switch cos-dsp map or prec-dscp map setting to something unique in your network, by all means go ahead :)"

Not really no :-)

"We are basically saying the same thing"

Yes, i think we are..


John Blakley Mon, 03/16/2009 - 08:09

So, from the routers prospective it doesn't really matter, but a switch's perspective it does. When the switch receives a marked packet, it has internal coding that would treat packets a certain way?


Jon Marshall Mon, 03/16/2009 - 08:15


No not really. I think, altho Edison will confirm, that what Edison was saying is that Cisco routers and switches will recognize certain values whether CoS or DSCP and treat them accordingly - think AutoQos as a good example.

But again there is nothing to stop you changing this behaviour. That is what the CoS-to-DSCP, DSCP-to-CoS maps etc.. are for on a switch.

And Cisco mark certain network traffic with CS6/CS7 and Cisco VOIP kit will mark packets but the key point i'm making is that these values in isolation are meaningless. It is up to you or Cisco as to how they treat them ie. if you simply marked a packet as AF41 and left it at that with no queueing and only tail drop used then the AF41 packets would get no better treatment than anything else.


Mohamed Sobair Mon, 03/16/2009 - 11:57


The "CS" is backward compatibilty with IP precedence values.

The IP-Precedence represent 3 bit in the IP header from the TOS field.

On the other hand, The DSCP is 8 bits long of the "TOS" field in the IP Header. The actually most left 6 bits are used to mark packets, while the most right 2 bits are "ECN" field and has different usage.

Assured Forwarding "AF" and "EF" are all PHP codes for the corresponds DSCP binary value.

DSCP has 4 classes with 3 drop probabilities.

Each class represented by "X" and each priority or drop probability is represented by "Y".

The Correspond Binary Value for the AF marking is defined by the equation bellow"

8x+2y (Binary)

where x = class , y = priority

The sum represent the Binary value.

On the other hand, the L2 COS are 3 bits in the layer-2 header , marking the layer-2 frames with 802.1p.

There is a recommended marking for each type of traffic based on RFC.

The Coloring has no affect on the queue, the Coloring "Marking" is part of the laer-2 and laer-3 packet headers , So it doesn't sets queues up.



Joseph W. Doherty Mon, 03/16/2009 - 14:07

Although I believe some of the (many other) posts touch on this, just want to emphasis there's often a big gap between how things are defined and what's provided on a particular vendor's network device.

The ToS (type of service) byte goes pretty far back as being part of the IP header. Over the years, RFCs have defined different interpretations to this byte's contents. DSCP is one of the later interpretations for the high 6 order bits (0..63, decimal value). Later RFCs provided suggestions on how DSCP might be used, e.g. assured forwarding (AFxy), expedited forwarding (EF), scavenger, etc. Then there's also a RFC suggesting QoS classes and how AFs and EF might be used.

Although RFC can be dry and/or difficult to understand, they are what defines the standards, so you might benefit from reading the RFCs on these issues.

What's often missing from RFCs, is how and why you might want to do things. For this, often books on a subject will make it clear(er). Cisco has some good ones under its label; their whitepapers and technotes are also very helpful (especially with regard to using features specific to Cisco).

Once you covered the standard meanings, and have a feel for the theory, then you can jump into what you might do on actual network equipment. Although you can learn from the equipment's features, you're often left with many gaps in understanding.

As with many other things, to obtain full benefit of some technology, you often need to know much beyond the subject at hand and/or an understanding of its history to reach "critical mass" (in understanding).

These forums are great, but they might not be the best place to easily obtain any subject's "critical mass", directly. However, if you ask for suggestions on books, articles, classes, you might acquire "critical mass" sooner. These forums can be an excellent source for information tidbits and/or some informational point clarification, but from your original questions, and the lack of information they imply (NOT intended as a negative!!!), I'm concerned some answers might confuse as much as explain.


This Discussion