QoS: Differentiated Services Model

I cannot cover Diffserv without ever mentioning his predecessor, the Integrated Services model or Intserv. The latter never seen global deployment because of scalability issues inherent of its architectural design. The idea behind Intserv was to provide end-to-end QoS guarantees to applications like voice, video and conferencing. Intserv require a signaling protocol, namely RSVP to describe to the network what are the QoS requirements and which flows needs special treatments. Every routers along the path have to support the signaling protocol, and have to keep reservation states in memory, which obviously reduce the scalability of the protocol. It's the major reason why Intserv never scaled beyond small-to-medium sized networks. Although the Intserv model never seen widespread use, the Resource Reservation Protocol (RSVP) is extensively used today, in particular in MPLS backbone for traffic engineering and label signaling.

The IP protocol has undergoes a number of changes regarding QoS handling. RFC791 which defines version 4 of the IP protocol, outline the Type of Service field as follow:

RFC791 IP Header
RFC791 Type of Service Field

The 8 bits header field, or ToS byte is composed of the 3-bits IP precedence field, the Delay (D), Throughput (T) and Reliability (R) bits, and finally of two unused/reserved bits. The primary purpose of the DTR bits was to implement ToS-based routing. However, ToS-based routing never seen widespread adoption and its support is relatively scarce and rare in networking gears. The industry however did adopted the IP precedence field, primarily because they needed basic QoS handling of interactive and network-control traffic.

Around 1998, the IETF released several RFCs to describe a new QoS model, named Differentiated Services model or Diffserv. RFC2474 redefines the IP ToS field, with 6 bits of Differentiated Services Code Point, as shown below:

RFC2474 Redefined ToS Byte

In contrast to Intserv, Diffserv doesn't require any signaling protocol. It doesn't require any states to be maintained either, which allow for high-scalability. Diffserv mainly defines the mechanisms to mark and classify flows of traffic.

More recently, RFC3168 enabled the last two unused bits to allow for Explicit Congestion Notification (ECN), a feature already present on ATM and Frame-Relay.

On the IPv6 side, RFC2460 defines a 8-bits header field named 'Traffic Class'. At the time RFC2460 was written, the Diffserv experiments were underway, therefore the IPv6 header field is merely a copy of the IPv4 ToS byte.

RFC2460 IPv6 Packet Header

Diffserv also comes with it's own nomenclature and a few acronyms:

  • Differentiated Services Code Point - DSCP: You already know that one. This correspond to the six bits carried in the IPv4 ToS or IPv6 Traffic Class header field. The DSCP is used to mark the packets according to the class they belong to. Sort to speak the DSCP helps identify the PHB.
  • Per-Hop Behavior - PHB: It describes how a network entity handles packets that belong to a specific Behavior Aggregate (BA).
  • Behavior Aggregate - BA: A collection of packets with the same code point that require the same QoS treatment.
  • Diffserv Domain: A contiguous set of network entity under a common QoS policy.

The value of the DSCP is left entirely to the Diffserv domain's administrator. As the code is used for marking and identification of traffic flows that belong to a common BA, you are free to use the values you want. However, RFC2547 and RFC3246 defines respectively the Assured Forwarding and the Expedited Forwarding PHB groups. The former provides low latency and low-loss guarantees to delay-sensitive applications like voice and video conferencing; the latter provides forwarding assurances to mission-critical traffic. The AF PHB group provides four independent classes (AF1, AF2, AF3, AF4). Within each AF class, an IP packet can be assigned three different drop probabilities, from low (AFx1), medium (AFx2) to high (AFx3). The drop probability as the name imply, is the statistical probability your packet will be dropped when congestion occurs. Note, the IANA maintains a registry of standardized DSCP values, along with their PHB.

Most equipments vendors actually provides some tools to easily mark and classify packets according to their PHB or EF/AF classes. In Cisco IOS, you can mark and match packets belonging to a class of traffic, by directly entering the class name inside a service-policy:

(config-pmap-c)#set dscp ?
  <0-63>     Differentiated services codepoint value
  af11       Match packets with AF11 dscp (001010)
  af12       Match packets with AF12 dscp (001100)
  af13       Match packets with AF13 dscp (001110)
  af21       Match packets with AF21 dscp (010010)
  af22       Match packets with AF22 dscp (010100)
  af23       Match packets with AF23 dscp (010110)
  af31       Match packets with AF31 dscp (011010)
  af32       Match packets with AF32 dscp (011100)
  af33       Match packets with AF33 dscp (011110)
  af41       Match packets with AF41 dscp (100010)
  af42       Match packets with AF42 dscp (100100)
  af43       Match packets with AF43 dscp (100110)
  cos        Set packet DSCP from L2 COS
  cs1        Match packets with CS1(precedence 1) dscp (001000)
  cs2        Match packets with CS2(precedence 2) dscp (010000)
  cs3        Match packets with CS3(precedence 3) dscp (011000)
  cs4        Match packets with CS4(precedence 4) dscp (100000)
  cs5        Match packets with CS5(precedence 5) dscp (101000)
  cs6        Match packets with CS6(precedence 6) dscp (110000)
  cs7        Match packets with CS7(precedence 7) dscp (111000)
  default    Match packets with default dscp (000000)
  ef         Match packets with EF dscp (101110)
  qos-group  Set packet dscp from QoS Group.
  tunnel     set tunnel packet dscp

On Junos devices, the DSCP to forwarding-class mapping is maintained in what is called a code-point alias. Code-point alias can be easily and quickly re-used in your CoS policy. You can print code point aliases using the following command:

show class-of-service code-point-aliases dscp

This conclude this article on the Diffserv model. The whole picture will become more evident when we will cover QoS handling and forwarding treatments.

About the author Nicolas Chabbey

Nicolas Chabbey is a Network Engineer certified with Cisco Systems and Juniper Networks. He has begun his career in 2003, and has designed, implemented and maintained networks for enterprises and service providers. When he is not behind a computer, he is riding his mountain bike across the Swiss alps.

Previous Home Next


blog comments powered by Disqus