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