Which byte inside the ipv4 header is used for DiffServ markings?

The Differentiated Services (Diffserv) architecture specifies use 
of the DS field in the IPv4 and IPv6 packet headers to carry one
of 64 distict differentiated services field codepoint (DSCP) values. 
The codepoint space is divided into three pools for the purpose of 
codepoint assignment and management: a pool of 32 codepoints (Pool 1)
to be assigned by Standards Action as defined in [RFC8126], a pool of 
16 codepoints (Pool 2) to be reserved for experimental or Local Use 
(EXP/LU) as defined in [RFC8126], and a pool of 16 codepoints (Pool 3) 
which are initially available for experimental or local use, but 
which should be preferentially utilized for standardized assignments 
if Pool 1 is ever exhausted. Pool 3 codepoints are now utilized for 
standardized assignments and are no longer available for experimental
or local use, as specified by [RFC8436]. The pools are defined in the 
following table (where 'x' refers to either '0' or '1').
  

Registries included below

• Differentiated Services Field Codepoints (DSCP)
  • DSCP Pool 1 Codepoints
  • DSCP Pool 3 Codepoints
• ECN Field (Bits 6-7)

Differentiated Services Field Codepoints (DSCP)

ECN Field (Bits 6-7)

RFC Required

The registrations are identical for IPv4 and IPv6.
    

Footnote

• IP Precedence
• Differentiated Services
  • Default PHB
  • Class-Selector PHB

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

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…

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:

Type of Service:

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:

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: