I was out on a call this morning and the network admin was as mad as a country music fan at a Iron Maiden concert. The users thought the VOIP system they installed sucked. Truth is it sucked worse then running out of beef jerky on football Sunday. If MOS scores could be in the negative, theirs would have been in the Kelvins. They thought that with high speed 10GB switches they did not need QoS in their network. On paper that would make sense, however, when packets start hitting the switch, all bets are off until they start existing. I have designed switching ASIC architectures for awhile, and every protocol specific packet is handled a little differently in the switch itself. That is just how ASIC design is.


Networks are like kids; they start small and grow big then don’t listen to what you have to say, then wreck your brand new Dodge Hemi truck on the first day school, step on your MegaBass Destroyer fishin rod and...oh sorry, Dr. Phil moment there.. Anyway, To keep up with the demand vendors have been building faster switches with deeper buffers every single year. This is an example of Moore's Law at its finest. But is that enough? Of course any Account Manager will say YES! Buy more Cisco, problem solved. But a realistic network engineer needs to consider the role Quality of Service (QoS) will play in their network. Most folks understand how 802.1p works. DiffServ seems to be the big unknown in the world of QoS.


The real term is Differentiated Services but the alpha geek crowd just says DiffServ. If you say DiffServ folks know you are down with the set yo. If you say Differentiated Services folks will point you to the server admin crowd… DiffServ is concerned with classifying packets as they enter the local network. This classification then applies to a flow of traffic where a flow is defined by 5 elements:


- Source IP address


- Destination IP


- Source port


- Destination port


- Transport protocol.


A flow that has been classified or marked can then be acted upon by other QoS mechanisms. Multiple flows can therefore be dealt with in a multitude of ways depending on the requirements of each flow. Voice this way and data that way, etc… DiffServ uses a Code Point (the cool way to say this is DSCP) to determine the per hop behavior of the flow. Kinda like how you can determine who does what on Star Trek by what color shirt they wear. Blue is Medical, Gold is Command and Red is the one that always gets killed off. Back to DSCP, there are 64 total DSCP values. They range from 0-63. Remember that a high DSCP value does is not equal to a high QoS queue. However, understand that in the Assured Forwarded (more to come…) there are three drop probabilities. I said this before, but let me say it again and add some acronym vocabulary enhancers. The DSCP determines the Per-Hop Behavior (PHB) of a flow. (QoS represent yo...) In a nutshell, packets are first classified according to their current DSCP. Then they are separated into queues where one queue may be routed via a marking mechanism and another queue may be examined more closely. After further examination additional packets may be sent for marking or be sent direct to the shaping/dropping mechanisms where all packets end up before leaving the interface. Just like on Star Trek NG, everyone always ends up in 10Forward to pound down some alien Newcastle Nutbrown Ales after a mission.


How cool is that! Differentiated Services provides a simple and quick (all be it) coarse method of classifying services of various applications. Of course there is more to then that, so let’s get geeky with it man! You don’t get off that easy… There are currently two standard per hop behaviors (PHBs) defined that effectively represent two service levels. Although others are possible, but these are the most common and most widely used.


• Expedited Forwarding (EF): This is like riding in First Class on a long trip. This is the best possible. EF has a single codepoint. EF minimizes delay and jitter and provides the highest level of aggregate quality of service and guaranteed bandwidth. Any traffic that exceeds the traffic profile (which is defined by local QoS policy) is discarded.


• Assured Forwarding (AF): This is like riding in coach with extra leg room for business class. AF has four classes and three drop precedence within each class (so a total of twelve codepoints). Excess AF traffic is not delivered with as high probability as the traffic “within profile,” which means it may be demoted but not necessarily dropped.


- Nothing (Sk): Is like riding in the Family Truckster with *********** In Law to WollyWorld. (just kidding...)


As you are mapping your DSCP’s ensure that you understand which traffic flows to map to EF and which flows to map to AF. Although DiffServ is not backward compatible with ToS, DiffServ can be used to actually replace Type of Service if it is mapped correctly. I have included a chart if you ever need to do this:


DSCP Precedence Purpose


0 0 Best effort


8 1 Class 1


16 2 Class 2


24 3 Class 3


32 4 Class 4


40 5 Express forwarding


48 6 Control


56 7 Control


DiffServ assumes the existence of a service level agreement (SLA) between networks that share a border. The SLA establishes the policy criteria, and defines the traffic profile. It is expected that traffic will be policed and smoothed at egress points according to the SLA, and any traffic “out of profile” (i.e. above the upper-bounds of bandwidth usage stated in the SLA) at an ingress point have no guarantees (or may incur extra costs, according to the SLA). The policy criteria used can include time of day, source and destination addresses, transport, and/or port numbers (i.e. application Ids). Basically, any context or traffic content (including headers or data) can be used to apply policy.


The best part of DiffServ is its simplicity to prioritize traffic and its flexibility and power. When DiffServ is the primary QoS parameter, specific application types can be used to identify and classify traffic, it will be possible to establish well-defined aggregate flows that may be directed to fixed bandwidth pipes. As a result, you could share resources efficiently and still provide guaranteed service. Then your users will give you the best compliment in the world: A silent phone...Newcastle and beef jerky time!



Jimmy Ray