In Chapter 11, we discussed 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.
It is easy to get confused between the different uses of the term "TOS." Sometimes it refers to the entire byte and sometimes to just the four bits that describe forwarding behavior. To help reduce the confusion, we call the four-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, which are strictly reserved for keepalive packets, routing protocols, and other important network traffic. The network must always give these packets higher priority than any application packets because no application will work if the network loses its topology information.
|
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 select a different path. So the standard was changed in RFC 1349 to prevent combinations of TOS bits.
|
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 2 unused bits. As we 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 3 bits is 4 or less, the packet uses Assured Forwarding (AF). If the value is 5, 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 3 bits specify the forwarding class. A higher value in this sub-field results in a higher forwarding precedence through the network. The remaining 3 bits specify Drop Precedence. The higher the Drop Precedence, the more likely the packet will be dropped if it encounters congestion.
|
Class 1 |
Class 2 |
Class 3 |
Class 4 | |||||
|---|---|---|---|---|---|---|---|---|
Drop Precedence |
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 3 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 FECN (Forward Explicit Congestion Notification) and BECN (Backward Explicit Congestion Notification) 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 were 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.
|
|
|
| Top |