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.