Do You Hear What I Hear?�Part VII: Differentiated Services

Continuing with our series on VoIP Quality of Service (QoS), our previous installments have looked at some of the key factors surrounding the quality of the voice connection:

Part I: Defining QoS
Part II: Key Transmission Impairments
Part III: Dealing with Latency
Part IV: Measuring “Toll Quality”
Part V: Integrated Services
Part VI: Resource Reservation Protocol

In our two most recent tutorials, we examined the Integrated Services (intserv) project of the Internet Engineering Task Force (IETF), and the Resource Reservation Protocol (RSVP) defined in RFC 2205, which is used by the intserv architecture to reserve network resources along the path from the sender to receiver. Another IETF development called Differentiated Services (diffserv) is also designed to support QoS requirements, but in a much different way. As we discovered in our discussion on intserv, all nodes from the sender to the receiver must support that architecture, along with RSVP, in order for network resources to be successfully reserved. In other words, if you wish to send traffic from New York to Los Angeles, all of the intervening routers much understand RSVP in order to reserve the bandwidth that you need for this connection. If some router in the Midwest does not support RSVP, you immediately have a challenge on your hands. Thus, we could say that intserv does not scale well, and as the internetwork grows, the end-to-end communication becomes more complex.

Differentiated Services takes a different approach to the QoS challenge. Instead of relying upon some type of bandwidth reservation protocol, it leverages a little used field within the Internet Protocol (IP) header to accomplish its goals. Three key RFC documents detail the operation of diffserv:

  • RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
  • RFC 2475: An Architecture for Differentiated Services
  • RFC 3260: New Terminology and Clarifications for Diffserv

To quote from RFC 2474:

“Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop.”

In other words, diffserv could be described as a “built in solution”, where interv could be described as a “bolted-on solution” (with RSVP being the bolted on solution requiring flow states and per-hop signaling). In a nutshell, the idea is to differentiate between multiple types of Internet service. Those services could be distinguished in a number of ways, including: quantitative network characteristics such as packet delay, jitter or loss; some type of a priority scheme based upon application requirements; or financial requirements and/or Internet service pricing levels.

The diffserv architecture defines network service provisioning policies that govern how the traffic streams are allocated a particular amount of available bandwidth, how that traffic is marked, and how it is conditioned upon entry into the network. The algorithms then classify packets for a specific traffic type, and mark the packets accordingly. Packets then receive a per-hop forwarding operation along the path from source to destination based upon that packet marking.

The key to diffserv operation is a field within the IPv4 header called the Differentiated Services (or DS) field, and a corresponding field within the IPv6 header called the Traffic Class field. For IPv4, this field was previously known as the Type of Service, or TOS field, which was relevant at the time that IP was designed in support of government and military networks, but became less useful (and often ignored by routers) as IPv4 moved into mainstream business applications. Similarly, the architects of IPv6 recognized the need for this type of QoS function, and built this functionality into the protocol from the ground up.

The DS field is eight bits in length, with six of these bits currently defined, and two bits that are not currently used by diffserv. The six defined bits are called the Differentiated Services Code Point, or DSCP. With six bits available, a total of 64 distinct codepoints are available, thus allowing 64 Internet service distinctions. These codepoints are divided into three pools: Pool 1, with 32 codepoints to be standardized by the IETF, Pool 2, with 16 codepoints that are intended for local or experimental use, and Pool 3, with 16 codepoints that are presently designated for experimental or local use, but may be used for standardized assignments in the future. For specific details on the DSCP assignments, check out the Internet Assigned Numbers Authority (IANA) site at

In addition, many other RFC documents have been written that describe specific diffserv applications and implementations, and can be found at the RFC Editor site,, with a search for “differentiated services.” In our next tutorial, we will look at another QoS-enhancing protocol, Multiprotocol Label Switching, or MPLS.

Copyright Acknowledgement: © 2005 DigiNet ® Corporation, All Rights Reserved

Author’s Biography
Mark A. Miller, P.E. is President of DigiNet ® Corporation, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.

Latest Articles

Follow Us On Social Media

Explore More