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