depoint currently unused Here's where the beauty of the design comes into play. Let's assume our TOS field contains the bits 10100000. The TOS field is always eight bits (an octet). If we look at it using the rules of IP precedence, only the first three bits are significant, giving us a value of 5. If we look at it using the rules of diffserv, however, the first six bits are significant, giving us a value of 40. And if we look at the entire field, with all eight bits being significant, we get a value of 160. The relationship between IP precedence, diff- serv, and the TOS field is shown in Figure 31-6. DiffServ IP precedence TOS field (3 bits) (IP preference) 101000 (6 bits) (DSCP) 10100000 bits) = 160 (TOS) They are all the same binary digits, but in different field lengths, they represent different decimal values! Figure 31-6. Different decimal values depending on the number of significant bits in the TOS field Chapter 31: Introduction to QoS Knowing that a value of 160 in the TOS field equals an IP precedence of 5 can be valuable when you're looking at packet captures. Because the field is known only as TOS to IP, the packet-capture tool will usually report the TOS value. CoS is a Layer-2 form of QoS. CoS works under the same principles as IP precedence in that there are only eight values determined within a three-bit field. The difference that these bits are in the 802. 1P frame header, not the IP header. CoS values are Ethernet-specific, SO they will be lost if frames are forwarded out of Ethernet networks. The good news is that because they map SO perfectly to IP precedence values, rules can be created to read CoS values and translate them to IP precedence values. In Cisco catalyst switches, there can be multiple queues for each Ethernet interface. CoS values can be mapped to these queues, allowing for prioritization. Ethernet pri- orities can be different from WAN-link priorities, though in practice, they're usually mapped one to one. Table 31-1 shows how CoS, IP precedence, and DSCP values are related. If 