Combining TOS and IP Precedence to Mimic DSCP

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.

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