Lesson Contents
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:
Above, you see the IP header with all its fields, including the TOS byte.
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.
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 ten years later, in 1992, RFC 1349 was created changed the definition of the TOS byte to look like this:
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:
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:
Great article and it makes a lot of sense about DSCP and IP Prec values.
Hi Hamood,
Glad to hear it was useful!
Rene
Very Nice article and very well framed.
Kudos to Rene.
Hi
Can you explain me about Quality of Service on trunk links? It’s important.
Thanks
Hi Alberto,
I can, anything in particular you want to know?
Rene