This is part 3 of a series on the ToS field (i.e. Differentiated Services Field) of IP frames. I’m getting closer to how it relates to NetFlow and sFlow. Make sure you have already read Part 1 and Part 2 of this blog.
ToS part 3
In this blog I copy largely from RFC 2474, which was written in 1998. I discuss how 6 bits of the 8-bit ToS is now the Differentiated Services Code Point. See the screen capture below from my first blog. This is where we are today however, many of us still refer to this field as ToS (i.e. type of service). Sometimes it is called the Differentiated Services Field (DSF) but, not as often.
Why do we keep calling it ToS? Well, with IPv6 calling it “Traffic Class” and seeing that many DSCP documents still call it the ToS field, this name has just sort of stuck. BTW: Some NetFlow Analyzers call it QoS, including ours, and I feel this is incorrect. QoS is really about configuring end-to-end quality of the connection or measuring end-to-end quality. I’m not going to get into the semantics of its use. Basically, in Scrutinizer 7 we call it something else 🙂 because we feel the techies know what we are talking about. Just remember this; DSCP is only 6 bits of this 8-bit ToS field (DSCP is not equal to ToS)!
Let’s bring back that same WireShark packet capture from blog 1. Click on the image below:
Notice above the ECN Explicit Congestion Notification field. It was unused in 1998 but, in 2001 RFC 3168 found use for these two bits. I could make this an eight-part blog and digress on this but, I think I’ll finish up this series first. 🙂
Anyway, those ECN bits are like the MBZ bits in part 2 of this blog. They are set to zero. However, today you will capture data with these bits set but, we are referencing an RFC from 1998. Let’s not go there yet! For this blog, we are calling these two bits currently unused (CU). The ECN bits shouldn’t be a problem for your NetFlow collector.
What the DiffServ
DiffServ is an architecture, not a field in the packet. It takes advantage of the 6-bit DSCP field within the ToS. In short, it is an architecture involving the set up of individual routers to help guarantee end-to-end QoS of connections. Do not confuse it with IntServ which involves the RSVP protocol to set up end-to-end connections prior to data transfer. IntServ is a bit similar to the way phone switches work. Just remember that DiffServ involves provisioning each individual router and flows are autonomous and could be prioritized differently from one hop to the next. DiffServ is the most popular of the two.
Goal of differentiated services
The primary goal of differentiated services is to allow different levels of service to be provided for traffic streams on a common network infrastructure. A variety of techniques may be used to achieve this, but the end result will be that some packets receive different (i.e. better) service than others.
Differentiated services field definition
The DS field comes about in RFC 2474 which is intended to supersede the existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet [IPv6]. It won’t matter to your NetFlow Analyzer. Any good NetFlow analyzer will come preconfigured with all the necessary definitions.
Six bits of the DS field (i.e. ToS) are used as a Code Point (DSCP) to select the PHB (per-hop behavior) a packet experiences at each node. So basically, the Quality of Service of your telephone connection with DiffServ is decided individually by each router in the path (i.e. connectionless). This is unlike analog calls (connection oriented) where initial call setup ensures guaranteed QoS through all switches prior to allowing the call to take place else, “all circuits are busy now, please try your call again later”. Your call can’t be guaranteed in today’s VoIP, rather the phone just fights with everything else on the network for bandwidth and call quality can suffer. It kills me that it was designed this way especially when the telephony world paved the way. Cisco tried with IntServ but, found it didn’t scale that well. I discussed the problem in a prior blog “Connection Oriented Networking” and how this is re-enforced by Dr. Lawrence Roberts. Rant, Rant, Rant. :/ Ok, back to topic.
A two-bit currently unused (CU) field is reserved and its definition and interpretation are outside the scope of this RFC. 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. I like to call the CU field the CUU (i.e. Currently Unused Usually). We see these bits being set from time to time and in some cases it can raise heck with your NetFlow reporting if it isn’t dealt with properly. Sorry I’m digressing on this so much…..anyway, back to 1998!
The DS field structure is presented below:
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | DSCP | CU | | | | +-----+-----+-----+-----+-----+-----+-----+-----+
DSCP: differentiated services code point
CU: currently unused (usually 🙂 )
The Router cares about DSCP
In this RFC, there is a greater detail discussion on how PHB (see above on Per Hop Behavior) or router forwarding logic can impact the DSCP value of the flow. Routers could have multiple routes to reach a destination. Each route may have a different quality of service. After deciding which route a router should use, the DSCP value could be changed. Here are some considerations:
- If a code point observed is not mapped to a standardized or local use PHB, it SHOULD be mapped to the Default PHB. YIKES! If the DSCP value isn’t in the table, it will get default quality of service. Read RFC 2475 on “An Architecture for Differentiated Services” to learn more about how network nodes along the transit path apply the appropriate priority forwarding behavior using the DSCP value within the packet’s header. You’ll need coffee for that one but, the content is good reading.
- A packet initially marked for the Default behavior MAY be remarked with another code point as it passes a boundary into a DS domain so that it will be forwarded using a different PHB within that domain, possibly subject to some negotiated agreement between the peering domains. Wow! The routers may change the DSCP value of packets as they are forwarded from router to router. Sounds similar to CBQoS .
“Setting up DiffServ for VoIP and video can be both a science and an art. You don’t need to use all the DSCP values; many times starting off using three or four is plenty. If nothing else, make sure VoIP has a DSCP value of EF. You have to be careful because if you don’t assign the DSCP values needed by the business, anything undefined is given a DSCP value of 00. I often point our customers to the ‘Classifying VoIP Signaling and Media with DSCP for QoS‘ page on Cisco’s web site”
Solutions Architect – CDW
Cisco Systems CCIE# 15255
E-mail: [email protected]
Today, you can use CBQoS on each router to prioritize network traffic such as VoIP to help ensure telephone calls don’t suffer from jitter or poor MOS. Then, you can use NetFlow in combination with ingress and egress flows to confirm that DSCP values were changed. I’ll dive into this in blog 4.