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