6.9 Differentiated Services

In the previous section we saw how RSVP reserves per-flow resources at routers within the network. The ability to request and reserve per-flow resources, in turn, makes it possible for the intserv framework to provide quality of service guarantees to individual flows. As work on Intserv and RSVP proceeded, however, researchers involved with these efforts (e.g., [Zhang 1998]) have begun to uncover some of the difficulties associated with the Intserv model and per-flow reservation of resources:

Scalability. The per-flow resource reservation in RSVP implies the need for a router to process resource reservations and to maintain per-flow state for each flow passing though the router. With recent measurements [Thompson 1997] suggesting that even for an OC-3 speed link, approximately 256,000 source-destination pairs might be seen in one minute in a backbone router, per-flow reservation processing represents a considerable overhead in large neworks.
Flexible service models. The Intserv framework provides for a small number of pre-specified service classes. This particular set of service classes does not allow for more qualitative or relative definitions of service distinctions (e.g., "Service class A will received preferred treatment over service class B."). These more qualitiative definitions might well better fit our intuitive notion of service distinction (e.g., first class versus coach class in air travel; "platinum" versus "gold" versus "standard" credit cards).
Better-than-best-effort service to applications, without the need for host RSVP signaling. Few hosts in today's Internet are able to generate RSVP signaling or express the Rspec and Tspec in the detail needed by the Intserv model.

These considerations have led to the recent so-called "diffserv" (Differentiated Services) activity [Diffserv 1999] within the Internet Engineering Task Force. The diffserv working group is developing an architecture for providing scalable and flexible service differentiation - i.e., the ability to handle different "classes" of traffic in different ways within the Internet. The need for scalability arises from the fact that hundreds of thousands simultaneous source-destination traffic flows may be present at a backbone router of the Internet. We will see shortly that this need is met by placing only simple functionality within the network core, with more complex control operations being implemented towards the "edge" of the network. The need for flexibilty arises from the fact that new service classes may arise and old service classes may become obsolete. The differentiated services architecture is flexible in the sense that it does not define specific services or service classes (e.g., as is the case with Intserv). Instead, the differentiated services architecture provides the functional components, i.e., the "pieces" of a network architecture, with which such services can be built. Let us now examine these components in detail.

6.9.1 Differentiated Services: A Simple Scenario

To set the framework for defining the architectural components of the differentiated service model, let us begin with the simple network shown in Figure 6.8-1. In the following, we describe one possible use of the diffserv components. Many other possible variations are possible, as described in [RFC 2475]. Our goal here is to provide an introduction to the key aspects of differentiated services, rather than to describe the architecural model in exhaustive detail.

Figure 6.9-1: A simple diffserv network example.

The differentiated services architecture consists of two sets of functional elements:

Edge functions: packet classification and traffic conditioning. At the incoming "edge" of the network (i.e., at either a differentiated services capable host that generates traffic or at the first DS-capable router that the traffic passes through), arriving packets are marked. More specifically, the Diffierentiated Service (DS) field of the packet header is set to some value. For example, in Figure 6.7-1, packets being sent from H1 to H3 might be marked at R1, while packets being sent from H2 to H4 might be marked at R2. The mark that a packet receives identifies the class of traffic to which it belongs. Different classes of traffic will then receive different service within the core network. The RFC defining the differeniated service architecture [RFC 2475] uses the term "behavior aggregate" rather than "class of traffic." After being marked, a packet may then be immediately forwarded into the network, delayed for some time before being forwarded, or may be discarded. We will see shortly that many factors can influence how a packet is to be marked, and whether it is to be forwarded immediately, delayed, or dropped.

Core function: forwarding. When a DS-marked packet arrives at a DS-capable router, the packet is forwarded onto its next hop according to the so-called per-hop behavior associated with that packet's class. The per-hop behavior influences how a router's buffers and link bandwidth are shared among the competing classes of traffic. A crucial tenet of the DS architecture is that a router's per-hop behavior will be based only on packet markings, i.e., the class of traffic to which a packet belongs. Thus, if packets being sent from H1 to H3 in Figure 6.7-1 receive the same marking as packets from H2 to H4, then the network routers treat these packets as a aggregate, without distinguishing whether the packets originated at H1 or H2. For example, R3 would not distinguish between packets from H1 and H2 when forwarding these packets on to R4. Thus, the differentiated service architecture obviates the need to keep router state for individial source-destination pairs - an important consideration in meeting the scalability requirement discussed at the beginning of this section.

