Some weeks ago I described 802.1p. It's a way to color traffic on your local network segment. If you have network equipment aware of this tag, you can get strict prioritization at these hops. Still, the tag is at layer-2 and not layer-3; your average IP router won't do anything with the tag. It's quite likely it won't even know there was a tag on the incoming traffic.
What then? How do we get a router to give preferential treatment to some of the traffic?
Were you to take a netmon capture of IP traffic, you might notice the following:
This is the first packet of a new TCP connection. I've highlighted a part of the IPv4 header which netmon calls the Type of Service. This field is the byte right after the version header. Notice the names: Precedence, Monetary Cost, Reliability, Throughput and Delay. If you think these read like characteristics for the quality of service of the packet, you'd be right. As the name says, it is after all the Type of Service field. This specific parsing of the byte/octet matches the description in section 3 and section 4 of RFC 1349; a proposed standard. RFC 1349 itself is an update to the grand parent of all RFCs: RFC 791; the Internet Protocol.
Since I now have your attention, note: RFC 1349 is obsolete. If your vernacular includes this interpretation of TOS, it shouldn't anymore. RFC 2474, another proposed standard, is the replacement. What is a proposed standard? From RFC 2026:
A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances.
In other words, the community has agreed that RFC 2474 is a step up from TOS. We agree with the community. However, I admit the community has not made this latest RFC a standard. As such, there's a lot of confusion. For example, you can still find references to TOS in many places at Microsoft (such as Netmon). Our team is actively trying to change this mindset.
So what is in RFC 2474? Differentiated Services; also known as Differentiated Services Code Points (DSCP). Here are a few things to know, quoted straight from section 3 of this RFC.
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 [Per Hop Behavior] 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:0 1 2 3 4 5 6 7+---+---+---+---+---+---+---+---+| DSCP | CU |+---+---+---+---+---+---+---+---+DSCP: differentiated services codepointCU: currently unused
Now we know how to read that byte (the one in black in the figure above) for DSCP. DSCP is a 6 bit value. It therefore ranges from 0 to 63. The other 2 bits don't matter now. But what should we do with the specific value? Let's read a bit more of the RFC.
With some exceptions noted below, the mapping of codepoints to PHBs MUST be configurable. A DS-compliant node MUST support the logical equivalent of a configurable mapping table from codepoints to PHBs. PHB specifications MUST include a recommended default codepoint, which MUST be unique for codepoints in the standard space (see Sec. 6). Implementations should support the recommended codepoint-to-PHB mappings in their default configuration. Operators may choose to use different codepoints for a PHB, either in addition to or in place of the recommended default. Note that if operators do so choose, re-marking of DS fields may be necessary at administrative boundaries even if the same PHBs are implemented on both sides of the boundary.
In effect, there is a recommended way to affect a packet based on its DSCP value however routers can (and generally do) have mechanisms for network administrators to change this recommended mapping. In practice, network administrators configure routers in whatever way they want. That is our takeaway: with DSCP, network administrators configure the exact behavior at each routing hop of their network; a lot more freedom than TOS or 802.1p gave us.
Obviously, I've skimmed through a bunch of RFCs to extract a view of the current state of things. If you want to know more about DSCP, TOS and their relation, I encourage you to read the RFCs yourself; there is no better way to learn about this topic.
I have a question though as I wrap up: how does an administrator get the stations to color their traffic with DSCP?