IP Precedence, TOS, and DSCP Classifications

Appendix 2 IP Precedence, TOS, and DSCP Classifications

In Chapter 11, we discuss several important concepts related to traffic classification, queueing algorithms, and congestion handling systems. Unfortunately, some of these concepts are unfamiliar to many network engineers, so this Appendix includes some more detail and background.

Every IP packet (including both IPv4 and IPv6) includes a TOS byte. This byte is broken up into fields that the network uses to help provide the appropriate QoS commitments. In the older TOS model defined in RFC 1349, the first three bits contain the IP Precedence value, and the next four bits contain the TOS value.

We note in passing that it is easy to get confused between the different uses of "TOS". Sometimes it refers to the entire byte, and sometimes to just the 4 bits that describe forwarding behavior. To help reduce the confusion, we will call the 4-bit field the TOS field, and the entire byte the TOS byte.

Table B-1 shows the standard IP Precedence values. It is important to note that normal application traffic is not permitted to use IP Precedence values 6 or 7. These are strictly reserved for network purposes like keepalive packets and routing protocols. The network must always give these packets higher priority than any application packets. This is because no application will work if the network loses its topology information.

Table B-1. Standard IP Precedence values

IP Precedence	Decimal value	Bit pattern
Routine	0	000
Priority	1	001
Immediate	2	010
Flash	3	011
Flash Override	4	100
Critical	5	101
Internetwork Control	6	110
Network Control	7	111

 

Table B-2 shows the standard IP TOS values, as defined in RFC 1349. The idea was that an application could use these bits to request the appropriate forwarding behavior. Because the values are specified in different bits, the standard originally allowed applications to specify more than one option. This turned out to be unmanageable in practice because it wasn't clear which bit should have precedence in cases where two bits were set, and each would result in selecting different paths. So the standard was changed in RFC 1349 to prevent combinations of TOS bits.

Table B-2. Standard IP TOS values

IP TOS	Decimal value	Bit pattern
Normal	0	0000
Minimum monetary cost	1	0001
Maximum reliability	2	0010
Maximum throughput	4	0100
Minimum delay	8	1000

 

Note that there is some disagreement in the literature about the last bit, which sometimes signifies "minimum monetary cost" and sometimes is not used at all. Some references state that the TOS byte has one unused bit, and others say that there are two unused bits. In any case, this entire scheme is now considered obsolete, and has been replaced by the DSCP model. However, many common applications including TELNET and FTP, still set TOS field values by default. So it is important that the network be able to handle these settings gracefully.

In the new DSCP formalism, defined in RFC 2474, the TOS byte is divided into a 6-bit DSCP field, followed by two unused bits. As we will discuss in the next section, the DSCP formalism was designed to give good backward compatibility with the older formalism. In particular, the first three bits of the DSCP field map perfectly onto the older IP Precedence definitions.

The first three bits of the DSCP field identify the forwarding class. If the value in the first three bits is four or less, the packet uses Assured Forwarding (AF). If the value is five, which corresponds to the highest allowed application IP Precedence value, then the packet uses Expedited Forwarding (EF). These names are slightly confusing because, in general, Assured Forwarding is merely expedient, while Expedited Forwarding is more likely to assure delivery.

Table B-3 shows the Assured Forwarding DSCP values. As we have already mentioned, the first three bits specify the forwarding class. A higher value in this sub-field results in a higher forwarding precedence through the network. The remaining three bits specify Drop Precedence. The higher the drop precedence, the more likely the packet will be dropped if it encounters congestion.

Table B-3. Assured Forwarding DSCP values

Drop Precedence	Class 1	Class 2	Class 3	Class 4
	Value	Name	Value	Name	Value	Name	Value	Name
Lowest Drop Precedence	001010(10)	AF11	010010(18)	AF21	011010(26)	AF31	100010(34)	AF41
Medium Drop Precedence	001100(12)	AF12	010100(20)	AF22	011100(28)	AF32	100100(36)	AF42
Highest Drop Precedence	001110(14)	AF13	010110(22)	AF23	011110(30)	AF33	100110(38)	AF43

 

For Expedited Forwarding there is only one value. It has a binary value of 101110, or 46 in decimal, and it is usually simply called EF. Note that this continues to follow the same pattern. The first three bits correspond to a decimal value of 5, which was the highest application IP Precedence value. You could think of the remaining three bits as specifying the highest drop precedence, but really this isn't meaningful because there is only one EF value. However, there is still significant room for defining additional EF types, if it becomes necessary in the future.

The remaining two unused bits in the TOS byte have been the subject of some very interesting discussions lately. RFC 3168 suggests that they might be used for congestion notifications, similar to the Frame Relay Forward Explicit Congestion Notification (FECN) and Backward Explicit Congestion Notification (BECN) flags. This would seem to be a natural place to make this designation, since there is no congestion notification field anywhere else in the IPv4 or IPv6 headers. If packets carried this sort of information, routers could use adaptive processes to optimize forwarding behavior. If a link started to become congested, all upstream routers would automatically sense the problem and start to back off the rate that they are sending traffic before any application suffered from queue drops. This would be similar to the adaptive Frame Relay traffic shaping system that we discussed in Recipe 11.11. We look forward to seeing Cisco implement this feature in the future.

Combining TOS and IP Precedence to Mimic DSCP