An analogy might prove useful here. At many large-scale social events (e.g., a large public reception, a large dance club or discoteque, a concert, a football game), people entering the event receive a "pass" of one type or another. There are VIP passes for Very Important People; there are over-18 passes for people who are eighteen years old or older (e.g., if alcoholic drinks are to be served); there are backstage passes at concerts; there are press passes for reporters; there is an ordinary pass (sometimes simply the lack of a special pass) for the Ordinary Person. These passes are typically distributed on entry to the event, i.e., at the "edge" of the event. It is here at the edge where computationally intensive operations such as paying for entry, checking for the appropriate type of invitation, and matching an invitation against a piece of identification, are performed. Futhermore, there may be a limit on the number of people of a given type that are allowed into an event. If there is such a limit, people may have to wait before entering the event. Once inside the event, one's pass allows one to receive differentiated service at many locations around the event - a VIP is provided with free drinks, a better table, free food, entry to exclusive rooms, and fawning service. Conversely, an Ordinary Person is excluded from certain areas, pays for drinks, and receives only basic service. In both cases, the service received within the event depends solely on the type of one's pass. Moreover, all people within a class are treated alike.

6.9.2 Traffic Classification and Conditioning

In the differentiated services architecture, a packet's mark is carried within the so-called Differentiated Services (DS) field in the IPv4 or IPv6 packet header. The definition of the DS field is intended to supersede the earlier definitions of the IPv4 Type-of-Service field (see Section 4.4) and the IPv6 Traffic Class Field (see Section 4.7). The structure of this 8-bit field is shown below in Figure 6.8-2 Strcuture of DS field

Figure 6.8-2: Structure of the DS field in IVv4 and IPv6 header

The 6-bit Differentiated Service Code Point (DSCP) subfield determines the so-called per-hop behavior (see section 6.8.4) that the packet will receive within the network. The 2-bit CU subfield of the DS field is currently unused. Restrictions are placed on the use of half of the DSCP values in order to preserve backward compatability with the IPv4 ToS field use; see [RFC 2474] for details. For our purposes here, we need only note that a packet's mark, its "code point" in the DS terminology, is carried in the 8-bit DS field.

As noted above, a packet is marked (more specificially, its DS field value is set) at the edge of the network. This can either happen at a DS-capable host or at the first point at which the packet encounters a DS-capable router. For our discussion here, we will assume marking occurs at an edge router that is directly connected to a sender, as shown in Figure 6.9-1.

Simple classification and marking
Figure 6.9-3: Simple packet classification and marking

Figure 6.9-3 provides a logical view of the classification and marking function within the edge router. Packets arriving to the edge router are first "classified." The classifier selects packets based the values of one or more packet header fields (e.g., source address, destination address, source port, destination port, protocol ID) and steers the packet to the appropriate marking function. The DS field value is then set accordingly at the marker. Once packets are marked, they are then forwarded along their route to the destination. At each subsequent DS-capable router, these marked packets then receive the service associated with the packets' marks. Even this simple marking scheme can be used to support different classes of service within the Internet. For example, all packets coming from a certain set of source IP addresses (e.g., those IP addresses that have paid for an expensive priority service within their ISP) could be marked on entry to the ISP, and then receive a specific forwarding service (e.g., a higher priority forwarding) at all subsequent DS-capable routers. A question not addressed by the diffserv working group is how the classifier obtains the "rules" for such classification. This could be done manually, i.e., the network administrator could load a table of source addresses that are to be marked in a given way into the edge routers, or could be done under the control of some yet-to-be-specified signalling protocol.

In Figure 6.9-3, all packets meeting a given header condition receive the same marking, regardless of the packet arrival rate. In some scenarios, it might also be desirable to limit the rate at which packets bearing a given marking are injected into the network. For example, an end-user might negotiate a contract with its ISP to receive high priority service, but at the same time agree to limit the maximum rate at which it would send packets into the network. That is, the end user agrees that its packet sending rate would be within some declared traffic profile. The traffic profile might contain a limit on the peak rate, as well as the burstiness of the packet flow, as we saw in Section 6.6 with the leaky bucket mechanism. As long as the user sends packets into the network in a way that conforms to the negotiated traffic profile, the packets receive their priority marking. On the other hand, if the traffic profile is violated, the out-of-profile packets might be marked differently, might be shaped (e.g. delayed so that a maximum rate constraint would be observed), or might be dropped at the network edge. The role of the meteringfunction, shown in Figure 6.9-4, is to compare the incoming packet flow with the negotiated traffic profile and to determine whether a packet is within the negotiated traffic profile. The actual decision about whether to immediately re-mark, forward, delay, or drop a packet is not specified in the diffserv architecture. The diffserv architecture only provides the framework for performing packet marking and shaping/dropping; it does not mandate any specific policy for what marking and conditioning (shaping or dropping) is actually to be done. The hope, of course, is that the diffserv architectural components are together flexible enough to accomodate a wide and constant evolving set of services to end users.

Figure 6.9-4: logical view of packet classification and traffic conditioning at the edge router

6.9.3 Per-Hops Behavior

