Differentiated Services

The previous tutorial explored the issue of delivering QoS over IP-based networks ("Lesson 157: The Resource Reservation Protocol"). Now, we'll look at another approach to this goal: Differentiated Services (DiffServ).

DiffServ was designed to provide a simpler, more coarse approach to establishing differentiated classes of service for Internet data. In the Integrated Services (IntServ) model, resources are allocated to individual flows, which can lead to scalability limitations. In DiffServ, traffic is divided into a small number of forwarding classes, and resources are allocated on a per-class basis. The desired performance levels are achieved through the proper mix of provisioning, prioritization, and admission control. This is in contrast to techniques such as end-to-end resource reservation, which is the foundation of RSVP.

DiffServ was designed to provide service to aggregate forwarding classes comprising multiple traffic flows. Simplicity is fostered by the fact that these flows are grouped into a relatively small number of aggregates that receive a limited number of differentiated treatments (defined via policies) throughout the network.

One of DiffServ's goals was to eliminate the need for per-flow resource reservation state, as well as signaling in each router along a data path . Most classification and policing is done at the network edge. In the core , routers inspect only one field in the IP headerthe DiffServ fieldto determine where to send the packet next , as opposed to storing information about each individual flow. (The DiffServ field is also referred to as the DS field or DS byte.)

The ultimate aim of the DiffServ architecture is to simplify forwarding in the core and to place the processing burden that accompanies traffic classification and profiling at the network edge. This architecture is more conducive to facilitating the levels of scalability required for today's networks than many possible alternative approaches. (The DiffServ architecture is described in detail in the IETF's RFC 2475.)

Moving To The Head Of The Class

When traffic enters the DiffServ network's ingress interface, it's classified and subjected to a preconfigured admission process, and then conditioned to meet policy requirements in accordance with a specific classification. (Conditioning is also referred to as shaping or policing.)

The data stream is then assigned to a behavior aggregate. This is done by marking the IDS fields of the packets' IP headers with the corresponding Differentiated Services Code Point (DSCP). The DSCP value initiates a specific Per-Hop Behavior (PHB) in devices in the network and classifies the packet service level. (The term PBH refers to specific forwarding treatments that occur at a particular node.)

In DiffServ, the 8-bit Type of Service (ToS) field in the IPv4 header is supplanted by the DS field, which contains a value that DiffServ-enabled routers use to determine a specific forwarding treatment (PHB) at each node along a traffic path (see figure). The first six bits of the DS field comprise the DSCP. This is mapped to the PHB, which is received by the packet containing this field at each DiffServ-aware node. The values within the DSCP field are called code points.

Figure 1: In Differentiated Services (DiffServ), the DS field (or DS byte) shown in part A of this diagram replaces the 8-bit Type of Service (ToS) field in the IPv4 header (shown in part B). The DS field contains a 2-bit Currently Unused (CU) field and the Differentiated Services Code Point value, which triggers certain treatments of the packet in devices within the network.

The last two bits in the DS field are designated Currently Unused (CU), and support legacy (non-DiffServ-enabled) devices that use the original ToS byte to determine forwarding treatment. The DS field can have up to 64 different values. (For more information on the DS field, see RFC 2474.)

The DS field is ultimately a fundamental ingredient in ensuring that Service Level Agreements (SLAs) between network subscribers and service providers are met. On a more granular level, Traffic Conditioning Agreements (TCAs, basically subsets of an SLA) are designed to help achieve this goal. The TCA may include parameters regarding traffic profiles, performance metrics (such as latency, throughput, and drop priorities), and instructions on how out-of-profile packets will be handled. The TCA can also describe additional traffic-handling services supplied by the service provider. In addition to what the TCA specifies, an SLA may also include specific availability levels, monitoring provisions, and accounting and billing agreements.

Terms And Conditions

Two fundamental processes in DiffServ implementation are classification and conditioning (see Figure 2). In DiffServ, traffic is classified and conditioned at the network ingress interface based on the TCA parameters that exist between the service provider and the network subscriber.

Figure 2: In the DiffServ process flow, packets are classified and then conditioned to ensure that they conform to the classification's particular policy requirements. Classification is based on Traffic Conditioning Agreements (TCAs) between service providers and network subscribers. Conditioning, also called traffic shaping or policing, involves metering, marking, shaping, and dropping.

In DiffServ, a classifier selects packets based on information in the packet header correlating to preconfigured admission policy rules. There are two primary types of DiffServ classifiers : the Behavior Aggregate (BA) and the Multi-Field (MF). The BA classifier bases its function on the DSCP values in the packet header. The MF classifier classifies packets based on one or more fields in the header, which enables support for more complex resource allocation schemes than the BA classifier offers. These may include marking packets based on source and destination address, source and destination port, and protocol ID, among other variables .

Conditioning involves metering, marking, shaping, and dropping. A meter monitors traffic based on how the traffic is classified. It determines whether classified traffic is meeting the specified traffic profile, and can also gather statistics on flows for accounting and billing functions.

