cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4628
Views
4
Helpful
8
Replies

QOS - DSCP Vaules

carl_townshend
Spotlight
Spotlight

Hi all

Can anyone tell me when looking at the dscp values, are the CS values also included?

Am I right in saying they are only there as they map to the IP Precedence values and are backwards compatible?

so for example CS1 is DSCP value of 8 ? which AF class would this fall into ?

cheers

1 Accepted Solution

Accepted Solutions

Right, take note of:

These PHBs retain almost the same forwarding behavior as nodes that implement IP-precedence based classification and forwarding.

and

These PHBs ensure that DS-compliant nodes can co-exist with IP-precedence aware nodes, with the exception of the DTS bits.

Which is why I wrote "No, they are not fully backward compatible, but they can be used like IPPrec."  I.e. a simplified version of the RFC info.

Basically the CS code points overlap between AF RFC and IPPrec.  For example, in pure AF, AF4x doesn't really guarantee precedence over AF1x, but IPPrec 4 has precedence over IPPrec 1.  In common usage, CS classes generally are treated like IPPrec for relative precedence and the related AF group "under" that class is too.

BTW, another example of how CS is different, consider the RFC for the scavenger class which uses CS1, which has less priority then BE traffic.  If you use this RFC recommendation, CS is no longer backward compatible with IPPrec, even ignoring the DTR bits.

View solution in original post

8 Replies 8

Joseph W. Doherty
Hall of Fame
Hall of Fame

Can anyone tell me when looking at the dscp values, are the CS values also included?

Yes.  (NB:DSCP values range from 0..63).

Am I right in saying they are only there as they map to the IP Precedence values and are backwards compatible?

No, they are not fully backward compatible, but they can be used like IPPrec.

so for example CS1 is DSCP value of 8 ? which AF class would this fall into ?

Correct.  None, CS is not an AF.

so CS does not fall into an AF? are you sure?

so what do they align to? so are you saying the below is incorrect ?

CS0 = ip precedence 0 = dscp 0
CS1 = ip precedence 1 = dscp 8      = AF11-13 (dscp 10,12,14)
CS2 = ip precedence 2 = dscp 16    = AF21-23 (dscp 18,20,22)
CS3 = ip precedence 3 = dscp 24    = AF31-33 (dscp 26,28,30)
CS4 = ip precedence 4 = dscp 32    = AF41-43 (dscp 34,36,38)
CS5 = ip precedence 5 = dscp 40    = EF (dscp 46)
CS6 = ip precedence 6 = dscp 48    
CS7 = ip precedence 7 = dscp 56

Hello

Please review below- probably explains it better than I was trying to- which makes me wonder - if I cannot explain it in simple terms then surely I don't know enough about it!

Class-Selector PHBs (Defined in RFC-2474)
To preserve backward compatibility with the IP-precedence scheme, DSCP values of the form `xxx000,' where x is either 0 or 1, are defined. These codepoints are called class-selector codepoints. Note that the default codepoint is also a class-selector codepoint (`000000'). The PHB associated with a class-selector codepoint is a class-selector PHB. These PHBs retain almost the same forwarding behavior as nodes that implement IP-precedence based classification and forwarding. For example, packets with a DSCP value of `110000' (IP-precedence 110) have a preferential forwarding treatment (scheduling, queuing, etc.) as compared to packets with a DSCP value of `100000' (IP-precedence 100). These PHBs ensure that DS-compliant nodes can co-exist with IP-precedence aware nodes, with the exception of the DTS bits.

res

paul


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Right, take note of:

These PHBs retain almost the same forwarding behavior as nodes that implement IP-precedence based classification and forwarding.

and

These PHBs ensure that DS-compliant nodes can co-exist with IP-precedence aware nodes, with the exception of the DTS bits.

Which is why I wrote "No, they are not fully backward compatible, but they can be used like IPPrec."  I.e. a simplified version of the RFC info.

Basically the CS code points overlap between AF RFC and IPPrec.  For example, in pure AF, AF4x doesn't really guarantee precedence over AF1x, but IPPrec 4 has precedence over IPPrec 1.  In common usage, CS classes generally are treated like IPPrec for relative precedence and the related AF group "under" that class is too.

BTW, another example of how CS is different, consider the RFC for the scavenger class which uses CS1, which has less priority then BE traffic.  If you use this RFC recommendation, CS is no longer backward compatible with IPPrec, even ignoring the DTR bits.

Hello Joseph

i couldn't have put it any better that ! - lol 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hi

So when we talk about these PHB's and AF classes, what process or config on the router is looking into these classes and dropping them etc? Is it different on each node? or Is it the WFQ process that looks at the QOS values and drops them according to its value?

For starters, typically L3 network devices ignore ToS unless you configure them to do something with it.  One Cisco exception that comes to mind is interface WFQ.

Is it different on each node?

Depends on the QoS model being used.  If you're using PHB, which stands for per-hop-behavior, each hop may have a different policy although generally those under the same administrative management have a similar or consistent policy.

So when we talk about these PHB's and AF classes, what process or config on the router is looking into these classes and dropping them etc?

That depends on the platform.  Different platforms offer different QoS features, how they are enabled may vary (although Cisco has been trying to get them consistent by using MQC [Modular QoS Command line]), and how they are physically implement such features depends very much on hardware.

or Is it the WFQ process that looks at the QOS values and drops them according to its value?

That's just one of many QoS feature implementations.  What it does is based on its own "rules".  BTW, WFQ only drops when its flow queues overflow.  (I'm also assuming you do mean WFQ and not CBWFQ.)

Hello
My understanding is the Class Selector PHBs are values that can be understood by differential services and assured forwarding in similar regards to ip precedence values.

Thus:
CS0 = ip precedence 0 = dscp 0
CS1 = ip precedence 1 = dscp 8      = AF11-13 (dscp 10,12,14)
CS2 = ip precedence 2 = dscp 16    = AF21-23 (dscp 18,20,22)
CS3 = ip precedence 3 = dscp 24    = AF31-33 (dscp 26,28,30)
CS4 = ip precedence 4 = dscp 32    = AF41-43 (dscp 34,36,38)
CS5 = ip precedence 5 = dscp 40    = EF (dscp 46)
CS6 = ip precedence 6 = dscp 48    
CS7 = ip precedence 7 = dscp 56

res
Paul


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: