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:
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:
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.
Diffserv also comes with it's own nomenclature and a few acronyms:
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.