A marker sets the packet's DS byte at a specific value. Packets may be marked for a particular flow to help ensure the proper sequence of PHBs for that flow. The marker can also be used to re-mark packets (for example, to change the existing value of a DS field), or to demote packets that fall outside the traffic profile. Packets that travel through a series of different domains may need to be re- marked repeatedly to ensure that they're in compliance with the various traffic profiles located at multiple domain boundaries. (A domain is a set of nodes that operates under a common set of service provisioning policies and PHB definitions.)

The shaper function keeps packets in a queue to ensure that traffic is in accordance with the traffic specification, often storing large bursts of packets until they can be safely released into the network.

When a flow violates the traffic specification, excess packets may simply be dropped from that flow. Alternatively, these packets may be delayed or reduced in priority level. Such actions are taken when the flow exceeds the negotiated transmission rate, or when a burst exceeds a maximum limit.

A key aspect of DiffServ implementation is determining which packets should receive forwarding priority. There are two primary types of forwarding: Expedited Forwarding (EF) and Assured Forwarding (AF). EF provides minimal delay, jitter, and packet loss, and assured bandwidth. In EF, the arrival rate of packets at a node must be less than the output rate at that node. Packets that violate the traffic profile are dropped or delivered out of sequence. EF is suitable for delay-sensitive applications such as voice and video.

In AF, there are four classes, each containing three drop precedences and allocated certain amounts of buffer space and bandwidth. Drop priorities are assigned to help determine which packets should be dropped during congested periods. Out-of-profile packets are dropped according to drop precedence; those with the highest drop priority are dropped first, and those with lower drop priorities follow.

Entering The Diffserv Domain

In DiffServ, SLAs between network subscribers and service providers establish policy criteria and define traffic profiles. Traffic is typically classified and conditioned at the network ingress interface, but when traffic spans multiple domains, some of these processes may be performed at the network egress interface, or at interior DiffServ-enabled nodes. In some cases, out-of-profile packets may be forwarded at an extra charge to the sender. Policy criteria may include source and destination addresses, port numbers , and time of day.

The Internet and some enterprise networks contain multiple domains. Bandwidth provisioning across multiple domains can be challenging, if the desired level of end-to-end QoS is to be achieved. The profile of traffic that crosses domain borders is specified in the SLA that exists between two domains. But as traffic between the two domains increases, the need to adjust traffic profiles often also increases , creating the need for more flexible resource allocation.

Enter the Bandwidth Broker (BB). The BB starts an end-to-end call setup to other BBs across the desired path, enabling resource negotiation among multiple domains. BBs perform admission control, policy control, and reservation tracking and aggregation. BBs can facilitate reservation requests between an enterprise network and its users, or between the network subscriber and service provider.

Double Duty

DiffServ has the potential to support multicast traffic, but some traffic estimation issues must be resolved before this can occur on a widespread basis. The fact that multicast group membership can change so frequently and quickly makes it difficult to gauge the amount of traffic potentially involved in a multicast sessiona must for ensuring reliable multicast transmissions. In addition, a multicast distribution tree may have one ingress point but many egress points, which also complicates traffic estimation. (For an overview of some of the IETF's efforts in this area, see http://search.ietf.org/internet-drafts/draft- bless -diffserv-multicast-01.txt.)

Work is also underway to determine how DiffServ could best be used with RSVP. One promising approach is using RSVP at the network edge and DiffServ in the core.

The two technologies have some very complementary properties that could make this a compelling combination. RSVP excels at per-flow resource management, but isn't highly scalable. Also, because it's inherently more complex than DiffServ, it's recommended that RSVP not be used on most backbones, as it can impair performance there.

DiffServ, on the other hand, has limited resource management capabilities but is more scalable than RSVP. Thus, using DiffServ in the network backbone and RSVP at the network edge could represent a very efficient approach in the quest to sustain desired levels of QoS across the network.

The IETF has also proposed measures for refining the use of DiffServ with Multiprotocol Label Switching (MPLS; see http://search.ietf.org/internet-drafts/draft-gant-mpls-diffserv-elsp-00.txt). DiffServ traffic can be mapped to MPLS processes, but this can involve some relatively complex resource allocation schemes and label assignment procedures.

Despite these issues, DiffServ remains a promising candidate for use in combination with other QoS architectures. The primary challenge will lie in achieving interoperability with other technologies, particularly when it comes to specifying and maintaining SLAs and TCAs.

Resources

The following books contain useful overviews of Differentiated Services (DiffServ) and other QoS architectures:

Internet Performance Survival Guide , by Geoff Huston, John Wiley & Sons (ISBN: 0-471-37808-9)

Designing Quality of Service , by Eric D. Siegel, John Wiley & Sons (ISBN: 0-471-33313-1)

A white paper entitled "Internet QoS: A Big Picture," by Xipeng Xiao and Lionel M. Ni, contains an informative section on DiffServ. See www.cs. columbia .edu/~zub/myloral/qos/netmg/ qos.pdf.

This tutorial, number 158, by Elizabeth Clark, was originally published in the September 2001 issue of Network Magazine.