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:

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:

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:

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:

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:

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 only use the first three bits, just like we did with IP precedence. Here is a list of the possible class-selector codepoints that we can use:

Class selector name	DSCP value	IP Precedence value	IP Precedence name
Default / CS0	000000	000	Routine
CS1	001000	001	Priority
CS2	010000	010	Immediate
CS3	011000	011	Flash
CS4	100000	100	Flash Override
CS5	101000	101	Critic/Critical
CS6	110000	110	Internetwork Control
CS7	111000	111	Network Control

As you can see, CS1 is the same as “priority” and CS4 is the same as “flash override”. We can use this for compatibility between the “old” TOS byte and the “new” DS field.

The default PHB and these class-selector PHBs are both described in RFC 2474 from 1998.

Assured Forwarding PHB

About a year later, RFC 2597 arrives that describes assured forwarding. The AF (Assured Forwarding) PHB has two functions:

1. Queueing
2. Congestion Avoidance

There are 4 different classes and each class will be placed in a different queue, within each class there is also a drop probability. When the queue is full, packets with a “high drop” probability will be deleted from the queue before the other packets. In total there are 3 levels for drop precedence. Here’s what the DS field looks like:

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:

Drop	Class 1	Class 2	Class 3	Class 4
Low	001010 AF11	010010 AF21	011010 AF31	100010 AF41
Medium	001100 AF12	010100 AF22	011100 AF32	100100 AF42
High	001110 AF13	010110 AF23	011110 AF33	100110 AF43

Class 4 has the highest priority. For example, any packet from class 4 will always get better treatment than a packet from class 3.

Some vendors prefer to use decimal values instead of AF11, AF32, etc. A quick way to convert the AF value to a decimal value is by using the 8x + 2y formula where X = class and Y = drop probability. For example, AF31 in decimal is 8 x 3 + 2 x 1 = 26.

Expedited Forwarding

The EF (Expedited Forwarding) PHB  also has two functions:

1. Queueing
2. Policing

The goal of expedited forwarding is to put packets in a queue where they experience minimum delay and packet loss. This is where you want the packets of your real-time applications (like VoIP) to be. To enforce this we use something called a priority queue. Whenever there are packets in the priority queue, they will be sent before all other queues. This is also a risk, there’s a chance that the other queues won’t get a chance to send their packets so we need to set a “rate limit” for this queue, this is done with policing.

The DSCP value is normally called “EF” and in binary it is 101110, the decimal value is 46.

The real world

You should now have good understanding of the difference between IP precedence and DSCP values. It’s quite a long story right?

There’s one thing that I should mention. We talked a lot about PHB (Per Hop Behavior) and the word “behavior” makes it sound like when you use a certain DSCP value, the router will automatically queue, police or drop the packets. The funny thing is that your router won’t do anything! We have to configure the “actions” that the router will perform ourselves…

We have a lot of different values that we can use for the TOS byte..IP precedence, CS, AF and EF. So what do we really use on our networks?

The short answer is that it really depends on the networking vendor. IP Precedence value 5 or DSCP EF is normally used for voice traffic while IP precedence value 3 or DSCP CS3 or AF31 is used for call signaling.

See if your networking vendor has a Quality of Service design guide, they usually do and give you some examples what values you should use.

I hope this tutorial has been helpful to understand the TOS byte, IP Precedence and DSCP. If you have any questions feel free to leave a comment.