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.
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.
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
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.
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 metering function, 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
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.
The AF PHB could be used as a building block to provide different levels of service to the end systems, e.g., an Olympic-like gold, silver, and bronze classes of service. But what would be required to do so? If gold service is indeed going to be "better" (and presumably more expensive!) than silver service, then the ISP must ensure that gold packets receive lower delay and/or loss than silver packets. Recall, however, that a minimum amount of bandwidth and buffering are to be allocated to each class. What would happen if gold service was allocated x% of a link's bandwidth and silver service was allocated x/2 % of the link's bandwidth, but the traffic intensity of gold packets was 100 times higher than that of silver packets? In this case, it is likely that silver packets would receive better performance than the gold packets! (An outcome that leaves the silver service buyers happy, but the high-spending gold service buyers extremely unhappy!) Clearly, when creating a service out of a PHB, more than just the PHB itself will come into play. In this example, the dimensioning of resources - determining how much resources will be allocated to each class of service - must be done hand-in-hand with knowledge about the traffic demands of the various classes of traffic.
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
Return to Table Of Contents
Copyright James F. Kurose and Keith W. Ross 1996–2000