IP Precedence and DSCP Values

IP packets have a field called the Type of Service field (also known as the TOS byte). The original idea behind the TOS byte was that we could specify a priority and request a route for high throughput, low delay and high reliable service.

The TOS byte has been defined back in 1981 in RFC 791 but the way we use it has changed throughout the years. This makes it confusing to understand since there is a lot of terminology and some of is not used anymore nowadays. In this tutorial I’ll explain everything there is to know about the TOS byte, IP precedence and DSCP values.

Let’s take a look at the TOS byte:

ToS byte in IP packet

Above you see the IP header with all its fields, including the TOS byte.

Don’t mix up TOS (Type of Service) and COS (Class of Service). The first one is found in the header of an IP packet (layer 3) and the second one is found in the header of 802.1Q (layer 2). It’s used for Quality of Service on trunk links…

So what does this byte look like? We’ll have to take some history lessons here…

IP Precedence

In the beginning the 8 bits of the TOS byte were defined like this:

TOS Byte precedence type of service

The first 3 bits are used to define a precedence. The higher the value, the more important the IP packet is, in case of congestion the router would drop the low priority packets first. The type of service bits are used to assign what kind of delay, throughput and reliability we want.

It’s a somehow confusing that we have a type of service “byte” and that bit 3-7 are called the type of service “bits”. Don’t mix them up, these are two different things.

Here’s a list of the bits and the possible combinations:

Precedence:

000 Routine
001 Priority
010 Immediate
011 Flash
100 Flash Override
101 Critic/Critical
110 Internetwork Control
111 Network Control

Type of Service:

Bit 3: 0 = normal delay 1 = low delay
Bit 4: 0 = normal throughput 1 = high throughput
Bit 5: 0 = normal reliability 1 = high reliability
Bit 6-7: Reserved for future use

This is what they came up with in 1981 but the funny thing is that the “type of service” bits that specify delay, throughput and reliability have never really been used. Only the precedence bits are used to assign a priority to the IP packets.

About 10 years later, in 1992 RFC 1349 was created that changes the definition of the TOS byte to look like this:

TOS byte precedence type of service mbz

The first 3 precedence bits remain unchanged but the type of service bits have changed. Instead of 5 bits, we now only use 4 bits to assign the type of service and the final bit is called MBZ (Must Be Zero). This bit isn’t used, the RFC says it’s only been used for experiments and routers will ignore this bit. The type of service bits now look like this:

1000 minimize delay
0100 maximize throughput
0010 maximize reliability
0001 minimize monetary cost
0000 normal service

With the old 5-bit type of service bits you could flip some switches and have an IP packet that requested low delay and high throughput. With the “newer” 4-bit type of service bits you have to choose one of the 5 options. Good thinking but the type of service bits have never been really used…

So what do we actually use nowadays?

Differentiated Services

The year is 1998 and 6 years have passed since the last changes to the TOS byte. RFC 2474 is created which describes a different TOS byte. The TOS byte gets a new name and is now called the DS field (Differentiated Services) and the 8 bits have changed as well. Here’s what it looks like now:

DS Field DSCP CU

The first 6 bits of the DS field are used to set a codepoint that will affect the PHB (Per Hop Behavior) at each node.The codepoint is also what we call the DSCP value.

Let me rephrase this in plain english…

The codepoint is similar to precedence that we used in the TOS byte, it’s used to set a certain priority.

PHB is another fancy term that we haven’t seen before, it requires some more explanation. Imagine we have a network with 3 routers in a row, something like this:

Two phones three routers and end-to-end QoS

Above we have two phones and 3 routers. When we configure QoS to prioritize the VoIP packets, we have to do it on all devices. When R1 and R3 are configured to prioritize VoIP packets while R2 treats it as any other IP packet, we can still experience issues with the quality of our phone call when there is congestion on R2.

To make QoS work, it has to be configured end-to-end. All devices in the path should prioritize the VoIP packets to make it work. There are two methods to do this:

  • Use reservations, each device in the network will “reserve” bandwidth for the phone call that we are about to make.
  • Configure each device separately to prioritize the VoIP packets.

Making a reservation sounds like a good idea since you can guarantee that we can make the phone call, it’s not a very scalable solution however since you have to make reservations for each phone call that you want to make. What if one of the routers loses its reservation information? The idea of using reservations to enforce end-to-end QoS is called IntServ (Integrated Services).

The opposite of IntServ is DiffServ (Differentiated Services) where we configure each device separately to prioritize certain traffic. This is a scalable solution since the network devices don’t have to exchange and remember any reservation information Just make sure that you configure each device correctly and that’s it…

With 6 bits for codepoints we can create a lot of different priorities…in theory, there are 64 possible values that we can choose from.

The idea behind PHB (Per Hop Behavior) is that packets that are marked with a certain codepoint will receive a certain QoS treatment (for example queuing, policing or shaping). Throughout the years, there have been some changes to the PHBs and how we use the codepoints. Let’s walk through all of them…

Default PHB

The default PHB means that we have a packet that is marked with a DSCP value of 000000. This packet should be treated as “best effort”.

Class-Selector PHB

There was a time when some older network devices would only support IP precedence and newer network devices would use differentiated services. To make sure the two are compatible, we have the class-selector codepoints. Here’s what it looks like:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Full Access to our 651 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

567 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. Hi Hamood,

    Glad to hear it was useful!

    Rene

  2. Abhishek,
    I would recommend you check out Rene’s lesson on QoS Classification. In this lesson, you will discover that there are all kinds of tools at your disposal to be able to identify, classify, and mark traffic for QoS treatment throughout your network. It is rarely the case, for the reasons you brought up, that a simplistic approach of using just IP addresses is used.

    As for your second question, you are essentially asking about what QoS is meant to do as a whole (so there isn’t a quick, easy answer). The key to getting QoS working properly relies on th

    ... Continue reading in our forum

  3. awesome, it clears now. Thanks for your crystal clear approach of explanation.

    I am eagerly waiting for L2VPN related topics (vpls etc…) :slight_smile:

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

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

    ... Continue reading in our forum

37 more replies! Ask a question or join the discussion by visiting our Community Forum