Differentiated Services (Diff-Serv) (Linktionary term)

Site home page
(news and notices)

Get alerts when Linktionary is updated

Book updates and addendums

Get info about the Encyclopedia of Networking and Telecommunicatons, 3rd edition (2001)

Download the electronic version of the Encyclopedia of Networking, 2nd edition (1996). It's free!

Contribute to this site

Electronic licensing info

Differentiated Services (Diff-Serv)

Note: Many topics at this site are reduced versions of the text in "The Encyclopedia of Networking and Telecommunications." Search results will not be as extensive as a search of the book's CD-ROM.

This topic is presented in its entirety with illustatations as a sample topic.

Diff-Serv is a CoS (class of service) model that enhances the best-effort services of the Internet. It differentiates traffic by user, service requirements, and other criteria; then, it marks packets so that network nodes can provide different levels of service via priority queuing or bandwidth allocation, or by choosing dedicated routes for specific traffic flows. A policy management system controls service allocation. Note that some of the concepts discussed here are covered in more detail under the topics listed on the related entries page.

Various QoS (quality of service) techniques have been proposed or developed that attempt to provide predictable service on the Internet. One technique is Integrated Services (Int-Serv) and its associated RSVP protocol, as discussed in a moment. Some of the concepts in Diff-Serv grew out of the IntServ model. However, Diff-Serv is a CoS approach rather than a full QoS approach.

The traditional best-effort model of the Internet makes no attempt to differentiate between the traffic flows that are generated by different hosts. As traffic flow varies, the network provides the best service it can; but there are no controls to preserve higher levels of service for some flows and not others. What Diff-Serv does is attempt to provide better levels of service in a best-effort environment. RFC 2638 (Two-Bit Differentiated Services Architecture, July 1999) uses the following analogy to describe differentiated services:

We are motivated to provide services tiers in somewhat the same fashion as the airlines do with first class, business class and coach class. The latter also has tiering built in due to the various restrictions put on the purchase. A part of the analogy we want to stress is that best effort traffic, like coach class seats on an airplane, is still expected to make up the bulk of internet traffic. Business and first class carry a small number of passengers, but are quite important to the economics of the airline industry. The various economic forces and realities combine to dictate the relative allocation of the seats and to try to fill the airplane. We don't expect that differentiated services will comprise all the traffic on the internet, but we do expect that new services will lead to a healthy economic and service environment.

RFC 2990 (Next Steps for QoS Architecture, November 2000) is one of the best documents to read with regard to QoS in the Internet. Geoff Huston of Telstra (Australia) did an excellent job documenting QoS problems and solutions. The next few paragraphs draw on his work.

IntServ is a bandwidth reservation technique that builds virtual circuits across the Internet. Bandwidth requests come from applications running in hosts. Once a bandwidth reservation is made, the bandwidth cannot be reassigned or preempted by another reservation or by other traffic. IntServ and RSVP are stateful, meaning that RSVP network nodes must coordinate with one another to set up an RSVP path, and then remember state information about the flow. This can be a daunting task on the Internet, where millions of flows may exist across a router. The RSVP approach is now considered too unwieldy for the Internet, but appropriate for smaller enterprise networks (or when used with Diff-Serv and other techniques, discussed shortly).

Diff-Serv takes a stateless approach that minimizes the need for nodes in the network to remember anything about flows. It is not as good at providing QoS as the stateful approach, but more practical to implement across the Internet. Diff-Serv devices at the edge of the network mark packets in a way that describes the service level they should receive. Network elements simply respond to these markings without the need to negotiate paths or remember extensive state information for every flow. In addition, applications don't need to request a particular service level or provide advance notice about where traffic is going.

In the IntServ/RSVP environment, applications negotiate with the network for service. IntServ is said to be application aware, which allows hosts to communicate useful information to the network about their requirements and the state of their flows. In contrast, Diff-Serv is not application aware (although work is underway to make it so). Since Diff-Serv does not listen to applications, it does not benefit from feedback that applications could provide. Since it doesn't know exactly what an application needs, it may fail to provide it with an appropriate service level. In addition, Diff-Serv is not in touch with the receiving host, so it doesn't know whether that host can handle the services it will allocate.

One could say that the Internet needs both RSVP (or some other full QoS model) and Diff-Serv. RFC 2990 mentions that both IntServ and Diff-Serv may need to be combined into an end-to-end model, with IntServ as the architecture that allows applications to interact with the network, and Diff-Serv as the architecture to manage admission and network resources. This is covered further in RFC 2998 (A Framework for Integrated Services Operation Over DiffServ Networks, November 2000). One approach is to use Diff-Serv to carry RSVP application messages across the core to another RSVP network.

This discussion has so far compared Diff-Serv with IntServ and RSVP. Diff-Serv can be contrasted with MPLS, which implements connection-oriented virtual circuits on ATM, frame relay, or switched networks. MPLS adds labels (tags) to packets that indicate forwarding behavior, but packets travel across predefined circuits. MPLS is generally more sophisticated and complex than Diff-Serv, but provides better QoS capabilities.

