standards, and three bits of IP precedence were fine. But eventually, the issue of scal- ability became apparent as users began to want more than eight levels of distinction in their priorities. So, along came RFC 2474, which redefined the TOS field: 3. Differentiated Services Field Definition A replacement header field, called the DS field, is defined, which is intended to supersede the existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet [IPv6]. Six bits of the DS field are used as a codepoint (DSCP) to select the PHB a packet experiences at each node. A two-bit currently unused (CU) field is reserved and its definition and interpretation are outside the scope of this document. The value of the CU bits are ignored by differentiated services-compliant nodes when determining the per-hop behavior to apply to a received packet. The DS field structure is presented below: DSCP: differentiated services codepoint 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, diffserv, and the TOS field is shown in Figure 29-6. Knowing that a value of 160 in the TOS field equals an IP precedence of 5 can be valuable when 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 prece- dence, in that there are only eight values determined within a three-bit field. The difference is that these bits are in the 802. 1P frame header, not the IP header. CoS values are Ethernet