draft-ietf-diffserv-framework-00.txt   draft-ietf-diffserv-framework-01.txt 
Differentiated Services S.Blake, et al
INTERNET-DRAFT Yoram Bernet Document: draft-ietf-diffserv-framework-01.txt
Diffserv Working Group Microsoft
Expires: November 1998 James Binder
3Com
Steven Blake
IBM
Mark Carlson
Redcape Software
Elwyn Davies
Nortel UK
Borje Ohlman
Ericsson
Dinesh Verma
IBM
Zheng Wang
Bell Labs Lucent Technologies
Walter Weiss
Lucent Technologies
A Framework for Differentiated Services
<draft-ietf-diffserv-framework-00.txt> Yoram Bernet, Microsoft
James Binder, 3-Com
Steven Blake, Torrent Networking Technologies
Mark Carlson, Redcape Software
Srinivasan Keshav, Cornell University
Elwyn Davies, Nortel UK
Borje Ohlman, Ericsson
Dinesh Verma, IBM
Zheng Wang, Bell Labs Lucent Technologies
Walter Weiss, Lucent Technologies
Status of This Memo A Framework for Differentiated Services
<draft-ietf-diffserv-framework-01.txt>
This document is an Internet-Draft. Internet-Drafts are working Status of this Memo
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document is an Internet Draft. Internet Drafts are working
and may be updated, replaced, or obsoleted by other documents at any documents of the Internet Engineering Task Force (IETF), its Areas,
time. It is inappropriate to use Internet-Drafts as reference and its Working Groups. Note that other groups may also distribute
material or to cite them other than as "work in progress." working documents as Internet Drafts.
To view the entire list of current Internet-Drafts, please check the Internet Drafts are draft documents valid for a maximum of six
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow months. Internet Drafts may be updated, replaced, or obsoleted by
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern other documents at any time. It is not appropriate to use Internet
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Drafts as reference material or to cite them other than as a
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). "working draft" or "work in progress".
Abstract To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.
This document provides a general description of issues related to the A revised version of this draft document will be submitted to the
definition, configuration, and management of services enabled by the RFC editor as a Proposed Standard for the Internet Community.
differentiated services architecture [DSARCH]. It should be Discussion and suggestions for improvement are requested. This
considered as a work-in-progress. document will expire before April, 1999. Distribution of this draft
is unlimited.
Bernet, et. al. Expires: November 1998 [Page 1] 1. Abstract
Sec. 1 provides a motivation for the deployment of differentiated
services. Sec. 2 examines the range of services that are enabled
by the differentiated services architecture. Sec. 3 examines
service instantiation, configuration, and management issues. Sec. 4
discusses issues relating to the deployment of differentiated
services across multiple provider boundaries or end-to-end. Sec. 5
addresses interoperability with the Integrated Services.
1. Motivation This document provides a general description of issues related to
the definition, configuration and management of services enabled by
the differentiated services architecture [DSARCH]. This document
should be read along with its companion documents, the
differentiated services architecture [DSARCH] and the definition of
the DS field [DSHEAD]. A glossary of specialist terms used may be
found in [DSARCH].
A service is a contract between a network provider and its customer, Blake, et al Expires: April 1999 1
which outlines the characteristics and behavior of network
connectivity offered by the provider to the customer. The network
provider may be an Internet Service Provider whose customers include
individual users or corporations, an I/T department within an
enterprise, or a networking company to which the operations of an
enterprise network has been outsourced. Individual users would
typically access the network at a single point, while businesses may
have multiple access-points to the network.
A service level agreement (SLA) may specify different aspects of 2. Structure of this Draft
network behavior, such as the security to be expected by the
customer, constraints on the type and amount of data that can be sent
on the network, and the performance aspects of communication. The
SLA would typically also include a payment/billing scenario as well
as the performance (both up time as well as throughput) aspects
expected with the associated contract.
While services can be differentiated from each other by various Section 3 defines Differentiated Services and explains the
aspects, we concentrate on service differentiation from the motivation behind its deployment. Section 4 defines the concept of a
performance aspect only in this document. Traditionally, network service and the components that comprise a service. Section 5
providers have tended to provide all of their customers with the same discusses several service examples. Section 6 examines intra-domain
type of performance (a best-effort service), with most provisioning, configuration and management issues. Section 7
differentiation resulting from the pricing structure (business rates examines inter-domain provisioning, configuration and management.
versus individual rates) or the connectivity structure (dial-in Section 8 addresses interoperability with Integrated Services and
access versus leased line T1 access, etc.). However, the size of the RSVP. Section 9 discusses the interaction of differentiated services
Internet continues to grow at an astounding rate, and network with multicast and tunnelling. Section 10 addresses security
capacity has become a scarce resource. Given new types of media and concerns.
the further reliance on the network as a mission critical resource,
there is a need felt by the network providers to offer different
types or grades of performance to customers, with network providers
offering better performance to customers who are willing to pay more.
The key aspects determining service performance are availability and 3. Differentiated Services - Motivation and Definition
responsiveness. Availability refers to the ability of a customer to
maintain connectivity between its access points on the provider
network, while responsiveness refers to the round-trip delay and
throughputs seen by the customer on its communication.
This document presents a framework for service definition and service Traditionally, network service providers (both enterprise and
differentiation in the context of a differentiated service domain as traditional ISPs) provide all customers with the same level of
performance (best-effort service). Most service differentiation has
been in the pricing structure (individual vs. business rates) or the
connectivity type (dial-up access vs. leased line, etc.). However,
in recent years, increased usage of the Internet has resulted in
scarcity of network capacity, compromising performance of
traditional, mission critical applications. At the same time, new
applications have emerged which demand much improved service
quality. As a result, service providers are finding it necessary to
offer their customers alternative levels of service. As well as
meeting new customer expectations, this allows service providers to
improve their revenues through premium pricing and competitive
differentiation of service offerings, which in turn can fund the
necessary expansion of the network.
Bernet, et. al. Expires: November 1998 [Page 2] The Differentiated Services architecture offers a framework within
described in [DSARCH]. which service providers can offer each customer a range of network
services which are differentiated on the basis of performance in
addition to pricing tiers used in the past. Customers request a
specific performance level on a packet by packet basis, by marking
the DS field of each packet with a specific value (see [DSHEAD] for
more details). This value specifies the Per-hop Behavior (PHB) to be
allotted to the packet within the provider's network. Typically, the
customer and provider negotiate a profile (policing profile)
describing the rate at which traffic can be submitted at each
service level. Packets submitted in excess of this profile may not
be allotted the service level requested. A salient feature of
differentiated services is its scalability, which allows it to be
deployed in very large networks. This scalability is achieved by
forcing as much complexity out of the core of the network into edge
devices which process lower volumes of traffic and lesser numbers of
flows, and offering services for aggregated traffic rather than on a
per-micro-flow basis.
2. Services Blake, et al Expires: April 1999 2
2.1 Service Categorization 4. Services
In order to provide the notion of differentiated services, the [DSARCH] defines a Service as "the overall treatment of a defined
network provider needs to be able to categorize traffic entering its subset of a customer's traffic within a DS-domain, or end-to-end".
network into multiple categories. Each of the categories of traffic Although PHBs are at the heart of the differentiated services
is marked with a codepoint as described in [DSARCH]. These architecture, it is the service obtained as a result of marking
codepoints (or per-hop behaviors (PHBs)) in turn can be used to build traffic for a specific PHB, which is of value to the customer. PHBs
a specific service offered by the Network Provider to the customer. are merely building blocks for services. Service providers combine
Service differentiation may be made along multiple dimensions. PHB implementations with traffic conditioners, provisioning
strategies and billing models which enable them to offer services to
their customers. Providers and customers negotiate agreements with
respect to the services to be provided at each customer/provider
boundary. These take the form of Service Level Agreements (SLAs).
A provider may offer a customer a service which provides different Bear in mind when considering the services that are offered in a DS-
performance assurances to packets being received by the customer from domain that:
the provider network, or to packets being sent from the customer * DS services are all for unidirectional traffic only
network into the provider network, or a combination of the above. A * DS services are for traffic aggregates, not individual micro-flows
business hosting a web-site might have a contract with its ISP, which
enables the responses out from the web-server to be carried at a
better performance level than the default. One business may not want
to pay for a better performance level for requests trying to reach
its server, while a third business may be willing to pay more both
for its requests as well as responses. Depending on the type of
service contract between the customer and the provider, the network
may control packets being sent into it, packets being sent out of it,
or both.
A service may be defined which is dependent on the time-of-day. A 4.1 Customer/Provider Boundaries
customer may want a better performance of service during business
hours, and may choose to revert to the default behavior during off-
hours. A customer may require that a different path be offered to
its packets which satisfy certain constraints (e.g., a minimum of T1
capacity along any link connecting the service), or meet certain
geographical or topological constraints (e.g., packets must not leave
the boundaries of the United States).
A service may be defined based on the performance level to be Present day network traffic generally traverses a concatenation of
expected between a pair of customer access points to the network. networks which may include hosts, home or office networks, campus or
Thus, one may define a service, which would offer statistical bounds corporate networks and several large transit networks. Home and
on the delay or loss rate to be experienced between two access- office networks are typically customers of campus or corporate
points. While such performance bounds may be different for different networks, which are in turn customers of large transit networks.
access-points, some providers may choose to offer a service, which While one would expect the initial deployment of differentiated
would provide the minimum acceptable performance among any two points services to be within large transit networks, its deployment may
on the customer network. also be extended to the smaller campus and corporate networks and in
special cases, all the way to individual hosts. As such, there may
be numerous customer/provider boundaries at which the concept of a
'service' applies.
Such performance assurances may be coupled with constraints on how 4.2 SLAs and TCAs
much traffic a customer may inject into the provider's network.
A service may be defined on the basis of the fault tolerance At each differentiated service customer/provider boundary, the
properties that are offered to the customer. The service may specify service provided is defined in the form of an SLA. The SLA is a
contract which specifies the overall features and performance which
can be expected by the customer. Because DS services are
unidirectional the two directions of flow across the boundary will
need to be considered separately. An important subset of the SLA is
the traffic conditioning agreement, or TCA. The TCA specifies
detailed service parameters for each service level. Such parameters
include:
1. Detailed service performance parameters such as expected
throughput, drop probability, latency.
2. Traffic profiles which must be adhered to for the requested
service to be provided, such as token bucket parameters.
Bernet, et. al. Expires: November 1998 [Page 3] Blake, et al Expires: April 1999 3
resumption of the service within a certain limit of time, or promise 3. Disposition of traffic submitted in excess of the specified
upper bounds on the total connectivity downtime over a period of time profile.
or the amount of traffic which is dropped due to congestion over a 4. Marking services provided.
given period of time. 5. Shaping services provided.
Services, as may be obvious from the preceding paragraphs, could be In addition to the details in the TCA, the SLA may specify more
quite varied and rich in context. Different ISP's or vendors may general service characteristics such as:
offer different types of services to their customers over the 1. Availability/Reliability, which may include behavior in the event
network. These diverse services need to be supported and mapped onto of failures resulting in rerouting of traffic
a few PHBs within the DS domain of the network provider. In Section 2. Encryption services
2.3, we offer some examples of the services that may be offered by a 3. Routing constraints
network provider, and illustrate how they could be supported using a 4. Authentication mechanisms
few simple PHBs. 5. Mechanisms for monitoring and auditing the service
6. Responsibilities such as location of the equipment and
functionality, action if the contract is broken, support
capabilities
7. Pricing and billing mechanisms
A service agreement between a customer and a provider is usually These additional characteristics are important, and in the case of
captured in the form of a SLA. The SLA is normally in the form of a pricing and billing, fundamental to the service offering but they do
binding business contract, which specifies the features and not affect the service itself and are not considered further here.
performance requirements of the service provided, as well as traffic
profiles and/or corresponding packet marking requirements that are
captured in a traffic conditioning agreement (TCA) [DSARCH]. SLA's
may be static or dynamic. Static SLAs, that are the norm at the
present time, are defined at service initiation time, and do not
change frequently. Static SLAs may include the provision of specific
performance levels to a selected set of applications, time-of-day
changes in performance requirements, and changes dependent on network
load, as long as the specific agreement between the customer and
provider does not change. Dynamic SLAs, on the other hand, are
possibly subject to frequent changes, and may require an automated
protocol such as the bandwidth broker [BB] or other methods between
the customer and the network.
2.1.1 Sample SLA 4.3 Service Taxonomy: Quantitative through Qualitative and alternatives
The following example illustrates a boundary between two networks and The Differentiated Services architecture can support a broad
a simple static SLA: spectrum of different kinds of service. Categorizing these services
provides some constraints on the corresponding SLAs that can be
offered for the service.
The customer's network sends traffic to the provider's network via Some services can be clearly categorized as qualitative or
the customer's egress router. The provider's network receives quantitative depending on the type of performance parameters
traffic from the customer's network via the provider's ingress offered. Examples of qualitative services are as follows:
router. The SLA takes the following form: 1. Traffic offered at service level A will be delivered with low
latency.
2. Traffic offered at service level B will be delivered with low
loss.
Service Level Profile The assurances offered in examples 1 and 2 are relative and can only
be verified by comparison.
Premium R = 100 Kbps, b = 1000 bytes, r = 100 Kbps Examples of quantitative services are as follows:
3. 90% of in profile traffic delivered at service level C will
experience no more than 50 msec latency.
4. 95% of in profile traffic delivered at service level D will be
delivered.
Assured Gold R = 1000 Kbps, b = 1000 bytes, r = 250 Kbps Examples 3 and 4 both provide concrete guarantees that could be
verified by suitable measurements on the example service
irrespective of any other services offered in parallel with it.
(where R: peak rate, b: burst size, r: average rate) Blake, et al Expires: April 1999 4
There are also services which are not readily categorized as
qualitative or quantitative as in the following examples:
5. Traffic offered at service level E will be allotted twice the
bandwidth of traffic delivered at service level F.
6. Traffic with drop precedence AF12 has a lower probability of
delivery than traffic with drop precedence AF13.
Some of the characteristics that might be used to describe an SLA In example 5, the provider is quantifying the relative benefit of
between a customer and a service provider are discussed in the submitting traffic at service level E vs. service level F, but the
following paragraphs. customer cannot expect any particular quantifiable throughput. This
can be described as a `Relative Quantification Service'.
Bernet, et. al. Expires: November 1998 [Page 4] In general, when a provider offers a quantitative service, it will
2.1.1.1 Qualitative Performance and Quantitative Performance be necessary to specify quantitative policing profiles. In many
cases, quantitative policing profiles will be specified even for
services that do not offer quantitative performance.
SLAs may characterize Performance levels in qualitative (i.e., Determining how to monitor and audit the delivery of a qualitative
relative) terms, or in absolute quantitative terms. An example of a or relative quantification service in such a way as to convince the
qualitative performance guarantee would be "Traffic from stream A user that he has received fair measure requires careful attention.
will be given priority over traffic from stream B". An example of a It will be up to the customer to determine if the advantage offered
quantitative performance guarantee would be "Traffic from stream A, is sufficient to make the service worthwhile. The SLA must clearly
if provisioned at an average rate of 100 Kbps, with bursts not avoid making quantitative commitments for these services.
exceeding 64 KB allowed at a peak rate of 1 Mbps, will then have a
loss rate of no more than 0.001%, when averaged over the interval of
1 hour".
2.1.1.2 Throughput Characteristics 4.4 The Scope of a Service
Throughput characteristics (sometimes referred to as Token Bucket The scope of a service refers to the topological extent over which
Models) are another means to define a quantitative SLA. This model the service is offered. For example, assume that a provider offers a
could be used to describe a service that guarantees to deliver service to a customer which connects to their network at ingress
traffic at a certain sustained rate and to accommodate bursts of a point A. The service may apply to:
limited size up to a certain peak rate. 1. all traffic from ingress point A to any egress point
2. all traffic between ingress point A and egress point B
3. all traffic from ingress point A to a set of egress points
2.1.1.3 Latency Parameters Egress points may be in the same domain as the ingress point or may
be in other domains which are either directly or indirectly
connected to the ingress domain. If the egress point is in another
domain, it will be necessary for the ingress provider to negotiate
SLAs with the relevant peer domains, which will recursively
negotiate with their peers to ensure that the service offered at
ingress point A can indeed be extended to the egress points
specified. The scope of a service is part of the SLA governing
ingress point A.
A SLA may define maximum latency (or delay) as well as jitter bounds Blake, et al Expires: April 1999 5
for any packet within a specifically marked traffic stream within a In general, providers will be able to offer quantitative services
certain traffic profile. most efficiently when a specific set of egress points is specified.
Quantitative services which span multiple domains also require
tighter coupling between the SLA offered to the customer at ingress
point A and the SLAs negotiated with intermediate domains.
Qualitative services can more readily be offered to arbitrary sets
of egress points and require looser coupling between the SLA at
ingress point A and SLAs at intermediate domain boundaries.
2.1.1.4 Packet Loss (or Drop) Probability 4.4.1 Services Governing Received Traffic
A service may guarantee a limit on the percentage of packets dropped A special case of service scope is a service that governs all
from a certain flow. Typically, such a service is defined using traffic between any ingress point and egress point B. The SLA that
token bucket parameters and a drop probability. defines this service would be at egress point B and would
effectively allow the customer to control the mix of traffic
received from the provider. While such a service is theoretically
possible, it conflicts with the more traditional use of diffserv
which governs the quality with which traffic is sent, rather than
received.
This is typically a relative contract. For example - "When traffic A number of concerns would have to be addressed by such a service,
from flow A conforms to X token bucket parameters, it is 90% less including:
likely to be dropped than traffic from flow B. If it does not Traffic going to point B from an ingress point A under the terms
conform to the profile..." of the SLA of this service may also be governed by an SLA for
traffic submitted at point A. The SLAs may conflict and it will
not, in general, be possible to resolve all such conflicts across
all the ingress points.
- Establishing a traffic profile for this service at every possible
ingress which prevents overload of the receiver can be more
complex than for other service scopes: Static profiles are likely
to be either inefficient (e.g. dividing the egress profile into
fixed proportions) or risky (e.g. allowing every ingress to send
the whole profile) whilst dynamic profiles require processes and
communication mechanisms to coordinate the settings.
- Without effective ingress profiles for the service, denial of
service attacks will be a serious problem.
2.1.1.5 Additional Performance Parameters Some of the characteristics of receiver oriented services can be
provided by local policies and the SLA for the domain to which
traffic is sent via the egress point as described in Sec. 4.6.4.
Additional performance parameters may be offered using Blake, et al Expires: April 1999 6
specific PHBs. differentiated services does not dictate a
specific set of performance parameters.
2.1.2 Service Constraints 4.5 Dynamic vs. Static SLAs
SLAs may be offered which meet certain constraints in addition to SLAs may be static or dynamic. Static SLAs are the norm at the
those listed above. Two of the most obvious constraints are Locality present time. These are instantiated as a result of negotiation
and Time. between human agents representing provider and customer. A static
SLA is first instantiated at the agreed upon service start date and
may periodically be renegotiated (on the order of days or weeks or
months). The SLA may specify that service levels change at certain
times of day or certain days of the week, but the agreement itself
remains static.
2.1.2.1 Flow Locality-based Constraints Dynamic SLAs, on the other hand, may change frequently. Such changes
may result for example, from variations in offered traffic load
relative to preset thresholds or from changes in pricing offered by
the provider as the traffic load fluctuates. Dynamic SLAs change
without human intervention and thus require an automated agent and
protocol, in effect, a bandwidth broker to represent the
differentiated service provider's domain (such as suggested in
[BB]).
SLAs may be offered only for communication between specific ingress Dynamic SLAs also present challenging problems to both end users and
network providers:
- Network providers have to balance frequently changing loads on
different routes within the provider network. This requires the
provider to adopt dynamic, automated resource provisioning
mechanisms rather than relying on static provisioning.
- Customer equipment will have to adapt to dynamic SLAs in order to
make the most out of the changing SLA.
- End user applications may have to adapt their behavior during a
session to make the most of (or even, cope with) dynamic SLAs.
Bernet, et. al. Expires: November 1998 [Page 5] It is worth reiterating that the SLAs in Differentiated Services
and egress points. Others may allow combinations of various ingress apply to aggregates of traffic and not individual flows. For
or egress points. For example, services may be offered: scalability, it is undesirable to envisage modifying an SLA every
time a new micro-flow is added or removed from an aggregate.
a. For all traffic between ingress point A and egress point B. 4.6 Provisioning Traffic Conditioners in Boundary Devices to Provide
Services
b. For all traffic originating at ingress A, to any egress Once an SLA has been negotiated, the service provider (and
point. optionally the customer) will configure traffic conditioning
components at the boundary between the two networks. The service
provider does so with the goal of protecting the provider's network
such that the resources granted to the customer meet but do not
exceed the terms of the TCA. The customer does so with the goal of
making the best use of the service purchased from the provider. In
this section, we will briefly describe configuration of traffic
conditioners in boundary devices.
c. For all traffic originating at any ingress point, to egress Blake, et al Expires: April 1999 7
point B. Note that the provider's self interests require only that the
provider identify
- for which service level specific traffic is submitted,
- by which customer it is submitted, and
- for traffic with double-ended SLAs (i.e. SLA scope is type 2 or 3
of Sec. 4.4) only, the destination address to which the traffic
is directed.
d. For traffic from the group of ingress points A to the group Customer traffic may be authenticated either by the physical
of egress points B. connection on which it arrives or by some sophisticated
cryptographic means which is beyond the scope of this draft. The
provider need not be concerned with the customer's individual micro-
flows in delivering basic Differentiated Services (see Sec. 4.6.3
for additional services).
2.1.2.2 Time based Constraints [DSARCH] identifies four traffic conditioning components:
1. Meters
2. Markers
3. Shapers
4. Droppers
These SLAs would typically specify a reduced or improved performance The combination and interaction of the traffic conditioning
service for certain hours of the day and/or days of the week or components is selected on a packet-by-packet basis by the DS
month. codepoint. The configuration parameters for the components at each
codepoint are determined by the policies and profiles applied, so
that the conditioner polices the traffic in the BA specified by the
codepoint. Meters measure submitted traffic for conformance to a
profile, providing control input for the other components which
implement the policing:
- Shapers police by delaying submitted traffic such that it does
not exceed the traffic rate specified in a profile.
- Droppers police by dropping traffic that is submitted at a rate
exceeding that specified in a profile.
- Markers police by re-marking the traffic with a different
codepoint either
- to demote out-of-profile traffic to a different PHB,
- as a result of an SLA which specifies codepoint mutation, or
- to ensure that only valid codepoints are used within the
domain.
2.1.3 Other Service Characteristics In addition to these four components, traffic classifiers are
required in order to separate submitted traffic into different
classes. Classifiers may separate traffic based only on the DS-field
of submitted packets (BA classifiers) or may do so based on multiple
fields within the packet header and even the packet payload (MF
classifiers). MF classifiers may be used at boundaries to provide
certain per-micro-flow services to customers. Examples of such
services include per-flow marking or shaping. Typically, traffic
will arrive at the boundary of a DS domain pre-marked and
pre-shaped. However, at interfaces with some non-DS customer
Although differentiated services focuses primarily on performance Blake, et al Expires: April 1999 8
related characteristics, other non-performance characteristics may be networks, it is possible that traffic will require marking and
offered as part of a contract. shaping.
Examples of these non-performance-based characteristics might Even if a customer has pre-marked and pre-shaped, the service
include: availability and reliability, security (e.g., encryption). provider will wish to police the traffic at the ingress boundary to
meet the domain's self-interests. This may result in traffic being
re-marked or dropped.
The SLA shown in Sec. 2.1.1 defines two levels of service to the Traffic conditioning components (in particular, meters) will also be
customer at the specific boundary [CLARK]. the primary source of billing information for a differentiated
Services network.
2.2 Service Provisioning 4.6.1 Minimal Functionality at Provider's Ingress
In order to support a range of different services, a network would At the very least, the service provider must limit traffic carried
map all traffic into one or more of the PHBs that it supports. One on behalf of the customer to the constraints specified in the TCA. A
of the preconditions for satisfactory performance of the network is simplified TCA can be represented in the form of a table wherein
that the provider provision its network so as to be able to meet the each row has the format:
performance needs of the customers under normal operating conditions
according to the negotiated SLAs. Thus, adequate attention must be
given to the right selection of the speed of the network links
available within the DS domain of the network provider.
The provisioning of the network would be done on the basis of the DS-Mark : Profile : Disposition of non-conforming traffic
predicted (or contracted) traffic, which the network provider would
expect from its customers. The provisioning decision has to take
into account the needs for traffic belonging to different PHBs.
Let us examine two simple cases of PHBs that can be supported in the This row indicates that the provider commits to carry traffic marked
provider network. [DSHEAD] specifies two PHBs, an Expedited with 'DS-Mark' at the corresponding service level, provided that it
Forwarding PHB and a Default PHB. Packets marked with the Expedited conforms to the 'Profile'. Traffic that is submitted with 'DS-Mark'
and which does not conform to the 'Profile', is subjected to
'Disposition of non-conforming traffic'. This is generally a
policing action such as re-marking to a lower service level,
delaying in a shaper, or dropping. Alternatively, it may be carried
at the requested service level, but subjected to a surcharge. The
SLA for this type of service would normally be expected to be of
type 1 of Sec. 4.4.1, where the traffic destination can take it
through any egress point of the domain.
Bernet, et. al. Expires: November 1998 [Page 6] To provide this minimal functionality, the provider must configure a
Forwarding PHB are put into a queue which is serviced frequently, and BA classifier to separate traffic into the different service level
packets belonging to the Default PHB are serviced less frequently requested, based on DS-Mark. Following the BA classifier, each class
when the Expedited Forwarding queue is non-empty. Within this must be metered for conformance to the corresponding profile.
context, the network may expect a certain amount of traffic marked Following the profiler, either a dropper, shaper or re-marker is
with the Expedited Forwarding PHB between its various access points, likely to be employed. The Better than Best Efforts service
and a different amount of traffic marked by the Default PHB between described in Sec. 5.1 is an example of a service for which this
the different access-points. In order to meet the desired functionality is sufficient.
performance goals of the network, the network provider may decide to
provision the links in its network, or conversely, the SLAs, so that
the expected load due to Expedited Forwarding traffic on any node/
link in the network does not exceed a fixed percentage (e.g., 10%),
and the expected load due to the combined (Expedited Forwarding and
Default) traffic on any other element does not exceed another
(higher) percentage (e.g., 90%). There are well-established tools
and algorithms, which would enable the network provider to obtain an
optimum configuration of the network to satisfy these constraints.
Another PHB case may consist of defining a limited number of output 4.6.2 Functionality at Provider's Ingress for Double-ended SLAs
queues (e.g., four) at each of the routers in the DS domain. A
packet marked with one of the distinct codepoints is placed into one
of the four queues in the network. The queues are served using a
algorithm according to weights which are configured by the network
provider at the different routers. The network provider would
compute the expected distribution of traffic at each of the network
elements belonging to each codepoint. It would then assign weights
at the different routers so that they match the ratio of the
different traffic load expected at the specific router. With this
provisioning of the network, the provider can expect to satisfy the
average load on the network in a satisfactory manner.
In either of the two cases (or any other network provisioning case) If quantitative or other services needing double-ended SLAs (types 2
described above, the network provider's predictions of traffic may and 3 of Sec. 4.4.1) are implemented in a DS Domain, these services
not match the actual usage of the network. When the actual usage of specify the possible egress port(s) for traffic conforming to the
traffic exceeds the provisioned traffic for any specified codepoint, SLA. The traffic conditioner needs to consider the destination
the network provider may choose to regulate the amount of traffic address of the packet as additional input to the policing process,
that could be allowed into the network for a specific codepoint. The so that traffic is not accepted for egress ports for which an SLA
excess traffic may be discarded, smoothed, or converted to another does not exist. The Virtual Leased Line service described in
codepoint, or just billed at a different rate depending on the
policies adopted by the network provider.
A network provider would typically run metering and accounting Blake, et al Expires: April 1999 9
software on the access points to estimate the amount of traffic Sec. 5.2 is an example of a service that would require this
flowing between its different customer access-points. An estimation functionality.
of the these traffic flows can then be used in order to provide
admission control of traffic belonging to different codepoints in the
network (assuming some form of admission control protocol or policy
is in place).
When the network provider opts to use admission control to limit the A QoS VPN can be constructed by provisioning multiple instances o f
amount of traffic belonging to different codepoints (and hence services of type 2, building in effect, a mesh of point to point QoS
enforce or validate a given SLA), each access-point has a limit on links.
the amount of traffic it can inject into the network. The limit may
Bernet, et. al. Expires: November 1998 [Page 7] Services of type 3 are most likely to be used for multicast
be enforced as an aggregate depending only on the codepoint of the applications (see Sec. 9).
traffic entering the network, or enforced on separate traffic streams
which may be defined by the codepoint of the traffic as well as by
other header field values, including the destination access-point
(prefix) of the stream. Access control on the basis of separate
traffic flows or streams is better from the perspective of efficient
network resource usage, but requires the ingress access-point to
maintain more routing information to determine the egress access-
point. The shaping of the traffic based on some form of admission
control could be distributed to the edges of the network (i.e., host
or first-hop router) as needed. If this is done, then minimal state
is needed within the core of the network while still maintaining the
SLA.
In either of the two modes of access-control defined above, the DS 4.6.3 Added Value Functionality at Provider's Ingress
network needs to determine the amount of bandwidth to be assigned to
a specific codepoint at each access-node. The amount of bandwidth
may be obtained by management software in the network which
determines the routing topology of the network, obtains the expected
traffic at each access-point, and determines the correct admission
control limits for the traffic at each access-point. A distributed
version with admission control daemons that track resource usage at
each of the intermediate routers and hosts participating within the
DS domain can also be used.
2.3 Service Examples The functionality described in Secs. 4.6.1 and 4.6.2 serves only to
protect the provider's network resources in line with the terms of
the TCA. It provides no assistance to the customer. The burden of
marking packets and shaping traffic falls entirely on the customer.
In some cases, the SLA may call for the provider to provide
additional services to the customer. Such services may include:
1. Marking traffic from specific micro-flows to a specific behaviour
aggregate (marking the DS-field).
2. Policing traffic from specific micro-flows or sets of micro-
flows, either in the form of dropping or shaping.
In this section, we describe a few service examples, and show how In order to provide such services, the provider must generally
some specific PHBs could support them. We use two simple sets of employ an MF classifier in addition to the BA classifier. The need
PHBs. The first set of PHBs consist of two codepoints, one for an MF classifier arises only when the customer requires the
specifying Expedited Forwarding behavior and the other specifying a provider to provide some form of traffic separation or
Default behavior [DSHEAD]. The second set of PHBs consist of four authentication on behalf of the customer. The provider may charge
codepoints, each specifying a different queue at each router, the dearly for these services depending on the degree of granularity and
queues being serviced on a weighed basis as configured by the network the amount of work required. For example, shaping thousands of
provider [DSPREC]. customer micro-flows might consume considerable resources in the
provider's edge device. On the other hand marking based on source
subnet addresses would consume considerably fewer resources.
2.3.1 Services Enabled by First set of PHBs. 4.6.4 Functionality at Customer's Egress
The ISP offers three levels of service to the businesses that are Strictly speaking, the customer need not apply any specific traffic
hosting web-servers on its DS domain. The "Preferred Service" conditioning. In this case, the customer relies on the provider to
enables users trying to access the business sites with better mark as per negotiated MF classification criteria. In many cases it
performance for both the request and response of the web-server. The is preferable for the customer to mark. Customer marking may be
"Special Service" enables users trying to access the business sites necessary when customer packets are encrypted (as in the case of
with better performance for the web-responses, while the "Normal end-to-end IPSec). Customer marking enables the customer to direct
Service" provides the default performance for both requests and specific traffic from specific users or applications to specific
responses. service classes. This may be difficult or impossible for a provider
to do on behalf of a customer when, for example, applications use
volatile ports and users are assigned IP addresses based on DHCP.
In order to provide the services using the Expedited Forwarding and In addition to marking, it is in the customer's best interest to at
Default PHBs, the network provider maintains a list of the addresses least shape per service level, at the customer network's egress
and ports at which the preferred and special clients' web-servers are point. Otherwise, customer traffic may be policed by the service
operational. For all packets in which either the source host/port
Bernet, et. al. Expires: November 1998 [Page 8] Blake, et al Expires: April 1999 10
combination or the destination host/port combination identifies a provider with undesirable consequences (e.g. dropped packets).
preferred web-server, the packets are marked with the Expedited Shaping per service level does not however, provide for micro-flow
Forwarding codepoint. If the source host/port combination indicates traffic separation. As a consequence, a renegade traffic source may
a special service web-server, the packets are also marked expedited. cause the profile to be exceeded for a specific service level,
All other packets are marked with the default codepoint. Using this negatively impacting all customer flows which are marked for that
scheme, the right type of performance is given to the customers service level. Therefore, it is often in the customer's interest to
hosting a preferred web-server. shape or at least to police, with micro-flow granularity.
A second type of classification service may be provided by an ISP to 4.6.5 Functionality at Provider's Egress
its business clients using this PHB set. For each of the business
customers, some set of web-sites are identified as being more
relevant to their business. The ISP would provide expedited
forwarding to traffic from the web-sites that are considered relevant
to its business by the customer. As opposed to the preferred/special
service definition presented above, the customer accessing the web-
site, not the person hosting the web-site, drives the classification.
Such a marking can be done by supporting a PICS capable web-proxy at
each ISP access-point which uses a business rating system to classify
the web-pages into those relevant/irrelevant for a specific customer,
and marking the packets as Expedited Forwarding/Default
appropriately.
Another example of service that can be provided using this is At the egress from a provider's domain there may be an SLA in place
preferential service that may be given to "Premium Customers" when with a peer DS domain, which might be either another provider or an
they use the network provider to provide connectivity between end user domain. As in Sec. 4.6.4, it is in the provider's best
different customer premises. The packets, which contain the source interests to shape the traffic leaving the domain.
or destination addresses of the premium customers, are marked as
Expedited Forwarding packets while the other packets are marked with
the default codepoint. For example, an enterprise with an out-
sourced VPN which is replicating multiple databases or directories
across different geographies or other mission critical functions
across the VPN.
In this example, all data being transmitted between the mission Depending on the SLA, the egress may be required to remark and/or
critical replicated servers would be classified as "Preferred police or shape the traffic. Note that the forwarding treatment
Service" and given priority across the VPN (similar to a virtual applied to the packet in the egress node of the domain would be that
leased line). User traffic from outside the network destined to selected by the codepoint before it was remarked (otherwise, the
specific servers within the network (i.e., web-servers) might be egress node has to support multiple codepoint to PHB mappings).
given a different level of access called "Response Service". This
service would have other specific characteristics such as minimum
response time, latency and availability requirements. Any other
traffic on the VPN would be marked as "Normal Service" and would be
considered a best effort service, associated with the default PHB.
2.3.2 Services Enabled by the Second Set of PHBs The provider may also wish to offer additional services to a
customer by policing egress traffic with micro-flow granularity if
the customer might expect to receive excessive traffic in a single
BA and wishes to apply greater control than could be achieved by
normal policing of the aggregate. This would be specified via an
SLA in the usual way.
An ISP offers two services to its customer. The "voice" traffic 4.7 Internal Provisioning
results in a low bandwidth low-delay communication across the ISP
network. The "video" traffic results in a high-bandwidth low-delay
communication across the ISP network.
The "data" traffic provides behavior equivalent to that found in The provider must provision internal nodes in the provider network
to meet the assurances offered by SLAs negotiated at the boundaries
of the network. To do so, the provider may use similar traffic
conditioning mechanisms to those used at the network boundaries.
However, providers are unlikely to apply MF classification within
the interior of the network. The provider may police periodically
within the network, by reshaping, remarking or discarding traffic.
Service providers are experienced in provisioning large networks
which offer uniform service, assisted by predictive tools, traffic
modeling tools and real time measurements. Current techniques will
likely be applied to differentiated services networks, although, the
complexity of provisioning will increase significantly. In a
differentiated service network, the provider must ensure that
resources granted to traffic of one service level does not
inappropriately compromise assurances regarding traffic at other
service levels (for example, in example service 6, traffic in AF13
can legitimately compromise traffic in AF11 if an increase in AF13
traffic causes more AF11 traffic to be dropped). As mentioned
previously, internal provisioning in the case of dynamic SLAs will
likely require dynamic resource allocation protocols.
Bernet, et. al. Expires: November 1998 [Page 9] Blake, et al Expires: April 1999 11
current IP networks.
The ISP supports these three modes of services by mapping them into 4.8 End-to-End Service Construction
the three different queues at each router. The ISP periodically
recomputes the load and routing patterns of its voice and video
connections, regenerates the weights on each backbone router to
support this set of services, and reconfigures the router.
A second service offered by the same ISP is that of a fixed bandwidth The Differentiated Services architecture proposes that an end-to-end
pipe. The ISP offers a specific bandwidth between two access-points service can be constructed by the concatenation of domain services
of its customer. The ISP adjusts the weights of the different queues and their associated customer-provider SLAs for each of the domains
to meet the bandwidth requirements of all the customers passing which the service traffic has to cross.
through a router in the appropriate queue. These weights are only
recomputed when a new pipe is added or an existing pipe modified or
deleted.
3. Service Control Mechanisms Clearly, not all PHBs and services can be meaningfully concatenated,
and the definition of suitable services and their associated PHBs
will be a major focus of future Differentiated Services development.
This is discussed at greater length in Sect. 7.
3.1 Service Allocation and Configuration 5. Service Examples
Each access-point to a DS domain needs to be configured with the In this section, we describe service examples and show how they can
appropriate packet classification rules. At each of the access- be supported by specific PHBs. We base these examples on PHBs which
points, the provider of a specific DS-domain is either a provider to are defined in [AF]and [EF]. These examples are intended to be
a customer, or may be a customer of yet another provider. The illustrative of the wide range of services that can be employed
support of a SLA requires that the configuration of functional using the differentiated services model, and are not intended to be
components at the boundary be done with parameters that are designed an exhaustive list.
to support the required SLA performance levels. In order to support
specific services, specific functionality may be required of the
classifiers, meters, markers, shapers and policers at an access-
point [DSARCH].
Boundaries between two DS networks and between a DS and non-DS 5.1 Better than Best-Effort (BBE) Service
network, are of particular interest. At each such boundary, at least
one network is a customer and one is a provider. The provider agrees
to carry certain subsets of the customer's traffic at certain service
levels. This agreement is captured in the form of an SLA. Specific
functionality is required at such boundaries, to serve the needs of
the customer and the provider, subject to the SLA. This section
describes the methods by which such functionality may be configured.
3.1.1 Service Allocation This is a qualitative service which promises to carry specific web
server traffic at a higher priority than competing best-effort
traffic. Such a service offers relatively loose (not quantifiable)
performance from a given ingress point to any egress point. Such a
service is suitable for example for businesses offering access to
web based content. The BBE service enables the web content provider
to provide content at a generally higher rate than other content
providers are able to, in so reducing the latency experienced by
consumers of the web site.
Two types of SLA may exist, static and dynamic. A static SLA changes 5.1.1 Service Implementation
infrequently (typically weekly, or monthly) and typically is
renegotiated by human interaction. Dynamic SLA's change frequently
and typically are renegotiated via a machine to machine negotiation
protocol of some sort. Note that a static SLA may call for different
service levels to be supported at different times of day, in which
case, the service covered by the SLA changes automatically and
somewhat frequently, however, the agreement itself does not change
frequently.
In order to adhere to a SLA, it is useful to configure certain In this example, we assume that there is an SLA which defines the
functional components at access-points. These may include service at the customer's ingress point. This is the point at which
classifiers, meters, markers, shapers, and policers, as explained the customer injects web server responses into the differentiated
below. services network. The information in the TCA can be represented in
the following form [AF]:
An access-point to a DS domain can run in one of two modes of AF13 Mark : 1 Mbps : Any egress point : Excess traffic handled by
classification, as a microflow or traffic stream classifier (MFC), marking with AF11 mark.
or a bandwidth aggregate classifier (BAC). As a MFC, the access-
point classifies microflows (identified by the 5-tuple of src/dest IP
addresses, src/dest ports and the protocol) or traffic streams
(identified by subsets of the 5-tuple) and marks the DS field
according to the classification rules that are configured for it. As
a BAC, the access-point expects that the customer has already marked
the DS field appropriately after running a MFC function on its own
behalf, and only looks at the DS field. Even as a BAC, the access-
point may choose to remark the DS field as it may check the
aggregated traffic level associated with the DS field to make sure it
fits into limits defined for it by the appropriate SLA. In either of
the two modes, the access-point can perform the policing function on
the aggregate stream as a result of the classification process.
In the first mode, the customer applies no traffic conditioning. Packets submitted for the BBE service should be marked with the DS-
Instead, the customer contracts with the provider to do per-microflow field codepoint corresponding to the AF13 PHB. The provider is
or per-traffic stream classification, marking and policing. In the promising to carry up to 1 Mbps of traffic from the ingress point to
second mode, the customer applies per-microflow/stream classification any egress point at a higher priority than best-effort traffic. A
and marking. In this case, the provider applies aggregate (per- lesser class of service corresponding to the AF11 PHB will be
service level) classification and policing, to assure compliance with applied to traffic submitted for the AF13 PHB, in excess of 1 Mbps.
the SLA. It is assumed that all traffic from a single customer
arrives at an interface dedicated to the customer. If multiple
customers share a single interface, it will be necessary to apply
additional finer-grain classification for the purpose of
conditioning. Provider marking will typically be applied at the
periphery of the DS domains, where a DS network connects to
non-DS, stub networks.
Shaping is not included in the above discussion, but may be Blake, et al Expires: April 1999 12
recommended in the customer's network, or the provider's network or The provider will provision a policer at the ingress point. Traffic
both. submitted up to the 1 Mbps limit will be directed to the AF13 PHB.
Traffic submitted in excess of 1 Mbps will be remarked for the AF11
PHB. Note that the scheme will preserve ordering of packets since
AF13 and AF11 use a single queue..
Typically, flows will be shaped within the customer's network. By In order to provide this service, the provider will have to
shaping at the microflow level, the customer can maintain traffic implement the AF13 and AF11 PHBs in core network equipment. The AF13
separation, ensuring that no microflow will seize more than its share and AF11 PHBs can be implemented for example, using a single RIO
of the aggregate DS domain resources guaranteed by the SLA. By queue. The provider will also have to provision equipment within the
shaping at the aggregate stream level, the customer can assure core of the provider's network to provide the AF13/AF11 service. By
aggregate compliance with the SLA and for example can avoid charges provisioning the appropriate RED parameters, for example, the
that may have been negotiated as part of the SLA for excess traffic. provider is able to control the priority of AF13 traffic relative to
However, by shaping at the aggregate stream level only, the customer AF11 traffic at each network node. Since there are no quantitative
cannot assure traffic separation once the traffic is injected into guarantees, the provider can be quite liberal in its provisioning
the service provider's network. strategy and may realize significant statistical multiplexing gains.
Also, the absence of quantitative guarantees makes it easy to
provide this type of service across multiple DS provider domains.
This is because is not necessary to negotiate, then provision and
enforce quantitative guarantees at multiple boundaries.
Devices that do full microflow classification will be more complex 5.2 Leased Line Emulation Service
than those that just offer bandwidth aggregation classification
support. The costs associated with these devices will should be
considered when determining where the classification and flow shaping
should occur within the DS domain. In certain cases, the customer
may contract to have the provider apply microflow or aggregate
shaping. This is a form of value-add which providers may offer
customers that are incapable of providing their own shaping.
Obviously, wherever shaping is applied at a microflow level, This is a quantitative service which emulates traditional leased
microflow classifiers will be required. Wherever shaping is applied line service. As such, it promises to deliver customer traffic with
at the behavior aggregate (BA) level, BA classifiers will be very low latency and very low drop probability, up to a negotiated
required. In general, classifiers are required only to support other rate. Above this rate, traffic is dropped. Such a service is
traffic conditioning functionality such as policing, marking, and/or typically offered between two specific points. It is suitable for
shaping. Subsequent discussion of specific functionality implies the many customer applications. However, due to the high quality
co-existence of the appropriate classifier. guarantees, it is likely to be priced higher than alternate services
and therefore, to be used only for applications which really require
this type of service. An example of such an application is IP
telephony. A corporate customer might purchase leased line emulation
service between each pair of a number of corporate network sites.
A static SLA with marking performed by customer requires that the 5.2.1 Service Implementation
customer provide an MFC at or before its egress, and the provider
provide a BA policer at the ingress access-point. A static SLA with
provider marking would require that the access-point support a MFC
and BA policer at the ingress access-point.
3.1.2 Service Configuration In this example, we consider a customer with three geographically
dispersed networks interconnected via a single provider network.
Customer attachment points are represented as A, B and C. At each
attachment point, an SLA describes the leased line service to be
provided to the other two points. The table below represents the
information required in the TCA at attachment point A:
Configuration requirements may vary depending on several parameters: EF-Mark : 100 Kbps : Egress point B : Discard non-conforming traffic
Variations in the distribution of the configured functionality, e.g., EF-Mark : 50 Kbps : Egress point C : Discard non-conforming traffic
use of the MFC mode versus the BA mode, specific functional
components being configured (policers versus markers), and the nature
of the SLAs (static versus dynamic). The functionality and
operational mode of access-points (egress as well as ingress) need to
be specified within a DS-domain.
In order for the classification to work efficiently, it must be Packets submitted for leased line service should be marked with the
simple and easy to configure. Furthermore, the configuration of DS-field codepoint corresponding to the EF PHB [EF]. From the
different access-points must be consistent. Otherwise, the ingress point A, to the egress point B, the provider is promising to
performance of the service provided to the different customers may be
erratic. For example, assuming the preferred ISP service described
in Section 2.3.1 is being supported, all the access-points must have
an entry classifying the same set of sites into its "Preferred"
class. Note that consistency does not imply that the configuration
information is identical for all the access-points. In the special
ISP service described in Section 2.3.1, the configuration entry for
each web-server needs to be only present at the access-point to which
the web-server is attached.
The simplest approach to the configuration problem is to ignore it. Blake, et al Expires: April 1999 13
The assumption would be that the ISP would configure each router carry up to 100 Kbps of traffic. Excess traffic will be discarded.
manually, and in a static manner. This solution requires extensive From ingress point A, to egress point C, the provider promises to
manual upgrade to each ISP router whenever a new service or a carry 50 Kbps of traffic. Of course, there is some tolerance
customer is added or deleted. The solution would not work well in required in policing the traffic and thus, there may be a
practice. specification of tolerated jitter or burst size. However, for a
leased line service, the primary traffic profile parameter would be
the sustained traffic rate.
Another option might be for the DS field to be marked with the The provider will provision a policer at ingress point A to limit
correct PHB service request by hosts or first-hop routers within the traffic destined for egress point B, to 100 Kbps. Similarly, a
CPE and then expedited through the ISP's (and billed based on this policer will be configured to limit traffic destined for egress
service) network as described. point C, to 50 Kbps. These policers will require classification
based on the DS-Mark and the destination address in each packet.
The ideal solution should provide a single administration point where In order to provide this service, the provider will have to
the ISP can enter the configuration rules from a centralized site. implement the EF PHB in core network equipment. The EF PHB can be
The configuration information should also permit scalability, in that implemented using strict priority queuing or alternatively, by
a large number of different ingress routers should be capable of assigning EF marked packets to a heavily weighted queue in a WFQ
receiving the configuration information. At the same time, the scheme. The provider will have to provision equipment within the
configuration information should not become a single point of core of the provider's network. For example, routers carrying
failure, which can bring the entire network to a halt. One solution traffic between point A and points B and/or C will have to be
to the configuration problem is a protocol, which permits the provisioned considering the resources committed by the TCA at point
administration at a single master site, but allows replication to A. This means that a router which is both in the path from A to B
several slave/mirror sites, which can be looked up by a large set of and from A to C, will have to be considered to have committed 150
access-points to permit a scalable operation. Kbps of bandwidth as a result of the TCA in place at A. A router
that is only in the path from A to B, will have to be considered to
have committed 100 Kbps as a result of this TCA, and so on. Of
course, routing is subject to change and so, failover paths may have
to be provisioned as well. These may be provisioned to provide some
fraction of the service in the case of failover or alternatively,
the SLA at point A might reflect appropriate service availability
parameters. To enhance the assurances offered by EF service,
providers may employ route pinning mechanisms or QoS routing
mechanisms.
Another desirable attribute for scalability would be the ability to 5.3 Quantitative Assured Media Playback Service
cache a limited set of classification rules and to query other rules
as and when needed.
Several alternatives exist for such a configuration policy. Some of This service offers looser assurances than the leased line service
these alternatives are outlined below: described above, but is still considered a quantitative service. In
particular, it promises to deliver traffic with a high degree of
reliability and with variable but bounded latency, up to a
negotiated rate. Above this rate, traffic is subject to significant
delay or drop. Such a service is typically offered between a
specific set of points. It is suitable for many customer
applications. It would likely be priced lower than a leased line
service, due to the latency variability. However, due to the latency
bound and high degree of delivery, it is likely to be priced higher
than alternate services. This service is particularly suitable for
video or audio playback, in which considerable bandwidth is required
on a continual basis, but the non-interactive nature of the traffic
makes it somewhat delay tolerant.
The SNMP MIB approach: Blake, et al Expires: April 1999 14
One may define a diffserv-specific SNMP MIB that needs to be 5.3.1 Service Implementation
supported at each of the access-routers, and can be populated using a
SNMP manager. The MIB definition approach would enable a centralized
administration of the configuration information.
However, the MIB approach does not enable caching in an efficient In this example, we again consider a customer with three
manner. Since the MIB for each access-point would have distinct geographically dispersed networks interconnected via a single
entries, consistency would have to be enforced using a layer above provider network. The table below represents the information
the SNMP manager. required in the TCA at attachment point A:
The LDAP approach: AF13-Mark : 100 Kbps sustained, 100 Kb bursts tolerated at up to 200
Kbps : Egress point B : Excess burst traffic over sustained rate
marked with AF12-mark : Non-conforming traffic marked with AF11-mark
: Max latency = 1 second
One can store the configuration entries in a directory accessible AF13-Mark : 50 Kbps sustained, 100 Kb bursts tolerated at up to 100
using the LDAP protocol. The directory is looked up at the Kbps : Egress point C : Excess burst traffic over sustained rate
initialization of the access-point. Directories permit centralized marked with AF12-mark : Non-conforming traffic marked with AF11-mark
administration at one master site, and support replication to : Max latency = 2 seconds
different slave sites. The access-point can also cache portions of
the classification rules, and can query the appropriate rule when
they detect the initiation of a new session (e.g. seeing a TCP header
with the SYN flag). The directory schemata also permit a way to
provide configuration information for a group of access-point in a
single entry, which can provide consistent configuration across
several access-points. The one drawback of the directory protocol is
inadequate support for asynchronous notification, which is currently
being discussed, in the various working groups. A tentative schema
for classification rules using this schema has been proposed in
[Ellesson].
The COPS approach: Packets submitted for the assured playback service should be marked
with the DS-field codepoint corresponding to the AF13 PHB. From the
ingress point A, to the egress point B, the provider is promising to
carry up to 100 Kbps of sustained traffic with bursts of 100 Kb in
size at a peak rate of 200 Kbps. Excess burst traffic will be marked
with the codepoint for AF12 and out of profile traffic will be
carried but with the AF13 codepoint. So long as these conditions are
met, latency will be limited to 1 second. Note that for this
service, the traffic profile is described using a full set of token
bucket parameters. Since the latency bounds for such a service are
less strict than those required for the leased line service, a
certain degree of traffic burstiness can be tolerated.
One can extend the policy query protocol for RSVP to provide The provider must support the AF11, AF12 and AF13 PHBs in core
classification information for differentiated services. COPS network routers. These PHBs might be provided, for example, by
supports asynchronous notification in a better way but has not yet assigning AF11, AF12 and AF13 marked traffic to a single RIO queue
addressed issues of replication of classification rules at different with high drop thresholds. The policers at the edge would limit
sites [COPS]. COPS extensions that support diffserv semantics would competing traffic in line with the TCA, in order to assure that the
need to be developed in order to use this approach. latency bounds can be met. In addition, the service provider will
have to provision devices in the core of the network. The
provisioning considerations discussed in the context of the leased
line service apply here as well, however, in general, the service
provider has the liberty of being less conservative in provisioning
and realizing better statistical gains.
When dynamic SLA's are being supported, the above mentioned 5.4 Superposition of Quantitative and Qualitative Services in the Same
configuration approaches need to be augmented with a negotiation Network
protocol between the customer and provider network to negotiate the
current details of the service levels. To this end, a standard
protocol is required between customers and providers. Such a protocol
would enable customers to present requests to providers that would
result in changes to the SLA. Entities within the provider's network
would respond to these requests by determining if the requested SLA
could be met, adjusting the policers accordingly and responding to
the customer's request. The bandwidth broker, as described in [BB]
is such an entity.
One realization of such a protocol is RSVP [RSVP]. Other protocols A compelling model would provide both quantitative and qualitative
could also be devised for this purpose. services in the same differentiated service network(s) as follows. A
number of corporate campus networks would be interconnected by a
differentiated service network providing quantitative services
between the sites. For example, a mesh of leased line services would
3.1.2.1 Functionality Required at Boundary Equipment Blake, et al Expires: April 1999 15
enable IP telephony between the sites. A mesh of media playback
service using the AF11 PHB would enable audio/video playback between
the sites. In addition, each corporate site would be allotted some
level of BBE service to arbitrary destinations. In this model, the
differentiated service network is effectively providing a mesh of
quantitative services between fixed locations (similar to a VPN).
This mesh is superimposed on a cloud supporting BBE service.
In the interest of adhering to the SLA, it is useful to configure 6. Provisioning and Configuration
certain functional components at DS boundary nodes. These may
include classifiers, markers, meters, shapers and policers as
described in the following section.
The following basic combinations of functional components are The provision of differentiated services requires careful network
possible: wide provisioning and configuration. Provisioning refers to the
determination and allocation of the resources needed at various
points in the network. Provisioning may dictate the addition or
removal of physical resources at various points (physical
provisioning). Provisioning may also dictate the modification of
operating parameters within existing physical network equipment to
alter the relative share of the equipment's resources which are
allotted to one or another class of traffic (logical provisioning).
Configuration refers to the distribution of the appropriate
operating parameters to network equipment to realize the
provisioning objectives.
Mode Customer's Egress Provider's Ingress In Secs. 4.6 and 4.7, we briefly discussed provisioning and
configuration requirements both at the network boundaries and in the
network interior. In this section we will focus primarily on the
coordination of provisioning and configuration throughout the
network, such that end-to-end services can be provided reliably. We
will discuss the roles of protocols such as SNMP, CLI, RSVP, COPS
and LDAP in the provisioning process.
Provider marking None MFC, BAC, M, P 6.1 Boundary vs. Interior Provisioning and Configuration
Note: Provider classifies microflows to aggregated service level For the sake of brevity, consider the term 'provisioning' to refer
and marks DS field accordingly. Provider polices based on both to provisioning and configuration, except where otherwise
aggregate. noted. It is helpful to consider provisioning at the network
boundaries, separately from provisioning of the interior. Since the
differentiated service provider is selling a contract (SLA) at the
network boundary, we can consider the boundary provisioning which
supports SLAs, to drive the interior provisioning. The two are not
entirely separable in that each affects the other. For example, a
network operator cannot offer an SLA which cannot be met by the
resources available in the interior of the network. In general, the
overall provisioning process iterates between the boundaries and the
interior. From here on we will refer to provisioning with respect to
the TCA rather than the SLA, since the TCA is the component of the
SLA that defines detailed traffic handling parameters.
Customer marking MFC, M BAC, P Blake, et al Expires: April 1999 16
Note: Customer classifies microflows to aggregated service level 6.1.1 Boundary Provisioning
and marks DS field accordingly. Provider polices based on
aggregate.
MFC - MF Classifier Boundary provisioning was considered briefly in Sec. 2.6. We
BAC - BA Classifier discussed the minimal provisioning that a provider must implement to
enforce a TCA. We also discussed additional configuration which a
provider may use to provide additional (especially per-flow)
services to a customer. The latter is not actually related to the
provisioning of resources within the differentiated services
network, but rather assists the customer by determining which
subsets of the customer's traffic make use of the resources
provisioned within the differentiated services network. As such, it
is out of the scope of this section. Here, we consider only the
minimal provisioning required at the boundary.
M - Marker At a minimum, the provider must assure that sufficient physical
resources are provisioned at the boundary to meet the requirements
of the TCA. For example, if the sum of the profiles supported at a
particular ingress point would allow 10 Mbps of traffic to be
supported, it is unacceptable to provision a T-1 access link. A T-3
however, would be sufficient. Once the physical provisioning is
implemented, it is necessary to apply the appropriate logical
provisioning. This is achieved by configuring policers which limit
the amount of traffic accepted from the T-3 access link, at each
service level. It may also be necessary to set up the amount of
buffering available for the queues used for the service. Similar
provisioning is also appropriate at each egress point if the
aggregate of profiles provisioned to the egress exceeds the capacity
of the output link.
P - Policer (policing shaper) 6.1.2 Interior Provisioning
In the first example, the customer applies no traffic conditioning. For the purpose of provisioning the interior of the network, it is
Instead, the customer contracts with the provider to do per-microflow desirable to understand or to control the volume of traffic of each
classification, marking and policing. In the second example, the class which traverses each network node. The greater this
customer applies per-microflow classification and marking. In this understanding, the more efficiently the network can be provisioned
case, the provider applies aggregate (per-service level) while still meeting the requirements of the TCAs. It is feasible to
classification and policing, to assure compliance with the SLA. It understand the volume of traffic traversing each node if this
is assumed that all traffic from a single customer arrives at an traffic is admitted according to a TCA which dictates egress point
interface dedicated to the customer. If multiple customers share a as well as ingress point. (This case generally applies to
single interface, it will be necessary to apply additional finer- quantitative services and was discussed in the context of the EF PHB
grain classification for the purpose of policing. and the leased line service in Sec. 3.2.1). While traffic volumes
cannot be anticipated with 100% accuracy, it is possible to
approximate them quite well, especially with the help of route
pinning mechanisms. It is therefore possible to provision the
network reasonably accurately for traffic submitted for quantitative
services. Although such provisioning may be quite difficult in a
large network, it is nonetheless a tractable problem. We will refer
to this component of the provisioning problem as quantitative
provisioning.
Provider marking will typically be applied at the periphery of the DS Blake, et al Expires: April 1999 17
domains, where a DS network connects to a non-DS, stub network. On the other hand, many (if not most) of the services offered by
differentiated service networks will not specify egress points (as
is the case for qualitative services) and will not restrict
submitted traffic to specific egress points, let alone specific
routes. Thus, interior nodes will have to be provisioned without an
a-priori understanding of the volume of traffic submitted for
qualitative services which will arrive at each node. It is necessary
to be able to provision differentiated service networks to support
both quantitative services with specific egress points as well as
qualitative services, which do not have specific egress points on
the same physical resources. To this end, it is necessary to isolate
the impact of qualitative traffic on the resources reserved for
quantitative traffic. This can only be achieved if the former is
treated with lower priority than the latter. Thus, in general,
resources will have to be provisioned first for quantitative
traffic, using quantitative provisioning mechanisms. Then,
qualitative provisioning can be used to allocate remaining resources
to qualitative traffic. Qualitative provisioning can also be
applied to services which offer a relative quantification of traffic
volumes.
Note that shapers are absent from the table above. Shapers are not The impact of the two types of traffic will have to be isolated by
strictly required but are recommended, at the customer's network, the ensuring that they do not share PHB codepoints. PHBs used for
provider's network, or both. quantitative services will always have higher priority access to
resources than those used for qualitative services. As a result, it
is necessary to carefully police traffic submitted for quantitative
PHBs. Failure to do so can result in the starvation of lower
priority traffic. In general it can be expected that only a small
fraction of the resources at each node will be provisioned for
quantitative traffic.
Typically, flows will be shaped within the customer's network. By Similarly, a significant fraction of the traffic capacity should
shaping at the microflow level, the customer can maintain traffic remain for best-efforts service to provide a 'soft' target for
separation, ensuring that no microflow will seize more than its share traffic dropping if congestion occurs or it is necessary to redirect
of the aggregate DS domain resources guaranteed by the SLA. By non-best efforts traffic in the event of failure.
shaping at the aggregate stream level, the customer can assure
aggregate compliance with the SLA and for example can avoid charges
that may have been negotiated as part of the SLA, for excess traffic.
However, by shaping at the aggregate level only, the customer cannot
assure traffic separation.
In certain cases, the customer may contract to have the provider 6.1.2.1 Quantitative Provisioning of the Interior
apply microflow or aggregate shaping. This is a form of value-add
which providers may offer customers that are incapable of providing
their own shaping. Obviously, wherever shaping is applied at a
microflow level, MF classifiers will be required. Wherever shaping
is applied at the behavior aggregate level, BA classifiers will be
required. In general, classifiers are required only to support other
functionality such as meters, markers, or shapers. Subsequent
discussion of specific functionality implies the co-existence of the
appropriate classifier.
3.1.2.2 Configuration of Functionality at Boundary Equipment As discussed previously, quantitative provisioning is a difficult
but tractable problem. With knowledge of the network routing
topology and the TCAs at the boundaries, it is possible to compute
the resources required at each interior node to carry the
quantitative traffic offered at the edges. Based on the results of
this computation, interior nodes must be provisioned and configured
with sufficient capacity to accommodate the quantitative traffic
which will arrive at the node, while leaving sufficient capacity
remaining to accommodate some amount of qualitative traffic.
Configuration requirements may vary depending on the following The provisioning mechanism described assumes a top-down approach, in
parameters: which the network administrator studies the network topology and
traffic routing and computes the provisioning requirements. An
1. Variations in the distribution of configured functionality, as Blake, et al Expires: April 1999 18
described in the previous section. alternative approach uses signalling to automate the process [MPLS].
For example, RSVP messages could be launched along the paths that
will be followed by submitted quantitative traffic. If a TCA calls
for 100 Kbps of leased-line service from ingress point A to egress
point B, an RSVP message could be transmitted from point A towards
point B, with a flowspec specifying 100 Kbps. This message would
traverse each node at which resources would have to be committed.
Conventional RSVP routers would install a reservation. In a
differentiated service network, RSVP could be adapted to provision
the resources required per the differentiated services model. In a
network which offers a number of static TCAs, such RSVP messages
could be launched from the TCA ingress point at the time the TCA is
initially instantiated with the effect of instantiating the
appropriate cumulative provisioning in routers along the various
routes. The advantage of this approach is that it does not require
explicit knowledge of the network topology. We will revisit these
two approaches to quantitative provisioning of the interior in a
later section.
2. The functional component configured (for example, policing vs. Once the resources required for quantitative traffic at each node
shapers vs. markers). have been determined, provisioning of the node consists of
installing or configuring interfaces of the appropriate capacity to
easily accommodate the quantitative traffic that will traverse the
node. Note that we do not state the precise meaning of 'to easily
accommodate'. A number of factors must be considered when
determining the appropriate capacity, given a certain volume of
predicted quantitative traffic. These include:
1. Margin of error
2. Statistical gain desired
3. Capacity remaining for qualitative (including best efforts)
traffic
3. The nature of the SLA (static vs. dynamic). The first, margin of error, accommodates mistakes in computation,
effects of transient route changes which are not otherwise accounted
for, effects of traffic clustering as it moves through the network
and so on. The statistical gain desired refers to the degree to
which a provider is willing to gamble that not all sources of
quantitative traffic will be simultaneously active at the limit
dictated by the TCAs at the ingress points (vs. the penalty the
provider would be willing to pay in terms of refunded charges or
lost customers). Finally, the provider must determine how much
capacity will be reserved for qualitative traffic at each node.
Thus, if it is determined that 1 Mbps of quantitative traffic might
traverse a specific node in a specific direction, the provider might
install a 10 Mbps interface in the node, to serve the corresponding
traffic direction. This would leave 9 Mbps of capacity quite safely
for qualitative traffic. In this case, the provider would be
assuming that statistical gains which might be realized will be used
to offset the margin of error which would compromise the resources
available.
This section describes configuration methods subject to the Blake, et al Expires: April 1999 19
variations listed. In addition to installing or configuring the appropriate capacity at
each interface, it may be desirable to configure policers to assure
that the resources actually consumed by the higher priority
quantitative traffic do not exceed expectations. This is especially
important if the provider is attempting to achieve a high degree of
statistical gain or has not allowed for a reasonable margin of
error. Policers need not be configured at each interior node, but
should probably be configured at certain key nodes. It may also be
necessary to configure the internal resources of the router (queues
and buffers) to deliver the services required.
3.1.2.3 Static SLA, Provider Marking 6.1.2.2 Qualitative Provisioning of the Interior
In this scenario, it is necessary to configure the following As explained previously, it is necessary first to determine the
functional components: resources which must be provisioned at each node for quantitative
traffic. Once these have been determined, interfaces must be
installed or provisioned to accommodate the required resources while
leaving sufficient capacity for qualitative traffic. In order to do
so, it is necessary to determine the resources required at the node
for qualitative traffic. Since qualitative traffic cannot be assumed
to follow specific routes with the same degree of predictability as
quantitative traffic, this provisioning problem is far more
difficult and provisioning parameters must be estimated based on
heuristics, experience and possibly on real time measurement.
1. A MF classifier + marker at the provider's ingress node. Once physical interfaces have been selected to accommodate the
resources required by the computed quantitative traffic load and the
estimated qualitative traffic load, additional configuration is
required to support qualitative traffic. Such configuration amounts
to the selection of relative weights for queues for different
service levels (in a WFQ scheme), or the selection of RIO or RED
thresholds or alternate logical resource provisioning parameters. It
is assumed that if quantitative traffic is accommodated via similar
queuing mechanisms (as opposed to strict priority queuing), that the
weighting parameters chosen for quantitative traffic isolate it
effectively from the effects of qualitative traffic. However, the
configuration parameters which differentiate the various qualitative
services may not provide such a degree of isolation among the
qualitative services. Thus, it may be necessary to attempt to
estimate the relative traffic arriving for each qualitative service
and to anticipate the interaction between traffic of different
qualitative services. It may be impossible to both efficiently and
conservatively provision a network for certain combinations of
qualitative services. To aid in the provisioning of a network for
qualitative services, it may be useful to configure policers to
control the volume of traffic arriving at a given node. However,
such policing might have to be restricted to shaping (rather than
discarding) in order to avoid violating TCAs in place at the network
boundaries.
2. A BA policer at the provider's ingress node. Blake, et al Expires: April 1999 20
The SLA specifies the traffic profiles that should be configured per- 6.2. Static vs. Dynamic Provisioning
service level for the policer at the ingress node of the provider's
network. The format of the information to be configured is tabulated
in Sec. 2.1.1. Since the SLA is static, this information changes
infrequently and likely requires human intervention.
Therefore, the policer will typically be configured remotely via SNMP So far, we have considered static provisioning techniques. Even the
or via a command-line interface. example of RSVP usage for provisioning assumed that the RSVP
messages were launched at the time a TCA was instantiated as opposed
to dynamically. In the case that TCAs are static, static
provisioning is adequate for quantitative traffic. However, since
qualitative traffic [e.b.1] offers less predictable patterns, it is
likely to cause traffic volumes at different nodes in the network to
change dynamically, even when the TCA is static. For this reason,
dynamic provisioning techniques are desirable and may assist the
service provider in making better use of network resources. In
addition, dynamic provisioning may enable the service provider to
provision more liberally for quantitative services, realizing
statistical gains. If we consider further, that it may be desirable
to provide dynamically changing TCAs, then the appeal of dynamic
provisioning techniques is even stronger.
The marker configuration is actually independent of the SLA. Dynamic provisioning may be signalling based, measurement based or
both. For example, a conventional RSVP router supports signalling
based dynamic provisioning. Hosts signal the router to request more
or less resources and the router adjusts accordingly. The host may
or may not actually submit traffic at the rate at which it signalled
it would, but regardless, the resources are committed in case it
does. Measurement based provisioning would adjust the resources
committed in response to the traffic loads actually measured at the
device. While differentiated services does not specify any form of
signalled or measurement based provisioning, both may be useful.
The customer may contract the provider to mark any service level 6.3 Distributing Configuration Information
based on the results of the MF classification.
Configuring the marker is similar to configuring access lists on The process of physical provisioning is by necessity relatively
standard switches and routers. Such lists take the form of "n-tuple: static and cannot be automated since it requires installation of
service level", where "-tuple" refers to some combination of possibly physical equipment. However, logical provisioning and configuration
masked values in packet headers. Such information is lengthy and can and should be automated to the degree possible. In this section,
error prone. In addition, it is subject to change more frequently we look at techniques for distributing configuration information.
than a static SLA and, does not require the approval of the provider.
While it is possible to configure markers using the same static 6.3.1 Top Down Distribution of Configuration Information
methods as used to configure the policers (SNMP and/or command-line
interfaces), there are strong incentives to provide dynamic marker
configuration via a standard protocol that is available to the
customer. RSVP may be used for this purpose.
3.1.3 Receiver Control In the simplest case, TCAs are static and both the boundaries and
interior of the network are provisioned statically by 'pushing'
configuration information down to the appropriate network nodes.
Configuration of boundary nodes requires primarily the pushing of
policing information to enforce the TCAs in place. (Additional fine
grain information may be pushed to provide traffic separation
services on behalf of the customer, but these are not addressed in
this context). Configuration information for boundary nodes is
determined at the time the TCA is negotiated. At this time, the
nodes are configured by the provider. The network administrator may
use one of several protocols to do so, including for example SNMP or
CLI.
In differentiated services there are two possible types of receiver Blake, et al Expires: April 1999 21
control. One, which has been addressed in a previous section, is In order to accommodate the traffic submitted by the provisioning of
when the receiver is allowed to control how the marking of the DS new TCAs, it is necessary to provision the interior of the network.
field is performed at the sender side. This can be done either in As discussed previously, it is possible to compute the resources
accordance with a static SLA that the user has with the provider, or required for quantitative traffic. Assuming that sufficient physical
by use of application- or session-level signaling which induces the capacity has been provisioned, configuration amounts to logically
sender (or a DS edge node) to mark the packets in accordance with the provisioning sufficient capacity at each interior interface and to
receiver's preferences. configuring policers for the quantitative traffic at various
interior nodes. In addition, qualitative provisioning requires the
configuration of queues, WFQ weights and/or RIO parameters at
various interior nodes, and may also include the configuration of
some number of policers. In the case, of static, top down
configuration, interior configuration information is also pushed
down via a configuration protocol such as SNMP or CLI.
Another type is when the receivers need to control the priority of The difficulty of such top down provisioning is that it requires the
packets that arrive from the network onto his/her access link. There network administrator to coordinate the provisioning of each network
are two reasons why this is important. One is that it provides node, at boundaries as well as in the interior, such that the
protection from certain types of denial-of-service attacks. The network is provisioned end-to-end in a consistent manner and is able
other is that this is important on low bandwidth access links, in to efficiently deliver the services promised by the TCAs. In order
particular for mobile IP hosts. to assist the network administrator in this task, it is useful to
consider a database which holds both current topology information as
well as the current TCAs instantiated at the network boundaries.
This information is stored in a format dictated by a standard schema
as suggested in [Elleson].
At the last-hop router, before the egress link, traffic from Of course, the database is ideally maintained in a way which is
different sources are merged onto the access link of the receiver logically centralized (for ease of programming and modifying) but is
(destination). Some packets might have been marked with respect to physically distributed (for the sake of robustness and fault
the SLA the receiver has with the ISP, others might not. To allow tolerance). Policy servers may be used to extract information from
the receiver to control which traffic gets priority on its access the database and to convert it to configuration information which is
link it should be allowed to direct the egress node re-mark (or use pushed down to individual nodes. In this scenario, policy servers
an alternative PHB than what is in accordance with the marking that would likely use a directory access protocol such as LDAP to
was made with respect to the sender's SLA) packets at the egress retrieve information from the directory and would use a
node, in accordance with a "receiver marking policy". This can be configuration protocol such as SNMP or CLI to push the configuration
thought of as a special case of a static or dynamic SLA between a information down to the network nodes. Note that in this example,
downstream network (the ISP) and an upstream network (the receiver). the policy servers and the directory schemas are in effect
fulfilling the role of bandwidth broker [BB]. In particular, the
policy servers use an awareness of the network topology to provision
interior nodes such that certain end-to-end QoS routes can be
constructed and assurances implied by the TCAs at the boundaries can
be delivered.
Such a "receiver marking policy" could e.g. state that all IP 6.3.2 Distribution of Configuration Information via Signalling
telephony traffic (e.g., identified by a particular source port
number) should be given priority to all other traffic.
3.1.4 Policy Protocols An alternate mechanism of distributing configuration information is
via signalling messages transmitted between boundary nodes of the
same differentiated service domain (intra-domain signalling). It is
also interesting to consider inter-domain signalling, but this will
be addressed separately. An example of such signalling was described
previously, in the usage of a modified form of RSVP. Such signalling
Two types of requests have been described which can result in Blake, et al Expires: April 1999 22
allocation of resources to particular users (at the expense of is particularly useful for the purpose of installing configuration
others), and which may result in charges to customers. The two types information for quantitative services which affect specific paths
of requests are requests to mark traffic for prioritized treatment and is somewhat less useful (though not useless) for the purpose of
(subject to the terms of an existing SLA), and requests to change configuring qualitative services. It is likely that such a
the existing SLA. These requests should be governed by policy signalling approach would be used in conjunction with top down
decisions. Information required to make policy decisions must be provisioning. For example, the directory schema might dictate the
conveyed to policy servers. These must reply with approval or amount of resources to be available for high priority quantitative
rejection of the request. COPS is an example of a policy protocol services at each node. These limits might be pushed down to
suitable for carrying such requests. individual nodes a- priori. Signalling from the network boundaries,
at TCA instantiation time, would then be used to claim resources
from the pool of quantitative resources available at each node.
Alternatively, nodes might consult policy servers as the signalling
resource requests arrive at each node. The latter model is similar
to the use of per- flow RSVP signalling and PEP/PDP policy usage in
traditional RSVP networks. Qualitative configuration information
would still be pushed in a top down manner. The advantage of the
latter model is that policy servers would be dynamically updated
with information regarding the current usage of network resources.
In this model, it is likely that a variant of COPS would be used to
communicate between network nodes and the policy servers. Note that
COPS may be used for distribution of top down configuration
information as well, though it is not specifically designed for this
purpose.
3.2 Requirements for Measurement and Management. One of the advantages of configuration via signalling, is that it
facilitates the support of dynamic TCAs. TCAs could be dynamically
renegotiated using inter-domain signalling. Such renegotiation would
require dynamically modifying the provisioning within the affected
domain, a process which requires some automated signalling protocol
such as an aggregated form of RSVP signalling between boundary nodes
in a provider's domain. This protocol would in effect, represent a
distributed bandwidth broker [BB] for the domain.
In order to validate conformance to the specific SLA's within a DS 6.3.3 Modification of Configuration Information Based on Real-Time
domain, the network operator should measure the performance of the Measurement
traffic belong to specific codepoints within its domain. The
measurement of traffic can be done in one of two modes:
Single Point Measurements: These measurements would monitor the A third mechanism for the configuration of interior nodes would be
traffic in the network at a single point in the network. Such a based on measurement of current traffic loads at key network nodes.
measurement can be done at the access-point of the network after Measurement based configuration is less necessary for quantitative
classification, and reported to the network management tools using provisioning, since quantitative traffic patterns are relatively
RMON MIBs [RMON]. A network operator can also station real-time flow predictable. However, it can significantly enhance the efficiency
monitors, and collect a more comprehensive record of the type of with which qualitative provisioning can be achieved. For example,
traffic flowing in the network [RTFlow]. network nodes may feed policy servers with current qualitative
traffic load measurements. In response, bandwidth brokers and policy
servers might recompute the relative weights for different service
queues in a WFQ node and push the new configuration information to
the routers. It is likely that measurement based configuration for
qualitative services would be used in conjunction with signalling
based configuration for quantitative services.
Dual Point Measurements: These measurements would monitor the Blake, et al Expires: April 1999 23
performance of the traffic between ingress access-points and the
egress access-point within the DS domain. The measurement of
performance could be done by means of network performance monitoring
protocols stationed at the two egress points. Network performance
monitoring protocols tend to be relatively heavyweight in their use
of network bandwidth, and these protocols should be used only when a
potential violation of the SLA is suspected between the two access-
points.
It would be desirable for a DS domain operator to have a continuous 7. Inter-Domain Considerations and End-to-End Services
low-overhead monitoring of the service-levels obtained by packets
within its domain using a passive monitoring scheme. When the
passive monitoring scheme suspects a potential problem, the more
heavyweight performance monitor can be activated. A SNMP manager may
be used as an intermediary to trigger this activation, with the
passive monitoring protocol generating an SNMP trap on suspicion of
SLA violation and the manager subsequently activating active
performance monitoring.
4. Inter-Domain Considerations and End-to-End Services So far we have considered differentiated service primarily in the
context of a single DS domain providing service to a single
customer. The ultimate customers of the differentiated service
network are hosts and end users residing on peripheral stub
networks. In general, these are interconnected by multiple domains
and require service which spans these domains. Therefore, it is
important to consider the interaction of services provided by a
concatenation of differentiated service domains and the peripheral
stub networks, rather than the service provided by a single domain.
In this section, we discus inter-domain issues related to TCAs,
provisioning and service and PHB mapping.
While the differentiated services architecture works very well to 7.1 TCAs
enable different service level agreements within a single ISP domain
or in a corporate Intranet, comprehensive service differentiation in
the Internet requires that there is support for service
differentiation in a uniform manner across several ISP's.
In general, communication across the Internet traverses several ISP Each service provider is expected to negotiate bilateral agreements
boundaries. When a browser accesses a web-server, the connection at each boundary node at which it connects to an adjacent provider's
traverses the client (browser) network; multiple ISP networks, and network. Such agreements are captured in the form of two TCAs, one
eventually reaches the server network. The response from the server governing the services provided to provider A's traffic by provider
traverses a (possibly asymmetric) path back to the client host. In B and the other governing the services provided to provider B's
these cases, SLAs are usually only specified between the client and traffic by provider A. Note that provider A serves as a provider to
its ISP, the server and its ISP, and between the neighboring pairs of provider B with respect to traffic flowing from provider B to
ISP's. Within this context, one must enable the definition of provider A. On the other hand provider A is a customer of provider B
services across the Internet using only bilateral SLAs between the with respect to traffic flowing from provider A to provider B. The
adjacent providers. two TCAs can be considered separately.
In order to appreciate the issues in service definition; let us In general, the TCAs negotiated by a provider at any boundary will
consider the "Preferred Service" web-service described in Section be dictated by TCAs negotiated at other boundaries. For example,
2.3.1. When the preferred service is provided, any client accessing assume that provider A offers leased line service to a customer with
the web-server must be provided Expedited Forwarding service for its an ingress point in provider A's domain, but an egress point in
requests as well as its response stream. As long as the client provider B's domain. In this case, it is necessary that the TCA
browser connects to the same ISP as the server, the preferred service between provider A and provider B be sufficient to accommodate the
is straightforward to provide. However, when the client browser is assurance made by provider A to its leased line service customer.
connecting to a different ISP, expedited processing for request Provider A may serve a number of customers with leased line services
packets is not enabled until they reach the domain of the ISP terminating at various boundary points in provider B's network.
immediately connected to the server. Thus, the TCA between provider A and provider B must represent the
aggregate requirements of the TCAs of all of provider A's customers.
Similarly, the expedited processing for response packets may not be 7.2 Inter-Domain Provisioning
honored once the response packets leave the domain of the ISP.
Some of the methods by which the service concept can be extended The inter-domain provisioning problem is not unlike the intra-
across multiple ISP's are outlined in the following sections. domain provisioning problem. The provider would generally begin by
evaluating the TCAs it has negotiated with its customers, and then
computing the impact of each of these TCAs on the TCAs it has
negotiated with its providers. For quantitative services, the
provider can compute the quantitative requirements of TCAs at each
of its provider's boundary nodes, as described above in the context
of the leased line service. For qualitative services, the process of
determining the requirements from its providers is fuzzier, since
4.1 Service Provisioning Across Boundaries Blake, et al Expires: April 1999 24
the volume of qualitative traffic expected to be carried through any
boundary is less deterministic.
There are two basic schemes which can be used to provide service In the simplest case, provisioning is based on static TCAs. In this
levels across ISP boundaries. The first scheme consists of case, provisioning is an iterative process in which providers
negotiating an aggregated bandwidth classification to one neighbor, negotiate TCAs with each of their customers, then apply the
and the second scheme consists of negotiating a microflow or traffic appropriate internal provisioning techniques to meet these
stream classification to a neighboring ISP. requirements. In the process of internal provisioning, a provider
might determine that a particular TCA cannot be met due to internal
resource constraints. The provider would then either have to add
internal resources or renegotiate one or more customer TCAs.
Although the process may be somewhat iterative, it is relatively
static in that changes in boundary TCAs and internal provisioning
occur relatively infrequently (on the order of hours, days or
months) and require human intervention.
An aggregated bandwidth negotiation is useful in preserving the Internal provisioning to meet the requirements of TCAs relies on
desired service levels of packets that are leaving an ISP DS domain. provisioning techniques described previously. As TCAs are
If an ISP A is sending packets into the DS domain of an ISP B, ISP A negotiated, the provider must check that the existing internal
would negotiate a SLA which would honor the DS field marking created provisioning is sufficient to meet the requirements of the new TCA,
by ISP A. As packets enter the domain of ISP A, they would be marked or must alter the internal provisioning. Recall that internal
with a specific codepoint. Before the packets leave the domain of provisioning might be pushed in a top down manner, from a domain's
ISP A and cross over to ISP B, they would be remarked so that DS logically centralized point of administration, or alternatively
field encoding matches the ones expected by ISP B as per the SLA might be distributed from the edges via signalling. In the former
between A and B. case, some form of a bandwidth broker would be directly consulted or
notified regarding changes in TCAs negotiated at the domain
boundaries. In the case that signalling is used, provisioning
messages (such as described previously) would be launched from the
boundary at which the new TCA is negotiated. These would claim a
share of existing provisioned resources, or would notify the
bandwidth broker in the case that additional resources are required.
For example, let us assume that the SLA between A and B A more sophisticated model would allow TCAs to be renegotiated
specifies that A would treat all packets marked for Expedited dynamically. In this case, the process would be automatic, and would
Forwarding with the same PHB as long as the aggregate inbound packet not require human intervention. Each domain would in effect,
rate is less than a certain limit. For the service category of represent a bandwidth broker, via one protocol or another. A
"special service" as described in Section 2.3.1, ISP A would mark all specific inter-domain protocol might be used to communicate between
response packets originating from the special web-servers for centralized bandwidth broker agents, or alternatively, an inter-
Expedited Forwarding. It would also negotiate the SLA with ISP B so domain variant of RSVP might be used. In the latter case, there is
as to obtain a rate for Expedited packets, which would be adequate to no direct interaction with a bandwidth broker per-se. However, the
meet the demand for its servers. Since ISP B would carry the packets collection of network nodes, policy servers and directory behave
at expedited level through its domain, the special service would be collectively as a bandwidth broker which communicates using RSVP. In
provided to all clients accessing either ISP A or B. A transitive either case, TCA renegotiations would be triggered by load
agreement between B and other service clients would lead to the measurements at boundary nodes. These could be in the form of
service being special to all clients in the Internet. changes in actual measured traffic volume, or alternatively, based
on explicit fine grain RSVP resource requests from hosts at the
periphery. Domains would approve renegotiations based both on
resource constraints as well as predetermined policy constraints.
For boundaries where the aggregated bandwidth is negotiated, one ISP Blake, et al Expires: April 1999 25
can simply act as the customer of another ISP. The marking and
policing scheme would work as for any other DS domain boundary
situation.
The aggregated bandwidth negotiation is not adequate for providing 7.3 Service, PHB and Codepoint Mapping
the preferred service described in Section 2.3.1.
The packets originating from a client who is connecting to ISP B and In order to provide end-to-end service to customers, it must be
trying to access a preferred web-server (as defined in ISP B's SLA possible to extend services across multiple domains. Several
with ISP A) will not receive the Expedited Forwarding treatment in complexities may arise at inter-domain boundaries, as follows:
the domain of ISP B since ISP B has no information that allows it to 1. The services provided by a certain domain may not be compatible
treat these packets specially. The client may have no SLA with ISP with the services provided by a neighbour domain.
B. One of the ways in which ISP A can manage to extend the preferred 2. The services provided by a certain domain may be compatible with
service agreement to clients in the domain of ISP B is to exchange a those provided by the neighbour domain, but the PHB used to
microflow- or traffic stream-level SLA with ISP B. In this obtain the service might be different.
negotiation, ISP A would inform ISP B about the set of destination 3. The PHB might be the same, but the codepoint used to request the
addresses (or prefixes) which need to be treated preferentially. In PHB might be different.
return ISP A would configure all of its access-points to mark the 4. The PHB and codepoint are the same but differences in
packets headed to the preferred service for Expedited Forwarding. provisioning and charging models results in different services.
An ISP may want to choose some other codepoint for marking packets Resolution of these complexities requires determination of the
belonging to the microflows/streams, which have a SLA with some other compatible services and negotiation of the PHB codepoints which will
ISP. There is also an associated scaling problem with too many be used to request the services. This process is greatly simplified
microflow/stream classifier entries floating across multiple ISP by the provision of a set of universal services using universally
boundaries. The ISP may want to export the microflows/streams recognized codepoints. The leased line service and EF codepoint is
classifier designations only across a certain number of likely to be one such example. Generally, extension of quantitative
administrative domains, and pay different amounts depending on how services across multiple domains will require more uniformity in the
far the microflow/stream classification negotiation would be carried. nature of the services provided. Qualitative services on the other
An ISP may also want to provide different levels of preferred service hand, may be extended end-to-end by a concatenation of services
to its web-server customers. A service where preferred service is which vary from domain to domain. For example, one domain may base a
extended to all the clients in the Internet may cost substantially qualitative service on a WFQ scheme with RED while another may use
more than a service where preferred service is only extended across priority queuing with RIO. Since the assurances provided by
one or two ISP domains. qualitative services tend to be looser, it is possible that a
meaningful service can be provided end-to-end by concatenating these
two service types.
4.1.1 Requirements for Service Level Agreements 7.4 Host-Domain Boundaries
Although the differentiated service architecture focuses on In certain cases, a host may be directly attached to a
differentiated treatment within a single domain, it is expected that differentiated service domain. This is likely both in the case of
different DS domains will be linked to each other through mutual campus networks that provide differentiated services within the
agreements and the DS region will expand in an incremental fashion. network or in the case of dial-up users connecting to a
How two different DS domains are interconnected is governed by the differentiated service provider. In these cases, the host can be
SLA between two-DS domains. The SLA will specify details as to how considered the customer of the differentiated service network.
each other's traffic is conditioned at the boundary of the two Legacy hosts are unlikely to mark their own packets for the
domains, and how packets are re-marked to be promoted or demoted appropriate DS-field and are also unlikely to shape or police their
within a PHB group. traffic. In the case of legacy hosts, the differentiated service
provider will have to provide these services on behalf of the
customer. In the case of campus networks, some network wide policy
would likely be used to configure these services in the DS boundary
devices. In the case of dial-up hosts, marking, shaping and
resources provided would likely be negotiated at the time the
customer signs up with the provider.
A SLA is normally a contract between two DS domains, which specifies Newer hosts may be capable both of marking and of traffic shaping.
details of treatment for traffic crossing the boundary of the two In this case, the overall per-host resource constraints are still
domains.
A SLA may contain the following: Blake, et al Expires: April 1999 26
likely to be somewhat static. However, the manner in which the host
shares these resources among its various traffic flows is determined
by the host. Of course, the provider will have to configure policers
to assure that the host does not seize more than its share of
resources in the differentiated service network.
Performance, Security, Availability between the domains: A bilateral 8. Inter-operability with RSVP/Integrated Services
agreement may dictate when the service is available and what type of
performance and security are expected when the service is running.
Rules for traffic conditioning: A SLA should specify how traffic from In this section, we discuss alternatives for inter-operability
one DS domain will be conditioned crossing the boundary, including between differentiated services and RSVP/Integrated services.
classification rules (MF classification or BA classification),
profiles for each PHB, actions for packets out-of-profile (marked
with a different PHB or shaped/discarded).
Mapping of PHBs between two domains: If the two DS domains use two 8.1 RSVP/Integrated Services Over Differentiated Services
distinct PHB groups, it may be necessary to establish some rules for
mapping one PHB to another.
Location of traffic conditioning: The packets can be conditioned by This scenario is discussed in detail in [E2EQOS]. It assumes a model
the egress node of one DS domain before the traffic crosses to the in which peripheral stub networks are RSVP and Intserv aware. These
next DS domain, or by the ingress node of the next domain. are interconnected by differentiated service networks. In this
model, the scalability of differentiated service networks helps to
extend the reach of RSVP/Integrated service (Intserv)networks.
Intervening differentiated service networks appear as a single RSVP
hop to the RSVP/Intserv networks. Hosts attached to the peripheral
RSVP/Intserv networks signal to each other for per-flow resource
requests across the differentiated service networks. Standard
RSVP/Intserv processing is applied within the RSVP/Intserv
peripheral networks. RSVP signalling messages are carried
transparently through the differentiated service networks. Devices
at the boundaries between the RSVP/Intserv networks and the
differentiated service networks process the RSVP messages and
provide admission control based on the availability of appropriate
resources within the differentiated service network.
4.1.2 Promotion and Demotion within a PHB group This model is predicated on the availability of services within the
differentiated service network which can extend the reach of intserv
type services. For example, the leased line service can extend the
intserv guaranteed service across a differentiated service network.
Multiple guaranteed service micro-flows which exist in peripheral
networks are aggregated into the EF behaviour aggregate at the edge
of the diffserv network. When an RSVP request for guaranteed service
arrives at the edge of a differentiated service network, RSVP style
admission control is applied based on the amount of resources
requested in the intserv flowspec and the availability of
differentiated services at the corresponding service level (per the
TCA). If admission control succeeds, the originating host (or its
agent) marks traffic on the signalled microflow, for the appropriate
differentiated service level.
When two DS domains use similar PHB groups, packets crossing the The RSVP/Intserv over differentiated service model is especially
boundary may be promoted or demoted to use a different PHB with the suitable for providing quantitative end-to-end services. The use of
same PHB group. Such promotion and demotion take place when there is differentiated services eliminates the scalability concerns of
a mis-match between the traffic rate specified in the SLA and the RSVP/Intserv networks. The use of RSVP signalling provides admission
actual traffic rate. For example, two ISP's both offer three traffic control to the differentiated service network, based on resource
classes: premium, standard and best effort. If the amount of premium availability and policy decisions. It also greatly simplifies the
traffic crossing the boundary is greater than the rate specified in
the SLA, some of the premium traffic may be demoted to standard
class. On the other hand, if there is less premium traffic than
specified in the SLA, standard traffic may be promoted to premium.
4.1.3 Mapping of PHBs at Boundaries Blake, et al Expires: April 1999 27
configuration of differentiated service classifiers, policers and
other traffic conditioning components.
When two DS domains are based on very different PHB groups, the SLA Variations on this theme would enable some number of nodes within
has to specify how one PHB in one DS domain is mapped to a PHB in the differentiated service networks to process the per-flow RSVP
another domain. If the PHBs have different values but similar messages passing through. These could be used to aid in dynamic
semantics, the mapping may be simple. However, in some case, the provisioning without necessarily requiring any per-flow state or
mapping can be very difficult. For example, one DS domain uses processing within the differentiated service network. In yet another
queueing priorities while the other is based on discard priorities. model, the transition of per-flow RSVP messages through the
However, in general, a "better" treatment in one PHB group should be differentiated service network might trigger aggregated RSVP
mapped to another "better" treatment. signalling between differentiated service domain edges, for the
purpose of renegotiating TCAs and adjusting provisioning dynamically
[GBH97, CLASSY].
4.2 Host Interactions 8.2 Parallel Operation
In the previous sections, we discuss the differentiated services Another alternative for the interoperation of differentiated service
primarily from the perspective of a service provider. In this and RSVP/Intserv networks is simple parallel operation. In this
section we look at how the users can make use of services offered by mode, each node within the differentiated service network may also
DS-capable networks. A host which is DS aware is just another DS be an RSVP capable node. Some strategy would have to be selected for
egress device; not a special case. determining which packets are handled using RSVP and which are
handled using differentiated services. For example, those that
classify to an RSVP installed filter might be handled using RSVP,
while those not classifying to specific RSVP filters would be
handled according to the DS-field using differentiated service
mechanisms. Such a model is likely to be deployed in smaller
networks (since the RSVP/Intserv component is less suited for large
networks). In particular, the stub networks cited in [E2EQOS] would
likely provide differentiated services for those qualitative
applications which do not signal, while providing RSVP/Intserv
services for those quantitative applications which do signal.
4.2.1 Traffic Conditioning for Directly Connected Users 9. Multicast Services
A user can gain access to a DS-capable network directly or through a Because the Differentiated Services Architecture deals only with
customer domain. Users who are directly connected to a DS-capable unidirectional flows, a 'multicast' service in a DS network will in
ISP (e.g., a dial-up user) should have a SLA with the ISP. Complex fact offer a point-to-multipoint unidirectional service. Each
traffic conditioning functions ideally should ideally be performed by source of traffic that wishes to send to the multicast group using
the hosts of the users rather than the access nodes, which may have this service needs a separate SLA which applies at the ingress point
to handle tens of thousands of users. where the traffic enters the network.
However, mechanisms have to be in place so that the ISPs are assured The network resources that must be provisioned for a multicast
that they can trust the self-policing by the users. service will be affected by the mechanisms used by the routers to
provide the service. Depending on the capabilities of the routers
and the multicast routing protocol employed, sub-optimal replication
of a packet may result in multiple copies travelling over the same
link.
Users may have to install DS control software from ISPs. When a user If receivers can be added dynamically to a multicast group whilst a
dials in, the authentication process also configures the DS control flow is in progress, the complexity of provisioning grows
module in the user's host according to the SLA between the user and considerably: The amount of network resources that will be consumed
the ISP. Random checking can also be done to ensure that the SLA is
maintained.
4.2.2 Service Allocation within Customer Domain Blake, et al Expires: April 1999 28
by multicast traffic originating from a particular upstream network
may be difficult to forecast in advance. Consequently, it may not
be possible to offer quantitative services where dynamic addition of
receivers adds to the paths through the network already used by the
flow.
When users are part of a customer domain, there is an issue of local 9.1 Codepoints and PHBs for Multicast Services
resource allocation. The customer domain should have a policy as to
what packets can be set to use a particular PHB group. Some form of
allocation, either static or dynamic, is needed in order to share the
profiles that the customer domain has obtained. The egress node of
the customer domain may perform traffic conditioning on the
aggregated traffic to ensure that the packets crossing the boundary
to the ISP conforms to the SLA between the customer domain and the
ISP.
A number of mechanisms for local allocation have been suggested. One To achieve resource isolation of multicast traffic from unicast
is bandwidth broker, which acts as a central allocation server for traffic, it may be necessary to use separate codepoints and separate
the customer domain and as a client to request additional resources instances of a PHB or different PHBs for the multicast and unicast
from the ISP [BB]. RSVP may also be adopted as a mechanism for services. If the multicast traffic is not adequately isolated,
requesting bandwidth with the customer domain and the resources to dynamic addition of new members of the multicast group can adversely
the ISP [RSVP]. affect existing unicast traffic.
4.2.3 End-to-End Services Because a multicast service traffic flow can exit from a domain to
several peer domains, care must be taken to use a codepoint and PHB
that is compatible with the peering SLAs at the egress points. This
may be a more stringent requirement than for a unicast service where
a flow need only be compatible with a single egress point SLA.
The differentiated services architecture is designed to be deployed 9.2 Provisioning Multicast Services
incrementally. ISPs are likely to offer differentiated services
first within their own networks, and conduct experiments. Over time,
ISPs will design business models for the new services and start to
extend the services by signing SLAs with other peering ISPs.
Since the differentiated services model is biased towards long term The scope of a multicast service would normally be either case 1
allocation rather than on-demand reservation, the guarantees for any (any egress point) or case 3 (a pre-defined set of egress points) of
differentiated services come through proper provisioning. Unless Sec. 4.4.
there is a clear traffic pattern, provisioning becomes much harder
when more DS domains are linked together. The level of provisioning
depends on the economic factors in the differentiated services and
varies from ISP to ISP. In general, when the packets leave the ISP
to which the customer has a SLA, the level of service may degrade.
For example, if the traffic aggregate for a particular PHB were over
the rate the next ISP would accept, some packets may be demoted to a
PHB with worse treatment. The more ISPs a packet traverses, the less
control the originating ISP has.
The extensibility of the differentiated services model allows many For a quantitative service the scope will, in general, need to be
different schemes to be tried out and developed further. case 3. The service can be provisioned in a similar way to
corresponding unicast services with the same volume of traffic along
each of the paths from ingress to egress, but taking into account
that all paths will be used simultaneously and allowing for multiple
copies of traffic if necessary. If the multicast routing protocol
used can generate different multicast trees depending on the order
in which members join the group, provisioning may not be possible.
Solving this problem may require pinning of the multicast tree
branch points; the solution of this problem is outside the scope of
this framework.
One possible approach is to establish an ISP-to-ISP pipe across For a qualitative service, provisioning is essentially the same as
multiple ISPs. So, the originating ISP and terminating ISP know the unicast case, but statistical multiplexing gains are likely to
exactly how traffic between them is provisioned. This is similar to be less because all paths may be used at once.
the VPN services that an ISP offers for connecting different sites of
an organization.
5. Interoperability with Integrated Services The traffic conditioning mechanisms for multicast services are not
significantly different from those for the unicast services but
multiple shapers may be required where traffic exits from several
interfaces on a single router or multiple replicas exit from one
interface.
In this section, we discuss three possible options for the Blake, et al Expires: April 1999 29
interoperability between the differentiated services and Integrated
Services [IntServ].
5.1 Parallel Operation 10. Security and Tunnelling Considerations
Both differentiated services and Integrated Services may operate in The security and tunnelling implications for the actual data
parallel over the same network infrastructure. It may be necessary transport of the services of the Differentiated Services
to set limits on the amount of bandwidth available for Integrated Architecture have been extensively discussed in {DSARCH] and
Services reservations so that the bandwidth provisioning for [DSHEAD] to which the reader is referred.
differentiated services traffic is protected. In general,
differentiated services provides an overall provisioning to
aggregates of traffic while Integrated Services can be used to make
reservation for long-lasting and high-bandwidth flows. This is
similar to the current telephone networks. One does not need to make
a prior reservation in order to make a phone call. The likelihood of
blocking inside the network is very small as capacity is guaranteed
through long-term provisioning. However, if one would like to make a
conference call or video call, an advanced reservation may be
necessary.
5.2 Int-serv Over Diff-serv Additional security considerations arise from the services overlaid
on the data transport:
1. The services are the subject of differential charging.
Accordingly, the service users have to be authenticated and
authorised, and the accounting data needed must be secured.
2. The mechanisms used to create and distribute the policy and
resource allocations must be secured.
3. Statistical data needed to audit service delivery must be
secured.
Alternatively, differentiated services and Integrated Services may be The mechanisms used to provide this security are outside the scope
tightly coupled by means of a hierarchical bandwidth allocation of this framework, but are under consideration by the AAA working
scheme. Differentiated services may be used to allocate bandwidth in group.
bulk quantity to individual customer networks. Each customer network
may use Integrated Services mechanisms to allocate the bandwidth
among individual hosts and application flows. This model works
particularly well for VPNs when a corporation can purchase "virtual
pipes" across the Internet and then run Integrated Services over the
over-laid virtual network. Examples of this model include [E2EQOS].
5.3 Aggregated Int-serv State The use of tunnels in general and IPsec tunnels in particular
impedes the work of MF Classifiers by concealing the fields used by
L4 and higher layer classifiers. Thus traffic conditioners within
the area where IPsec encryption is used will need to rely only on IP
header fields, including the DS field (BA Classifiers will work
normally). If more sophisticated Mf classification is required it
will have to take place before the tunnel ingress and the
application of IPsec encryption. If IPsec encryption is used end-
to-end, then Differentiated Services may require host marking.
In this approach, Integrated Services flow signaling state (e.g., If a tunnel carries multiple flows with different traffic types,
RSVP) is aggregated between border nodes within a cooperating network they may be marked with different DS codepoints so that they are
region. Hop-by-hop signaling messages within this region convey the subjected to appropriate behaviors in the network interior. This
aggregated state of a number of Integrated Services flows. Packets may be considered to be a security breach as it allows traffic
within an aggregated Integrated Services class are marked by a patterns to become visible. If just one codepoint is used for all
special DS codepoint to convey aggregated classification state (the traffic it should be selected carefully to be appropriate for all
service class, and possibly an in- or out-of-profile indicator). the traffic in the tunnel.
Examples of this model include [GBH97, CLASSY].
6. Acknowledgements 11. Acknowledgements
The authors would like to acknowledge the helpful comments and The authors would like to acknowledge the helpful comments and
suggestions of the following individuals: Kathleen Nichols, Brian suggestions of the following individuals: Kathleen Nichols, Brian
Carpenter, David Black, Konstantinos Dovrolis, Shivkumar Kalyana, Carpenter, David Black, Konstantinos Dovrolis, Shivkumar Kalyana,
Wu-chang Feng, Marty Borden, and Ronald Bonica. Wu-chang Feng, Marty Borden, and Ronald Bonica.
7. References Blake, et al Expires: April 1999 30
12. References
[BB] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit [BB] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet", Differentiated Services Architecture for the Internet", Internet
Internet Draft <draft-nichols-diff-svc-arch-00.txt>, Draft
November 1997.
[CLARK] D. Clark and J. Wroclawski, "An Approach to Service [CLARK] D. Clark and J. Wroclawski, "An Approach to Service
Allocation in the Internet", Internet Draft Allocation in the Internet", Internet Draft
<draft-clark-diff-svc-alloc-00.txt>, July 1997.
[CLASSY] S. Berson and S. Vincent, "Aggregation of Internet [CLASSY] S. Berson and S. Vincent, "Aggregation of Internet
Integrated Services State", Internet Draft
<draft-berson-classy-approach-01.ps>, November 1997.
[COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and Integrated Services State", Internet Draft, November 1997.
A. Sastry, "COPS (Common Open Policy Service) Protocol",
<draft-ietf-rap-cops-01.txt>, March 1998.
[DSARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and [COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A.
W. Weiss, "An Architecture for Differentiated Services", Sastry, "COPS (Common Open Policy Service) Protocol", March 1998.
Internet Draft <draft-ietf-diffserv-arch-00.txt>, May
1998.
[DSHEAD] K. Nichols and S. Blake, "Definition of the [DSARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and W.
Differentiated Services Field (DS Byte) in the IPv4 and Weiss, "An Architecture for Differentiated Services", Internet
IPv6 Headers", Internet Draft Draft, May 1998.
<draft-ietf-diffserv-header-00.txt>, May 1998.
[DSPREC] F. Baker, S. Brim, T. Li, F. Kastenholz, S. Jagannath, [DSHEAD] K. Nichols and S. Blake, "Definition of the Differentiated
and J. Renwick, "IP Precedence in Differentiated Services Field (DS Byte) in the IPv4 and IPv6 Headers", Internet
Services Using the Assured Service", Internet Draft Draft, May 1998.
<draft-ietf-diffserv-precedence-00.txt>, April 1998.
[AF] J.Heinanen, _Assured Forwarding PHB Group_Internet Draft,
August 1998.
[EF] V.Jacobson, _Expedited Fowarding Per Hop Behavior_, Internet
Draft, August 1998.
[Ellesson] E. Ellesson and S. Blake, "A Proposal for the Format and [Ellesson] E. Ellesson and S. Blake, "A Proposal for the Format and
Semantics of the TOS Byte and Traffic Class Byte in IPv4 Semantics of the TOS Byte and Traffic Class Byte in IPv4 and IPv6",
and IPv6", Internet Draft <draft-ellesson-tos-00.txt>, Internet Draft, November 1997.
November 1997.
[E2EQOS] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, and L. Zhang, [E2EQOS] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, and L. Zhang,
"A Framework for End-to-End QoS Combining RSVP/Intserv "A Framework for End-to-End QoS Combining RSVP/Intserv and
and Differentiated Services", Internet Draft Differentiated Services", Internet Draft, March 1998.
<draft-bernet-intdiff-00.txt>, March 1998.
[GBH97] R. Guerin, S. Blake, and S. Herzog, "Aggregating RSVP- [GBH97] R. Guerin, S. Blake, and S. Herzog, "Aggregating RSVP- based
based QoS Requests", Internet Draft QoS Requests", Internet Draft, November 1997.
<draft-guerin-aggreg-rsvp-00.txt>, November 1997.
[IntServ] R. Braden, D. Clark, and S. Shenker, "Integrated Services [IntServ] R. Braden, D. Clark, and S. Shenker, "Integrated Services
in the Internet Architecture: An Overview", Internet RFC in the Internet Architecture: An Overview", Internet RFC 1633, July
1633, July 1994. 1994.
[RMON] S. Waldbusser, "Remote Network Monitoring Management
Information Base Version 2 using SMIv2", Internet RFC
2021, January 1997.
[RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) [RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) --
-- Version 1 Functional Specification", Internet RFC Version 1 Functional Specification", Internet RFC 2205, September
2205, September 1997. 1997.
[RTFlow] N. Brownlee, C. Mills, and G. Ruth, "Traffic Flow Blake, et al Expires: April 1999 31
Measurement: Architecture", Internet Draft
<draft-ietf-rtfm-architecture-02.txt>, Dec. 1997.
Authors' Addresses 11. Author's Addresses
Yoram Bernet Bernet, Yoram
Microsoft Microsoft
One Microsoft Way, One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone: +1-425-936-9568 Phone: +1 (425) 936-9568
E-mail: yoramb@microsoft.com Email: yoramb@microsoft.com
James Binder Binder, James
3Com Corp. 3Com Corp.
5400 Bayfront Plaza 5400 Bayfront Plaza
Santa Clara, CA 95052 Santa Clara, CA 95052
Phone: +1-408-326-6051 Phone: +1 (408) 326-6051
E-mail: james_binder@3com.com Email: james_binder@3com.com
Steven Blake Blake, Steven
IBM Corporation Torrent Networking Technologies
800 Park Offices Drive 3000 Aerial Center, Suite 140
Research Triangle Park, NC 27709 Morrisville, NC 27560
Phone: +1-919-254-2030 Phone: +1-919-468-8466 x232
E-mail: slblake@raleigh.ibm.com Fax: +1-919-468-0174
Email: slblake@torrentnet.com
Mark A. Carlson Carlson, Mark
Redcape Software, Inc. RedCape Software Inc.
2990 Center Green Court South 2990 Center Green Court South
Boulder, CO 80301 Boulder, CO 80301
Phone: +1-303-448-0048 x115 Phone: +1 (303) 448-0048 x115
E-mail: mac@redcape.com Email: mac@redcape.com
Elwyn Davies
Davies, Elwyn
Nortel UK Nortel UK
London Road London Road
Harlow, Essex CM17 9NA, UK Harlow, Essex CM17 9NA, UA
Phone: +44-1279-405498 Phone: +44-1279-405498
E-mail: elwynd@nortel.co.uk Email: elwynd@nortel.co.uk
Borje Ohlman Ohlman, Borje
Ericsson Radio Ericsson Radio
Dialoggatan 1 (Kungens Kurva) Dialoggatan 1 (Kungens Kurva)
S-126 25 Stockholm S-126 25 Stockholm
Sweden Sweden
Phone: +46-8-719 3187 Phone: +46-8-719 3187
E-mail: Borje.Ohlman@ericsson.com Email: Borje.Ohlman@ericsson.com
Dinesh C. Verma Blake, et al Expires: April 1999 32
IBM TJ Watson Research Center Srinivasan Keshav
PO Box 218 4107B Uspon Hall
Cornell University
Ithaca, NY 14853
Phone: +607-255-5395
Email: skeshav@cs.cornell.edu
Dinesh Verma IBM T. J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598 Yorktown Heights, NY 10598
E-mail: dverma@watson.ibm.com Phone: +1 (914) 784-7466
Email: dverma@watson.ibm.com
Zheng Wang Zheng Wang
Bell Labs Lucent Tech Bell Labs Lucent Tech
101 Crawfords Corner Road 101 Crawfords Corner Road
Holmdel, NJ 07733 Holmdel, NJ 07733
E-mail: zhwang@bell-labs.com Email: zhwang@bell-labs.com
Walter Weiss Walter Weiss
Lucent Technologies Lucent Technologies
300 Baker Avenue, Suite 100, 300 Baker Avenue, Suite 100 Concord, MA 01742-2168
Concord, MA 01742-2168 Email: wweiss@lucent.com
E-mail: wweiss@lucent.com
Blake, et al Expires: April 1999 33
 End of changes. 244 change blocks. 
1059 lines changed or deleted 1392 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/