So far, we have focused on the edge functions in the differentiated services architecture. The second key component of the DS architecture involves the per hop behavior (i.e., packet forwarding function) performed by DS-capable routers. The per-hop behavior (PHB) is rather cryptically, but carefully, defined as "a description of the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate." [RFC 2475]. Digging a little deeper into this definition, we can see several important considerations embedded within:

A PHB can result in different classes of traffic ( i.e., traffic with different DS field values) receiving different performance (i.e., different externally observable forwarding behavior).
While a PHB defines differences in performance (behavior) among classes, it does not mandate any particular mechanism for achieving these behaviors. As long as the externally observable performance criteria are met, any implementation mechanism and any buffer/bandwidth allocation policy can be used. For example, a PHB would not require that a particular packet queueing discipline, e.g., a priority queue versus a weighted-fair-queueing queue versus a first-come-first-served queue, be used to achieve a particular behavior. The PHB is the "end", to which resource allocation and implemention mechanisms are the "means."
Differences in performance must be observable, and hence measurable.

An example of a simple PHB is one that guarantees that a given class of marked packets receive at least x% of the outgoing link bandwidth over some interval of time. Another per-hop behavior might specify that one class of traffic will always receive strict priority over another class of traffic - i.e., if a high priority packet and low priority are present in a router's queue at the same time, the high priority packet will always leave first. Note that while a priority queueing discipline might be a natural choice for implementing this second PHB, any queueing discipline that implements the required observable behavior is acceptable.

Currently, two PHB's are under active discussion within the diffserv working group: an Expedited Forwarding (EF) PHB [Jacobson 1999] and an Assured Forwarding (AF) PHB [Heinanen 1999]:

The Expedited Forwarding PHB specifies that the departure rate of a class of traffic from a router must equal or exceed a configured rate. That is, during any interval of time, the class of traffic can be guaranteed to receive enough bandwidth so that the output rate of the traffic equals or exceeds this minimum configured rate. Note that the EF per hop behavior implies some form of isolation among traffic classes, as this guarantee is made independently of the traffic intensity of any other classes that are arriving to a router. Thus, even if the other classes of traffic are overwhelming router and link resources, enough of those resources must still be made available to the class to ensure that it receives its minimum rate guarantee. EF thus provides a class with the simple abstraction of a link with a minumum guaranteed link bandwidth.

The Assured Forwarding PHB is more complex. AF divides traffic into four classes, where each AF class is guaranteed to be provided with some minimum amount of bandwidth and buffering. Within each class, packets are further partitioned into one of three "drop preference" categories. When congestion occurs within an AF class, a router can then discard (drop) packets based on their drop preference values. See [Heinanen 1999] for details. By varying the amount of resources allocated to each class, an ISP can provide different levels of performance to the different AF traffic classes.

each

better

6.9.4 A Beginning

The differentiated services architecture is still in the early stages of its development and is rapidly evolving. RFC's 2474 and 2475 [RFC1474], [RFC2475] define the fundamental framework of the diffserv architecture but themselves are likely to evolve as well. The AF and EF PHB's discussed above have yet to enter the RFC standards track. The ways in which PHB's, edge functionality, and traffic profiles can be combined to provide an end-to-end services, such as a virtual leased line service [Nicols 1998] or an Olympic-like gold/silver/bronze service [Heinanen 1999], are still under investigation. In our discussion above, we have assumed that the DS architecture is deployed within a single adminstrative domain. The (typical) case where an end-to-end service must be fashioned from a connection that crosses several administrative domains, and through non-DS capable routers, pose additional challenges beyond those described above.

References

[Diffserv 1999] The IETF Differentiated Services Working Group homepage, http://www.ietf.org/html.charters/diffserv-charter.html
[Heinanen 1999] Juha Heinanen, Fred Baker, Walter Weiss, John Wroclawski, "Assured Forwarding PHB Group", Internet Draft <draft-ietf-diffserv-af-04.txt> , January 1999.
[Jacobson 1999] V. Jacobson, Kathleen Nichols, Kedernath Poduri, "An Expedited Forwarding PHB", Internet Draft <draft-ietf-diffserv-phb-ef-02.txt> Feb. 1999.
[Nicols 1998] K. Nicols, V. Jacobson, L. Zhang, "A Two Bit Differentiated Services Architecture for the Internet." unpublished draft.
[RFC 2474] K. Nicols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998.
[RFC 2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Services", RFC 2475, Dec. 1998.
[Thomson 1997] K. Thomson, G. Miller, R. Wilder, "Wide Area Traffic Patterns and Characteristics," IEEE Network Magazine, Dec. 1997.
[Zhang 1998] Lixia Zhang, R. Yavatkar, Fred Baker, Peter Ford, Kathleen Nichols, M. Speer, Y. Bernet, "A Framework for Use of RSVP with Diff-serv Networks", <draft-ietf-diffserv-rsvp-01.txt> , 11/20/1998.

Return to Table Of Contents