You can also get the equivalent of DSCP, even on older routers that support only TOS and Precedence, by combining the TOS and Precedence values. All Assured Forwarding DSCP Class 1 values are equivalent to an IP Precedence value of 1, Priority. All Class 2 values correspond to IP Precedence 2, Immediate; Class 3 values to IP Precedence 3, Flash; and Class 4 corresponds to an IP Precedence value of 4, Flash Override. The higher IP Precedence values are not used for Assured Forwarding.

You can then select the appropriate Drop Precedence group from the TOS values. However, you have to be a little bit careful, since there are 4 TOS bits. Combining this with the 3 bits from IP Precedence gives you 7 bits to work with, while DSCP only uses the first 6. For example, looking at the bit values that give AF11 in Table B.3, you can see that the last three bits are 010. So the corresponding TOS value would be 0100, which is 4 in decimal, or maximum throughput.

In Table B.3, you can see that a TOS value of 4, maximum throughput, always gives the lowest Assured Forwarding Drop Precedence. Selecting a TOS value of 8, minimum delay, gives Medium Drop Precedence in all classes. And you can get the highest Assured Forwarding Drop Precedence value by setting a TOS value of 12, which doesn't have a standard name in the TOS terminology.

There is reasonably good interoperability between the Assured Forwarding DSCP variables and the combination of IP Precedence and TOS, which is good because it is impossible for a router to tell the difference in general. Only the three top priorities of IP Precedence are not represented, and that is simply because these DSCP values are used for guaranteed delivery services.

The biggest difference between the TOS and Assured Forwarding models is that where the Assured Forwarding model is used to define a type of queueing, the TOS model is used to select a particular path. TOS was intended to work was with a routing protocol, such as OSPF, in selecting the most appropriate path for a particular packet based on its TOS value. That is, when there are multiple paths available, a TOS-based OSPF (such as the version suggested in RFC 2676) would attempt to make a reasonable TOS assignment to each of them. Then, if the router needed to forward a packet that was marked with a particular TOS value, it would attempt to find a route with the same TOS value. Note that Cisco never incorporated this type of functionality into its OSPF implementation, however. So, if TOS is going to have an effect on how packets are forwarded, you have to configure it manually by means of Policy-based routing.

This was the historical intent for TOS, but in practice most engineers found that it was easier to just use the TOS field to influence queueing behavior rather than path selection. So the IETF developed the more modern and useful DSCP formalism.

Assured Forwarding introduces the concept of Per-Hop Behavior (PHB). Each DSCP value has a corresponding well-defined PHB that the router uses not to select a path, but to define how it will forward the packet. The router will forward a packet marked AF13 along the same network path as a packet marked AF41 if they both have the same destination address. However, it will be more likely to drop the AF13 packet if there is congestion, and it will forward the AF41 packet first if there are several packets in the queue.

From this, it should be clear why it is easier to implement Assured Forwarding than TOS-based routing on a network.

RSVP

Reservation Protocol (RSVP) is a signaling protocol that allows applications to request and reserve network resources, usually bandwidth. The core protocol is defined in RFC 2205. It is important to remember that RSVP is used only for requesting and managing network resources. RSVP does not carry user application data. Once the network has allocated the required resources, the application marks the packets for special treatment by setting the DSCP field to the Expedited Forwarding (EF) value, 101110.

The process starts when an end device sends an RSVP PATH request into the network. The destination address of this request is the far end device that it wants to communicate with. The request packet includes information about the application's source and destination addresses, protocol, and port numbers, as well as its quality of service requirements. It could specify a minimum required bandwidth, and perhaps also delay parameters. Each router along the path picks up this packet and figures out the best path to the destination.

Each router receiving an RSVP PATH request replaces the source address in the packet with its own, and forwards the packet to the next router along the path. So the QoS parameters are requested separately on each router-to-router hop. If a router is able to accommodate the request, it sends back an RSVP RESV message to the requester. For all but the first router on the path, the requester is the previous router. If a router receives one of these RESV packets, it knows that everything upstream from it is able to comply with the request. If it also has the resources to accommodate the requested QoS parameters, it sets aside the resources and sends an RESV packet to its upstream neighbor. And it sends an RSVP CONFIRM message downstream to acknowledge that the request will be honored. The routers pass PATH, RESV, and CONFIRM packets to one another periodically to ensure that the resources remain available.

If a router is not able to set aside the requested resources for whatever reason, it rejects the reservation. This may result in the entire path being rejected, but it can also just mean that the network will reserve the resources everywhere except on this one router-to-router link.

Clearly it would be counterproductive if every device on the network could request as much bandwidth as the wanted, whenever they wanted. This would leave few network resources for routine applications. So usually when you configure a router for RSVP, you just set aside a relatively small fraction of the total bandwidth on a link for reservation. Further, you will often want to restrict which source addresses are permitted to make RSVP requests.

Because RSVP makes its reservation requests separately on each link, it can easily accommodate multicast flows. In this case, you have to be careful that the periodic updates happen sufficiently quickly that any new multicast group members won't have to wait long before they start to receive data. Please refer to Chapter 23 for more detailed discussion of multicast services.

RSVP is an extremely useful technique for reserving network resources for real-time applications such as Voice over IP (VoIP). However, because it forces the routers to keep detailed information on individual data flows, it doesn't scale well in large networks. RSVP is most useful at the edges of a large network, where you can reserve bandwidth entering the core. However, you probably don't want it through the core of your network.

In large networks, it is common to use RSVP only at the edges of the network, with more conventional DSCP-based methods controlling QoS requirements in the core.