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
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 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.
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.
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
Copyright James F. Kurose and Keith
W. Ross 1996-2000