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 was 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 lesson, 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 somehow confusing that we have a type of service “byte” and that bits 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:


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 ten years later, in 1992, RFC 1349 was created changed the definition of the TOS byte to look like this:

TOS byte precedence type of service mbz

The first three precedence bits remain unchanged, but the type of service bits has changed. Instead of five bits, we now only use four 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:


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 the precedence that we used in the TOS byte, it’s used to set a specific priority.

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

Two phones three routers and end-to-end QoS

Above, we have two phones and three 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 particular 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 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.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 788 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

720 Sign Ups in the last 30 days

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

Forum Replies

  1. Great article and it makes a lot of sense about DSCP and IP Prec values.

  2. Hi Hamood,

    Glad to hear it was useful!


  3. Very Nice article and very well framed.
    Kudos to Rene.

  4. Hi

    Can you explain me about Quality of Service on trunk links? It’s important.


  5. Hi Alberto,

    I can, anything in particular you want to know?


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