Diff-Serv Architecture

RFC 2638 states that a differentiated services architecture should "keep the forwarding path simple, push complexity to the edges of the network to the extent possible, provide a service that avoids assumptions about the type of traffic using it, employ an allocation policy that will be compatible with both long-term and short-term provisioning, and make it possible for the dominant Internet traffic model to remain best-effort."

The IETF formed the Diff-Serv Working Group to develop a simple and coarse method for differentiating classes of service for Internet traffic. The primary Diff-Serv RFCs are RFC 2474 (Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers, December 1998), which defines the DS field and how it is used, and RFC 2475 (An Architecture for Differentiated Services, December 1998), which describes techniques for implementing scalable differentiated services on the Internet.

Some important points about Diff-Serv are outlined here:

Diff-Serv defines a new DS (Differentiated Services) field in the IP header that replaces the older ToS (Type of Service) field. Bit patterns in the field indicate the type of service and forwarding behavior at network nodes. The field is illustrated next. DSCP is the "differentiated services codepoint" (herein called DSCP, but also called the "DS codepoint," or simply "codepoint"), and CU indicates "currently unused."

The 6 bits in the DSCP field can define up to 64 discrete network service types.

PHB (per-hop behavior) refers to a particular type of forwarding treatment for packets across the Diff-Serv network. The value of the DSCP field indicates the PHB to use.

PHBs may satisfy a particular bandwidth requirement (i.e., to support real-time voice) or provide some priority service. Service characteristics may be designed to improve throughput or reduce delay, jitter, and packet loss.

Differentiated services can accommodate different types of application requirements and allow service providers to price services according to their characteristics.

Diff-Serv is designed to work within domains or end to end across the Internet (over different service provider domains).

Rules that define service are set with policy-based management schemes (see "Policy-Based Management").

Per-Hop Behaviors

A PHB (per-hop behavior) is a basic hop-by-hop resource allocation mechanism. Think of PHB as a particular forwarding behavior that stretches across a network and that provides a particular class of service-being careful not to call it a path, because a path could imply state in the network.

RFC 2475 describes a PHB as a forwarding behavior applied to a particular DS behavior aggregate. A DS behavior aggregate is a collection of packets with the same DSCP value crossing a link in a particular direction. When a behavior aggregate arrives at a node, the node maps the DSCP to the appropriate PHB, and this mapping defines how the node will allocate resources to the behavior aggregate. Some example PHBs are described here:

A PHB that guarantees a minimal bandwidth allocation across a link to a behavior aggregate.

A PHB similar to the preceding with the added feature of being able to share any excess link capacity with other behavior aggregates.

A PHB that has resource (buffers and bandwidth) priority over other PHBs.

A PHB that has low delay and traffic loss characteristics

RFC 2474 and RFC 2475 include sections that describe guidelines for defining PHBs in order to promote consistency and standardization. The guidelines recommend that PHBs be designed to provide host-to-host, WAN edge-to-WAN edge, and/or domain edge-to-domain edge services.

A PHB is implemented with buffer management and packet -scheduling mechanisms. Routers examine the DSCP field, differentiate according to the markings, and then move packets into appropriate queues. An outgoing link typically has multiple queues with different priorities. A scheduling technique is used to move packets in the queues out to the next hop. See "Queuing" for additional information

Diff-Serv Network Elements

The Diff-Serv network consists of a variety of network elements and some specific terminology. Some of the elements are illustrated in Figure D-21 and explained next. All of these elements and their associated behaviors are designed to decouple traffic management and service provisioning functions from the forwarding functions, which are implemented within the core network nodes.

The most prominent features of Diff-Serv networks are the DS domains and the DS boundary nodes. The DS domains may be private intranets, but are typically autonomous service provider networks that have their own service-provisioning policies and PHB definitions. DS Interior nodes interpret the DSCP value and forward packets. They may perform some traffic conditioning functions and may remark packets. DS domains interconnect with other domains via boundary links. A DS region is a set of contiguous DS domains that offer inter-domain differentiated services.

The DS boundary nodes exist at the edge of the Diff-Serv network as either ingress or egress nodes. The ingress node is the most important because it classifies and injects traffic into the network. It may also condition traffic to make sure it meets policy requirements. The boundary node contains the following elements.

Standard Classifier Selects packets based on the DS codepoint value. Selected packets are then forwarded as appropriate or subjected to traffic conditioning if necessary.

Multi-Field Classifier This classifier selects packets based on the content of some arbitrary number of header fields-typically, some combination of source address, destination address, DS field, protocol ID, source port, and destination port.

Marker An entity that sets the value of the DSCP field.

Policy Systems/Bandwidth Brokers Devices that are configured with organizational policies. They keep track of the current allocation of marked traffic and interpret new requests to mark traffic in light of the policies and current allocation. RFC 2638 provides a broad overview of these system requirements.

Traffic Conditioner An entity that meters, marks, drops, and shapes traffic. A traffic conditioner may re-mark a traffic stream, or may discard or shape packets to alter the temporal characteristics of the stream and bring it into compliance with a traffic profile. The subcomponents of the traffic conditioner are listed here. See "Traffic Management, Shaping, and Engineering" for related details.

Meter Measures the rate of traffic streams selected by the classifier. The measurements are used by the following elements, or for accounting and measurement purposes.

Policer Evaluates the measurements made by the meter and uses them to enforce policy-based traffic profiles.

Dropper Droppers discard some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. This process is known as "policing" the stream.

Shaper Delays packets within a traffic stream to cause it to conform to some defined traffic profile. A shaper may drop packets if there is not sufficient buffer space to hold the delayed packets.

Traffic conditioners are usually located within the DS ingress or egress boundary nodes, but may also be located in interior nodes within the DS domain. The ingress node of the source domain is the first to mark packets. An egress node that leads to another DS domain may re-mark packets if necessary.

Traffic conditioning rules are specified in a TCA (traffic conditioning agreement) and enforced by the traffic conditioner. TCA rules correspond to SLAs (service-level agreements) made between customers and service providers. These agreements specify the type of service a customer will receive. Note that DS domains within a region include ISPs that are peering with one another and have established peering SLAs.

Diff-Serv performs traffic conditioning to ensure that the traffic entering the DS domain conforms to the rules specified in the TCA, in accordance with the domain's service provisioning policy. The traffic classifier forwards packets to appropriate traffic conditioning elements.

Traffic conditioners use traffic profiles to determine how to condition traffic. A traffic profile defines the rules for determining whether packets are in-profile or out-of-profile. Out-of-profile packets may be queued until they are in-profile (shaped), discarded (policed), marked with a new codepoint (re-marked), or forwarded unchanged while triggering some accounting procedure. Out-of-profile packets may be mapped to an "inferior" behavior aggregate.

As mentioned in the preceding list, traffic conditioners contain meters, markers, shapers, and droppers. The meter measures traffic streams against the traffic profile, and the state of the meter affects whether a packet is marked, dropped, or shaped. The following illustration shows packets coming into the classifier. The meter measures the stream and passes information to other elements that trigger a particular action. The marker sets the DSCP value of a packet, effectively adding it to a particular behavior aggregate.

RFC 2597 (Assured Forwarding PHB Group, June 1999) defines a method for defining drop precedence. IP packets are marked by customers or other ISPs with one of three possible drop precedence values. When congestion occurs, the congested DS node protects packets with a lower drop precedence value by discarding packets with a higher drop precedence value.

RFC 2598 (An Expedited Forwarding PHB, June 1999) describes an expedited forwarding (EF) PHB that can be used to build a low-loss, low-latency, low-jitter, assured-bandwidth, end-to-end service through DS domains. Such a service appears to the endpoints like a point-to-point connection or a "virtual leased line." It is useful for voice over IP because it minimizes latency.

RFC 2697 (A Single Rate Three Color Marker [srTCM], September 1999) describes a way to mark packets according to three traffic parameters: Committed Information Rate, (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS). The srTCM is useful for ingress policing of a service, where only the length, not the peak rate, of the burst determines service eligibility.

RFC 2698 (A Two Rate Three Color Marker [trTCM], September 1999) describes a way to mark packets based on two rates, Peak Information Rate (PIR) and Committed Information Rate (CIR). The trTCM is useful for ingress policing of a service, where a peak rate needs to be enforced separately from a committed rate.

RFC 2859 (A Time Sliding Window Three Color Marker, June 2000) describes a method of marking packets based on the measured throughput of the traffic stream, compared to the Committed Target Rate (CTR) and the Peak Target Rate (PTR). The marker is intended to mark packets that will be treated by the Assured Forwarding (AF) PHB in downstream routers.

Additional DIff-Serv Information

As previously mentioned, other sections cover functions that are performed in Diff-Serv networks and in many other types of networks. These topics include "Queuing," "Policy-Based Management," and "Traffic Management, Shaping, and Engineering."

The IETF Differentiated Services (diffserv) Working Group has a complete list of Diff-Serv-related RFCs and a list of drafts that describe the latest developments in Diff-Serv.

The IETF Internet Traffic Engineering (tewg) Working Group is defining traffic engineering techniques and mechanisms for intra-domain traffic engineering, including provisioning, measurement and control of intra-domain routing, and measurement and control aspects of intra-domain network resource allocation. It is developing traffic engineering models for ATM and frame relay overlay, MPLS, constraint-based routing, and Diff-Serv environments.

The IETF Policy Framework (policy) Working Group is defining policy frameworks, information models, and schemata to store, retrieve, distribute, and process policies. It is also defining intra-domain policies. The group is providing input to the Diff-Serv Working Group.