draft-ietf-diffserv-framework-01.txt   draft-ietf-diffserv-framework-02.txt 
Differentiated Services S.Blake, et al
Document: draft-ietf-diffserv-framework-01.txt Differentiated Services Y.Bernet, et al
Document: draft-ietf-diffserv-framework-02.txt
Yoram Bernet, Microsoft Yoram Bernet, Microsoft
James Binder, 3-Com James Binder, 3-Com
Steven Blake, Torrent Networking Technologies Steven Blake, Torrent Networking Technologies
Mark Carlson, Redcape Software Mark Carlson, Redcape Software
Brian E. Carpenter, IBM
Srinivasan Keshav, Cornell University Srinivasan Keshav, Cornell University
Elwyn Davies, Nortel UK Elwyn Davies, Nortel Networks
Borje Ohlman, Ericsson Borje Ohlman, Ericsson
Dinesh Verma, IBM Dinesh Verma, IBM
Zheng Wang, Bell Labs Lucent Technologies Zheng Wang, Bell Labs Lucent Technologies
Walter Weiss, Lucent Technologies Walter Weiss, Lucent Technologies
A Framework for Differentiated Services A Framework for Differentiated Services
<draft-ietf-diffserv-framework-01.txt> <draft-ietf-diffserv-framework-02.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its Areas, all provisions of Section 10 of RFC2026. Internet Drafts are
and its Working Groups. Note that other groups may also distribute working documents of the Internet Engineering Task Force (IETF),
working documents as Internet Drafts. 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 Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet other documents at any time. It is not appropriate to use
Drafts as reference material or to cite them other than as a Internet Drafts as reference material or to cite them other than
"working draft" or "work in progress". as a "working draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the The list of current Internet-Drafts can be accessed at
1id-abstracts.txt listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au. The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
A revised version of this draft document will be submitted to the A revised version of this draft document will be submitted to the
RFC editor as a Proposed Standard for the Internet Community. RFC editor as an Informational Standard for the Internet
Discussion and suggestions for improvement are requested. This Community. Discussion and suggestions for improvement are
document will expire before April, 1999. Distribution of this draft requested. This document will expire before September, 1999.
is unlimited. Distribution of this draft is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Bernet, et al 1
CONTENTS
1. Abstract......................................................4
2. Structure of this Draft.......................................4
3. Differentiated Services - Motivation and Definition...........4
4. Services......................................................5
4.1 Customer/Provider Boundaries..............................5
4.2 SLSs and TCSs.............................................6
4.3 Service Taxonomy: Quantitative through Qualitative and
alternatives..........................................7
4.4 The Scope of a Service....................................8
4.4.1 Services where the Scope is Tied to the Receiver....8
4.5 Dynamic vs. Static SLSs...................................9
4.6 Provisioning Traffic Conditioners in Boundary Devices to
Provide Services.....................................10
4.6.1 Minimal Functionality at Provider's Ingress........11
4.6.2 Functionality at Provider's Ingress for Double-ended
SLSs.............................................12
4.6.3 Added Value Functionality at Provider's Ingress....12
4.6.4 Functionality at Customer's Egress.................13
4.6.5 Functionality at Provider's Egress.................13
4.7 Internal Provisioning....................................14
4.8 End-to-End Service Construction..........................14
5. Service Examples.............................................14
5.1 Better than Best-Effort (BBE) Service....................14
5.1.1 Service Implementation.............................15
5.2 Leased Line Emulation Service............................16
5.2.1 Service Implementation.............................16
5.3 Quantitative Assured Media Playback Service..............17
5.3.1 Service Implementation.............................17
5.4 Superposition of Quantitative and Qualitative Services in
the Same Network.....................................18
6. Provisioning and Configuration...............................18
6.1 Boundary vs. Interior Provisioning and Configuration.....19
6.1.1 Boundary Provisioning..............................19
6.1.2 Interior Provisioning..............................20
6.1.2.1 Quantitative Provisioning of the Interior..21
6.1.2.2 Qualitative Provisioning of the Interior...22
6.2. Static vs. Dynamic Provisioning.........................23
6.3 Distributing Configuration Information...................24
6.3.1 Top Down Distribution of Configuration Information.24
6.3.2 Distribution of Configuration Information via
Signaling........................................25
6.3.3 Modification of Configuration Information Based on
Real-Time Measurement............................26
7. Inter-Domain Considerations and End-to-End Services..........26
7.1 TCSs.....................................................27
7.2 Inter-Domain Provisioning................................27
7.3 Service, PHB and Codepoint Mapping.......................28
7.4 Host-Domain Boundaries...................................29
8. Deployment Scenarios.........................................29
9. Inter-operability with RSVP/Integrated Services..............31
Bernet, et al Expires: September 1999 2
9.1 RSVP/Integrated Services Over Differentiated Services....31
9.2 Parallel Operation.......................................32
10. Multicast Services..........................................32
10.1 Codepoints and PHBs for Multicast Services.............33
10.2 Provisioning Multicast Services........................33
11. Security and Tunneling Considerations.......................34
12. Acknowledgements............................................35
13. References..................................................35
14. Author's Addresses..........................................36
Changes from previous version
- Terminology made consistent with architecture _ particularly
boundary (node) used in place of edge (node) where appropriate.
- Table of contents added.
- Traffic Conditioning Agreement (TCA) replaced by Traffic
Conditioning Specification (TCS) throughout to avoid
connotations of contractual agreement.
- Most instances of Service Level Agreement (SLA) replaced by
Service Level Specification (SLS) where it is clear that we are
talking about the technical specification of the services. The
SLS is defined as the technical specification part of the
contractual SLA. Emphasized that this document discusses the
technical aspects of the SLA whilst acknowledging that it fits
in a wider contractual framework which is outside the scope of
technical standards.
- Deployment scenarios section added.
- Whole document coordinated with [DiffEdge] and [E2EQoS].
- Service scope added as a component of TCS.
- Connections made to work of MPLS and IP Performance Metrics
WGs.
- Pointed out that dealing with the interactions of multiple end-
to-end services is an open question and is unlikely to have a
computable answer in common cases.
- Multicast section improved:
- Added preamble pointing out that DS should be good for
multicast except that provisioning is difficult
- Application level unicast is dealt with by multiple
instances of point-to-point services
- Pointed out that provisioning multiple source mpt-to-mpt is
not a straight generalisation of pt-to-mpt
- Emphasised that TC for a quantitative service in an IPsec
tunnel will be difficult to realize because the relevant packet
fields are hidden.
- Updated references to reflect current drafts. Added a few new
references including [ROTZY] for bandwidth broker.
Bernet, et al Expires: September 1999 3
1. Abstract 1. Abstract
This document provides a general description of issues related to This document provides a general description of issues related to
the definition, configuration and management of services enabled by the definition, configuration and management of services enabled
the differentiated services architecture [DSARCH]. This document by the differentiated services architecture [DSARCH]. This
should be read along with its companion documents, the document should be read along with its companion documents, the
differentiated services architecture [DSARCH] and the definition of differentiated services architecture [DSARCH] and the definition
the DS field [DSHEAD]. A glossary of specialist terms used may be of the DS field [DSHEAD]. A glossary of specialist terms used may
found in [DSARCH]. be found in [DSARCH].
Blake, et al Expires: April 1999 1
2. Structure of this Draft 2. Structure of this Draft
Section 3 defines Differentiated Services and explains the Section 3 defines Differentiated Services and explains the
motivation behind its deployment. Section 4 defines the concept of a motivation behind its deployment. Section 4 defines the concept of
service and the components that comprise a service. Section 5 a service and the components that comprise a service. Section 5
discusses several service examples. Section 6 examines intra-domain discusses several service examples. Section 6 examines intra-
provisioning, configuration and management issues. Section 7 domain provisioning, configuration and management issues. Section
examines inter-domain provisioning, configuration and management. 7 examines inter-domain provisioning, configuration and
Section 8 addresses interoperability with Integrated Services and management. Section 8 describes some possible deployment
RSVP. Section 9 discusses the interaction of differentiated services scenarios. Section 9 addresses interoperability with Integrated
with multicast and tunnelling. Section 10 addresses security Services and RSVP. Section 10 discusses the interaction of
concerns. differentiated services with multicast and tunneling. Section 11
addresses security concerns.
3. Differentiated Services - Motivation and Definition 3. Differentiated Services - Motivation and Definition
Traditionally, network service providers (both enterprise and Traditionally, network service providers (both enterprise and
traditional ISPs) provide all customers with the same level of traditional ISPs) provide all customers with the same level of
performance (best-effort service). Most service differentiation has performance (best-effort service). Most service differentiation
been in the pricing structure (individual vs. business rates) or the has been in the pricing structure (individual vs. business rates)
connectivity type (dial-up access vs. leased line, etc.). However, or the connectivity type (dial-up access vs. leased line, etc.).
in recent years, increased usage of the Internet has resulted in However, in recent years, increased usage of the Internet has
scarcity of network capacity, compromising performance of resulted in scarcity of network capacity, compromising performance
traditional, mission critical applications. At the same time, new of traditional, mission critical applications. At the same time,
applications have emerged which demand much improved service new applications have emerged which demand much improved service
quality. As a result, service providers are finding it necessary to quality. As a result, service providers are finding it necessary
offer their customers alternative levels of service. As well as to offer their customers alternative levels of service. As well as
meeting new customer expectations, this allows service providers to meeting new customer expectations, this allows service providers
improve their revenues through premium pricing and competitive to improve their revenues through premium pricing and competitive
differentiation of service offerings, which in turn can fund the differentiation of service offerings, which in turn can fund the
necessary expansion of the network. necessary expansion of the network.
The Differentiated Services architecture offers a framework within The Differentiated Services architecture offers a framework within
which service providers can offer each customer a range of network which service providers can offer each customer a range of network
services which are differentiated on the basis of performance in services which are differentiated on the basis of performance in
addition to pricing tiers used in the past. Customers request a addition to pricing tiers used in the past. Customers request a
specific performance level on a packet by packet basis, by marking specific performance level on a packet by packet basis, by marking
the DS field of each packet with a specific value (see [DSHEAD] for the DS field of each packet with a specific value (see [DSHEAD]
more details). This value specifies the Per-hop Behavior (PHB) to be for more details). This value specifies the Per-hop Behavior (PHB)
allotted to the packet within the provider's network. Typically, the to be allotted to the packet within the provider's network.
customer and provider negotiate a profile (policing profile) Typically, the customer and provider negotiate a profile (policing
describing the rate at which traffic can be submitted at each profile) describing the rate at which traffic can be submitted at
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.
Blake, et al Expires: April 1999 2 Bernet, et al Expires: September 1999 4
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
boundary 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.
4. Services 4. Services
[DSARCH] defines a Service as "the overall treatment of a defined [DSARCH] defines a Service as "the overall treatment of a defined
subset of a customer's traffic within a DS-domain, or end-to-end". subset of a customer's traffic within a DS-domain, or end-to-end".
Although PHBs are at the heart of the differentiated services Although PHBs are at the heart of the differentiated services
architecture, it is the service obtained as a result of marking architecture, it is the service obtained as a result of marking
traffic for a specific PHB, which is of value to the customer. PHBs traffic for a specific PHB, which is of value to the customer.
are merely building blocks for services. Service providers combine PHBs are merely building blocks for services. Service providers
PHB implementations with traffic conditioners, provisioning combine PHB implementations with traffic conditioners,
strategies and billing models which enable them to offer services to provisioning strategies and billing models which enable them to
their customers. Providers and customers negotiate agreements with offer services to their customers. Providers and customers
respect to the services to be provided at each customer/provider negotiate agreements with respect to the services to be provided
boundary. These take the form of Service Level Agreements (SLAs). at each customer/provider boundary. These are commonly referred to
as Service Level Agreements (SLAs). Many of the aspects of SLAs
(such as payment terms) are beyond the scope of technical
standards and are therefore not considered in this document; the
subset of the SLA which provides the technical specification of
the service will be referred to as the Service Level Specification
(SLS).
Bear in mind when considering the services that are offered in a DS- Bear in mind when considering the services that are offered in a
domain that: DS-domain that:
* DS services are all for unidirectional traffic only * DS services are all for unidirectional traffic only
* DS services are for traffic aggregates, not individual micro-flows * DS services are for traffic aggregates, not individual micro-
flows
4.1 Customer/Provider Boundaries 4.1 Customer/Provider Boundaries
Present day network traffic generally traverses a concatenation of Present day network traffic generally traverses a concatenation of
networks which may include hosts, home or office networks, campus or networks which may include hosts, home or office networks, campus
corporate networks and several large transit networks. Home and or corporate networks and several large transit networks. Home and
office networks are typically customers of campus or corporate office networks are typically customers of campus or corporate
networks, which are in turn customers of large transit networks. networks, which are in turn customers of large transit networks.
While one would expect the initial deployment of differentiated While one would expect the initial deployment of differentiated
services to be within large transit networks, its deployment may services to be within large transit networks, its deployment may
also be extended to the smaller campus and corporate networks and in also be extended to the smaller campus and corporate networks and
special cases, all the way to individual hosts. As such, there may in special cases, all the way to individual hosts. As such, there
be numerous customer/provider boundaries at which the concept of a may be numerous customer/provider boundaries at which the concept
'service' applies. of a 'service' applies.
4.2 SLAs and TCAs Bernet, et al Expires: September 1999 5
4.2 SLSs and TCSs
At each differentiated service customer/provider boundary, the At each differentiated service customer/provider boundary, the
service provided is defined in the form of an SLA. The SLA is a technical aspects of the service provided is defined in the form
contract which specifies the overall features and performance which of an SLS which specifies the overall features and performance
can be expected by the customer. Because DS services are which can be expected by the customer. Because DS services are
unidirectional the two directions of flow across the boundary will unidirectional the two directions of flow across the boundary will
need to be considered separately. An important subset of the SLA is need to be considered separately. An important subset of the SLS
the traffic conditioning agreement, or TCA. The TCA specifies is the traffic conditioning specification, or TCS. The TCS
detailed service parameters for each service level. Such parameters specifies detailed service parameters for each service level. Such
include: parameters include:
1. Detailed service performance parameters such as expected 1. Detailed service performance parameters such as expected
throughput, drop probability, latency. throughput, drop probability, latency.
2. Traffic profiles which must be adhered to for the requested 2. Constraints on the ingress and egress points at which the
service is provided, indicating the `scope' of the service.
Service scopes are discussed further in Sec. 4.4.
3. Traffic profiles which must be adhered to for the requested
service to be provided, such as token bucket parameters. service to be provided, such as token bucket parameters.
4. Disposition of traffic submitted in excess of the specified
Blake, et al Expires: April 1999 3
3. Disposition of traffic submitted in excess of the specified
profile. profile.
4. Marking services provided. 5. Marking services provided.
5. Shaping services provided. 6. Shaping services provided.
In addition to the details in the TCA, the SLA may specify more The TCS, the logical components needed to implement it and the
configuration needed for those components are discussed in more
detail in [DiffEdge].
In addition to the details in the TCS, the SLS may specify more
general service characteristics such as: general service characteristics such as:
1. Availability/Reliability, which may include behavior in the event 1. Availability/Reliability, which may include behavior in the
of failures resulting in rerouting of traffic event of failures resulting in rerouting of traffic
2. Encryption services 2. Encryption services
3. Routing constraints 3. Routing constraints
4. Authentication mechanisms 4. Authentication mechanisms
5. Mechanisms for monitoring and auditing the service 5. Mechanisms for monitoring and auditing the service
6. Responsibilities such as location of the equipment and 6. Responsibilities such as location of the equipment and
functionality, action if the contract is broken, support functionality, action if the contract is broken, support
capabilities capabilities
7. Pricing and billing mechanisms 7. Pricing and billing mechanisms
These additional characteristics are important, and in the case of These additional characteristics are important, and in the case of
pricing and billing, fundamental to the service offering but they do pricing and billing, fundamental to the service offering but they
not affect the service itself and are not considered further here. do not affect the service itself and are not considered further
here.
4.3 Service Taxonomy: Quantitative through Qualitative and alternatives Metrics which can be used to validate the delivery of the service
specified by a TCS have been studied by the IP Performance Metrics
Working Group of the IETF and are being published as Informational
RFCs.
Bernet, et al Expires: September 1999 6
4.3 Service Taxonomy: Quantitative through Qualitative and
alternatives
The Differentiated Services architecture can support a broad The Differentiated Services architecture can support a broad
spectrum of different kinds of service. Categorizing these services spectrum of different kinds of service. Categorizing these
provides some constraints on the corresponding SLAs that can be services provides some constraints on the corresponding SLSs that
offered for the service. can be offered for the service.
Some services can be clearly categorized as qualitative or Some services can be clearly categorized as qualitative or
quantitative depending on the type of performance parameters quantitative depending on the type of performance parameters
offered. Examples of qualitative services are as follows: offered. Examples of qualitative services are as follows:
1. Traffic offered at service level A will be delivered with low 1. Traffic offered at service level A will be delivered with low
latency. latency.
2. Traffic offered at service level B will be delivered with low 2. Traffic offered at service level B will be delivered with low
loss. loss.
The assurances offered in examples 1 and 2 are relative and can only The assurances offered in examples 1 and 2 are relative and can
be verified by comparison. only be verified by comparison.
Examples of quantitative services are as follows: Examples of quantitative services are as follows:
3. 90% of in profile traffic delivered at service level C will 3. 90% of in profile traffic delivered at service level C will
experience no more than 50 msec latency. experience no more than 50 msec latency.
4. 95% of in profile traffic delivered at service level D will be 4. 95% of in profile traffic delivered at service level D will be
delivered. delivered.
Examples 3 and 4 both provide concrete guarantees that could be Examples 3 and 4 both provide concrete guarantees that could be
verified by suitable measurements on the example service verified by suitable measurements on the example service
irrespective of any other services offered in parallel with it. irrespective of any other services offered in parallel with it.
Blake, et al Expires: April 1999 4
There are also services which are not readily categorized as There are also services which are not readily categorized as
qualitative or quantitative as in the following examples: qualitative or quantitative as in the following examples:
5. Traffic offered at service level E will be allotted twice the 5. Traffic offered at service level E will be allotted twice the
bandwidth of traffic delivered at service level F. bandwidth of traffic delivered at service level F.
6. Traffic with drop precedence AF12 has a lower probability of 6. Traffic with drop precedence AF12 has a higher probability of
delivery than traffic with drop precedence AF13. delivery than traffic with drop precedence AF13 [AF].
In example 5, the provider is quantifying the relative benefit of In example 5, the provider is quantifying the relative benefit of
submitting traffic at service level E vs. service level F, but the submitting traffic at service level E vs. service level F, but the
customer cannot expect any particular quantifiable throughput. This customer cannot expect any particular quantifiable throughput.
can be described as a `Relative Quantification Service'. This can be described as a `Relative Quantification Service'.
In general, when a provider offers a quantitative service, it will In general, when a provider offers a quantitative service, it will
be necessary to specify quantitative policing profiles. In many be necessary to specify quantitative policing profiles. In many
cases, quantitative policing profiles will be specified even for cases, quantitative policing profiles will be specified even for
services that do not offer quantitative performance. services that do not offer quantitative performance.
Determining how to monitor and audit the delivery of a qualitative Determining how to monitor and audit the delivery of a qualitative
or relative quantification service in such a way as to convince the or relative quantification service in such a way as to convince
user that he has received fair measure requires careful attention. the user that he has received fair measure requires careful
It will be up to the customer to determine if the advantage offered attention. It will be up to the customer to determine if the
is sufficient to make the service worthwhile. The SLA must clearly advantage offered is sufficient to make the service worthwhile.
avoid making quantitative commitments for these services.
Bernet, et al Expires: September 1999 7
The SLS must clearly avoid making quantitative commitments for
these services.
4.4 The Scope of a Service 4.4 The Scope of a Service
The scope of a service refers to the topological extent over which The scope of a service refers to the topological extent over which
the service is offered. For example, assume that a provider offers a the service is offered. For example, assume that a provider offers
service to a customer which connects to their network at ingress a service to a customer which connects to their network at ingress
point A. The service may apply to: point A. The service may apply to:
1. all traffic from ingress point A to any egress point 1. all traffic from ingress point A to any egress point
2. all traffic between ingress point A and egress point B 2. all traffic between ingress point A and egress point B
3. all traffic from ingress point A to a set of egress points 3. all traffic from ingress point A to a set of egress points
Egress points may be in the same domain as the ingress point or may Egress points may be in the same DS Domain as the ingress point or
be in other domains which are either directly or indirectly may be in other domains which are either directly or indirectly
connected to the ingress domain. If the egress point is in another connected to the ingress domain. If the egress point is in another
domain, it will be necessary for the ingress provider to negotiate domain, it will be necessary for the ingress provider to negotiate
SLAs with the relevant peer domains, which will recursively SLAs with the relevant peer domains, which will recursively
negotiate with their peers to ensure that the service offered at negotiate with their peers to ensure that the service offered at
ingress point A can indeed be extended to the egress points ingress point A can indeed be extended to the egress points
specified. The scope of a service is part of the SLA governing specified. The scope of a service is part of the TCS governing
ingress point A. ingress point A.
Blake, et al Expires: April 1999 5
In general, providers will be able to offer quantitative services In general, providers will be able to offer quantitative services
most efficiently when a specific set of egress points is specified. most efficiently when a specific set of egress points is
Quantitative services which span multiple domains also require specified. Quantitative services which span multiple domains also
tighter coupling between the SLA offered to the customer at ingress require tighter coupling between the SLA offered to the customer
point A and the SLAs negotiated with intermediate domains. at ingress point A and the SLAs negotiated with intermediate
Qualitative services can more readily be offered to arbitrary sets domains. Qualitative services can more readily be offered to
of egress points and require looser coupling between the SLA at arbitrary sets of egress points and require looser coupling
ingress point A and SLAs at intermediate domain boundaries. between the SLA at ingress point A and SLAs at intermediate domain
boundaries.
4.4.1 Services Governing Received Traffic 4.4.1 Services where the Scope is Tied to the Receiver
A special case of service scope is a service that governs all A special case of service scope is a service that governs all
traffic between any ingress point and egress point B. The SLA that traffic between any ingress point and egress point B. The SLS that
defines this service would be at egress point B and would defines this service would be at egress point B and would
effectively allow the customer to control the mix of traffic effectively allow the customer to control the mix of traffic
received from the provider. While such a service is theoretically received from the provider. While such a service is theoretically
possible, it conflicts with the more traditional use of diffserv possible, it appears to be a mismatch with the more usual
which governs the quality with which traffic is sent, rather than specification of Differentiated Services which governs the
received. quality with which traffic is sent, rather than received.
A number of concerns would have to be addressed by such a service, A number of concerns would have to be addressed by such a service,
including: including:
Traffic going to point B from an ingress point A under the terms - Traffic going to point B from an ingress point A under the
of the SLA of this service may also be governed by an SLA for terms of the SLS of this service may also be governed by an SLS
traffic submitted at point A. The SLAs may conflict and it will for traffic submitted at point A. The SLSs may conflict and it
not, in general, be possible to resolve all such conflicts across will not, in general, be possible to resolve all such conflicts
all the ingress points. 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 Bernet, et al Expires: September 1999 8
complex than for other service scopes: Static profiles are likely - Establishing a traffic profile for this service at every
to be either inefficient (e.g. dividing the egress profile into possible ingress which prevents overload of the receiver can be
fixed proportions) or risky (e.g. allowing every ingress to send more complex than for other service scopes: Static profiles are
the whole profile) whilst dynamic profiles require processes and likely to be either inefficient (e.g. dividing the egress
communication mechanisms to coordinate the settings. 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. For example, the sources may offer 1Mb/s when
the receiver can only accept 9.6Kb/s.
- Without effective ingress profiles for the service, denial of - Without effective ingress profiles for the service, denial of
service attacks will be a serious problem. service attacks will be a serious problem.
Some of the characteristics of receiver oriented services can be Some of the characteristics of receiver oriented services can be
provided by local policies and the SLA for the domain to which provided by local policies and the SLS for the domain to which
traffic is sent via the egress point as described in Sec. 4.6.4. traffic is sent via the egress point as described in Sec. 4.6.4.
Blake, et al Expires: April 1999 6 4.5 Dynamic vs. Static SLSs
4.5 Dynamic vs. Static SLAs
SLAs may be static or dynamic. Static SLAs are the norm at the SLSs may be static or dynamic. Static SLSs are the norm at the
present time. These are instantiated as a result of negotiation present time. These are instantiated as a result of negotiation
between human agents representing provider and customer. A static between human agents representing provider and customer. A static
SLA is first instantiated at the agreed upon service start date and SLS is first instantiated at the agreed upon service start date
may periodically be renegotiated (on the order of days or weeks or and may periodically be renegotiated (on the order of days or
months). The SLA may specify that service levels change at certain weeks or months). The SLS may specify that service levels change
times of day or certain days of the week, but the agreement itself at certain times of day or certain days of the week, but the
remains static. agreement itself remains static.
Dynamic SLAs, on the other hand, may change frequently. Such changes Dynamic SLSs, on the other hand, may change frequently. Such
may result for example, from variations in offered traffic load changes may result for example, from variations in offered traffic
relative to preset thresholds or from changes in pricing offered by load relative to preset thresholds or from changes in pricing
the provider as the traffic load fluctuates. Dynamic SLAs change offered by the provider as the traffic load fluctuates. Dynamic
without human intervention and thus require an automated agent and SLSs change without human intervention and thus require an
protocol, in effect, a bandwidth broker to represent the automated agent and protocol, for example, a bandwidth broker to
differentiated service provider's domain (such as suggested in represent the differentiated service provider's domain (such as
[BB]). suggested in [ROTZY]).
Dynamic SLAs also present challenging problems to both end users and Dynamic SLSs also present challenging problems to both end users
network providers: and network providers:
- Network providers have to balance frequently changing loads on - Network providers have to balance frequently changing loads on
different routes within the provider network. This requires the different routes within the provider network. This requires the
provider to adopt dynamic, automated resource provisioning provider to adopt dynamic, automated resource provisioning
mechanisms rather than relying on static provisioning. mechanisms rather than relying on static provisioning.
- Customer equipment will have to adapt to dynamic SLAs in order to - Customer equipment will have to adapt to dynamic SLSs in order
make the most out of the changing SLA. to make the most out of the changing SLS.
- End user applications may have to adapt their behavior during a - End user applications may have to adapt their behavior during a
session to make the most of (or even, cope with) dynamic SLAs. session to make the most of (or even, cope with) dynamic SLSs.
It is worth reiterating that the SLAs in Differentiated Services It is worth reiterating that the SLSs in Differentiated Services
apply to aggregates of traffic and not individual flows. For apply to aggregates of traffic and not individual flows. For
scalability, it is undesirable to envisage modifying an SLA every scalability, it is undesirable to envisage modifying an SLS every
time a new micro-flow is added or removed from an aggregate. time a new micro-flow is added or removed from an aggregate.
Bernet, et al Expires: September 1999 9
4.6 Provisioning Traffic Conditioners in Boundary Devices to Provide 4.6 Provisioning Traffic Conditioners in Boundary Devices to Provide
Services Services
Once an SLA has been negotiated, the service provider (and Once an SLS has been negotiated, the service provider (and
optionally the customer) will configure traffic conditioning optionally the customer) will configure traffic conditioning
components at the boundary between the two networks. The service components at the boundary between the two networks. The service
provider does so with the goal of protecting the provider's network provider does so with the goal of protecting the provider's
such that the resources granted to the customer meet but do not network such that the resources granted to the customer meet but
exceed the terms of the TCA. The customer does so with the goal of do not exceed the terms of the TCS. The customer does so with the
making the best use of the service purchased from the provider. In goal of making the best use of the service purchased from the
this section, we will briefly describe configuration of traffic provider. In this section, we will briefly describe configuration
conditioners in boundary devices. of traffic conditioners in boundary devices. Traffic conditioners
and their configuration are described in greater detail in
[DiffEdge].
Blake, et al Expires: April 1999 7
Note that the provider's self interests require only that the Note that the provider's self interests require only that the
provider identify provider identify
- for which service level specific traffic is submitted, - for which service level specific traffic is submitted,
- by which customer it is submitted, and - by which customer it is submitted, and
- for traffic with double-ended SLAs (i.e. SLA scope is type 2 or 3 - for traffic with double-ended SLSs (i.e. SLS scope is type 2 or
of Sec. 4.4) only, the destination address to which the traffic 3 of Sec. 4.4) only, the destination address to which the
is directed. traffic is directed.
Customer traffic may be authenticated either by the physical Customer traffic may be authenticated either by the physical
connection on which it arrives or by some sophisticated connection on which it arrives or by some sophisticated
cryptographic means which is beyond the scope of this draft. The cryptographic means which is beyond the scope of this draft. The
provider need not be concerned with the customer's individual micro- provider need not be concerned with the customer's individual
flows in delivering basic Differentiated Services (see Sec. 4.6.3 micro-flows in delivering basic Differentiated Services (see Sec.
for additional services). 4.6.3 for additional services).
[DSARCH] identifies four traffic conditioning components: [DSARCH] identifies four traffic conditioning components:
1. Meters 1. Meters
2. Markers 2. Markers
3. Shapers 3. Shapers
4. Droppers 4. Droppers
The combination and interaction of the traffic conditioning The combination and interaction of the traffic conditioning
components is selected on a packet-by-packet basis by the DS components is selected on a packet-by-packet basis by the DS
codepoint. The configuration parameters for the components at each codepoint. The configuration parameters for the components at
codepoint are determined by the policies and profiles applied, so each codepoint are determined by the policies and profiles
that the conditioner polices the traffic in the BA specified by the applied, so that the conditioner polices the traffic in the BA
codepoint. Meters measure submitted traffic for conformance to a specified by the codepoint. Meters measure submitted traffic for
profile, providing control input for the other components which conformance to a profile, providing control input for the other
implement the policing: components which implement the policing:
- Shapers police by delaying submitted traffic such that it does - Shapers police by delaying submitted traffic such that it does
not exceed the traffic rate specified in a profile. not exceed the traffic rate specified in a profile.
- Droppers police by dropping traffic that is submitted at a rate - Droppers police by dropping traffic that is submitted at a rate
exceeding that specified in a profile. exceeding that specified in a profile.
Bernet, et al Expires: September 1999 10
- Markers police by re-marking the traffic with a different - Markers police by re-marking the traffic with a different
codepoint either codepoint either
- to demote out-of-profile traffic to a different PHB, - to demote out-of-profile traffic to a different PHB,
- as a result of an SLA which specifies codepoint mutation, or - as a result of an SLS which specifies codepoint mutation, or
- to ensure that only valid codepoints are used within the - to ensure that only valid codepoints are used within the
domain. domain.
In addition to these four components, traffic classifiers are In addition to these four components, traffic classifiers are
required in order to separate submitted traffic into different required in order to separate submitted traffic into different
classes. Classifiers may separate traffic based only on the DS-field classes. Classifiers may separate traffic based only on the DS-
of submitted packets (BA classifiers) or may do so based on multiple field of submitted packets (BA classifiers) or may do so based on
fields within the packet header and even the packet payload (MF multiple fields within the packet header and even the packet
classifiers). MF classifiers may be used at boundaries to provide payload (MF classifiers). MF classifiers may be used at
certain per-micro-flow services to customers. Examples of such boundaries to provide certain per-micro-flow services to
services include per-flow marking or shaping. Typically, traffic customers. Examples of such services include per-flow marking or
will arrive at the boundary of a DS domain pre-marked and shaping. Typically, traffic will arrive at the boundary of a DS
pre-shaped. However, at interfaces with some non-DS customer domain pre-marked and pre-shaped. However, at interfaces with some
non-DS customer networks, it is possible that traffic will require
Blake, et al Expires: April 1999 8 marking and shaping.
networks, it is possible that traffic will require marking and
shaping.
Even if a customer has pre-marked and pre-shaped, the service Even if a customer has pre-marked and pre-shaped, the service
provider will wish to police the traffic at the ingress boundary to provider will wish to police the traffic at the ingress boundary
meet the domain's self-interests. This may result in traffic being to meet the domain's self-interests. This may result in traffic
re-marked or dropped. being re-marked or dropped.
Traffic conditioning components (in particular, meters) will also be Traffic conditioning components (in particular, meters) will also
the primary source of billing information for a differentiated be the primary source of accounting information for a
Services network. Differentiated Services network.
4.6.1 Minimal Functionality at Provider's Ingress 4.6.1 Minimal Functionality at Provider's Ingress
At the very least, the service provider must limit traffic carried At the very least, the service provider must limit traffic carried
on behalf of the customer to the constraints specified in the TCA. A on behalf of the customer to the constraints specified in the TCS.
simplified TCA can be represented in the form of a table wherein A simplified TCS can be represented in the form of a table wherein
each row has the format: each row has the format:
DS-Mark : Profile : Disposition of non-conforming traffic DS-Mark : Profile : Scope : Disposition of non-conforming traffic
This row indicates that the provider commits to carry traffic marked This row indicates that the provider commits to carry traffic
with 'DS-Mark' at the corresponding service level, provided that it marked with 'DS-Mark' at the corresponding service level, provided
conforms to the 'Profile'. Traffic that is submitted with 'DS-Mark' that it conforms to the 'Profile'. Traffic that is submitted with
and which does not conform to the 'Profile', is subjected to 'DS-Mark' and which does not conform to the 'Profile', is
'Disposition of non-conforming traffic'. This is generally a subjected to 'Disposition of non-conforming traffic'. This is
policing action such as re-marking to a lower service level, generally a policing action such as re-marking to a lower service
delaying in a shaper, or dropping. Alternatively, it may be carried level, delaying in a shaper, or dropping. Alternatively, it may be
at the requested service level, but subjected to a surcharge. The carried at the requested service level, but subjected to a
SLA for this type of service would normally be expected to be of surcharge. The scope for this type of service would normally be
type 1 of Sec. 4.4.1, where the traffic destination can take it expected to be of type 1 of Sec. 4.4.1, where the traffic
through any egress point of the domain. destination can take it through any egress point of the domain.
To provide this minimal functionality, the provider must configure a To provide this minimal functionality, the provider must configure
BA classifier to separate traffic into the different service level a BA classifier to separate traffic into the different service
requested, based on DS-Mark. Following the BA classifier, each class
must be metered for conformance to the corresponding profile.
Following the profiler, either a dropper, shaper or re-marker is
likely to be employed. The Better than Best Efforts service
described in Sec. 5.1 is an example of a service for which this
functionality is sufficient.
4.6.2 Functionality at Provider's Ingress for Double-ended SLAs Bernet, et al Expires: September 1999 11
level requested, based on DS-Mark. Following the BA classifier,
each class must be metered for conformance to the corresponding
profile. Following the profiler, either a dropper, shaper or re-
marker is likely to be employed. The Better than Best Efforts
service described in Sec. 5.1 is an example of a service for which
this functionality is sufficient.
If quantitative or other services needing double-ended SLAs (types 2 4.6.2 Functionality at Provider's Ingress for Double-ended SLSs
and 3 of Sec. 4.4.1) are implemented in a DS Domain, these services
specify the possible egress port(s) for traffic conforming to the
SLA. The traffic conditioner needs to consider the destination
address of the packet as additional input to the policing process,
so that traffic is not accepted for egress ports for which an SLA
does not exist. The Virtual Leased Line service described in
Blake, et al Expires: April 1999 9 If quantitative or other services needing double-ended SLSs (types
Sec. 5.2 is an example of a service that would require this 2 and 3 of Sec. 4.4.1) are implemented in a DS Domain, these
functionality. services specify the possible egress port(s) for traffic
conforming to the SLS. The traffic conditioner needs to consider
the destination address of the packet as additional input to the
policing process, so that traffic is not accepted for egress ports
for which an SLS does not exist. The Virtual Leased Line service
described in Sec. 5.2 is an example of a service that would
require this functionality.
A QoS VPN can be constructed by provisioning multiple instances o f A QoS VPN can be constructed by provisioning multiple instances o f
services of type 2, building in effect, a mesh of point to point QoS services of type 2, building in effect, a mesh of point to point
links. QoS links.
Services of type 3 are most likely to be used for multicast Services of type 3 are most likely to be used for multicast
applications (see Sec. 9). applications (see Sec. 10).
4.6.3 Added Value Functionality at Provider's Ingress 4.6.3 Added Value Functionality at Provider's Ingress
The functionality described in Secs. 4.6.1 and 4.6.2 serves only to The functionality described in Secs. 4.6.1 and 4.6.2 serves only
protect the provider's network resources in line with the terms of to protect the provider's network resources in line with the terms
the TCA. It provides no assistance to the customer. The burden of of the TCS. It provides no assistance to the customer. The burden
marking packets and shaping traffic falls entirely on the customer. of marking packets and shaping traffic falls entirely on the
In some cases, the SLA may call for the provider to provide customer. In some cases, the SLS may call for the provider to
additional services to the customer. Such services may include: provide additional services to the customer. Such services may
1. Marking traffic from specific micro-flows to a specific behaviour include:
aggregate (marking the DS-field). 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- 2. Policing traffic from specific micro-flows or sets of micro-
flows, either in the form of dropping or shaping. flows, either in the form of dropping or shaping.
In order to provide such services, the provider must generally In order to provide such services, the provider must generally
employ an MF classifier in addition to the BA classifier. The need employ an MF classifier in addition to the BA classifier. The need
for an MF classifier arises only when the customer requires the for an MF classifier arises only when the customer requires the
provider to provide some form of traffic separation or provider to provide some form of traffic separation or
authentication on behalf of the customer. The provider may charge authentication on behalf of the customer. The provider may charge
dearly for these services depending on the degree of granularity and dearly for these services depending on the degree of granularity
the amount of work required. For example, shaping thousands of and the amount of work required. For example, shaping thousands of
customer micro-flows might consume considerable resources in the customer micro-flows might consume considerable resources in the
provider's edge device. On the other hand marking based on source provider's boundary device. On the other hand marking based on
subnet addresses would consume considerably fewer resources. source subnet addresses would consume considerably fewer
resources.
Bernet, et al Expires: September 1999 12
4.6.4 Functionality at Customer's Egress 4.6.4 Functionality at Customer's Egress
Strictly speaking, the customer need not apply any specific traffic Strictly speaking, the customer need not apply any specific
conditioning. In this case, the customer relies on the provider to traffic conditioning. In this case, the customer relies on the
mark as per negotiated MF classification criteria. In many cases it provider to mark as per negotiated MF classification criteria. In
is preferable for the customer to mark. Customer marking may be many cases it is preferable for the customer to mark. Customer
necessary when customer packets are encrypted (as in the case of marking may be necessary when customer packets are encrypted (as
end-to-end IPSec). Customer marking enables the customer to direct in the case of end-to-end IPSec). Customer marking enables the
specific traffic from specific users or applications to specific customer to direct specific traffic from specific users or
service classes. This may be difficult or impossible for a provider applications to specific service classes. This may be difficult or
to do on behalf of a customer when, for example, applications use impossible for a provider to do on behalf of a customer when, for
volatile ports and users are assigned IP addresses based on DHCP. example, applications use volatile ports and users are assigned
IP addresses based on DHCP.
In addition to marking, it is in the customer's best interest to at In addition to marking, it is in the customer's best interest to
least shape per service level, at the customer network's egress at least shape per service level, at the customer network's egress
point. Otherwise, customer traffic may be policed by the service point. Otherwise, customer traffic may be policed by the service
Blake, et al Expires: April 1999 10
provider with undesirable consequences (e.g. dropped packets). provider with undesirable consequences (e.g. dropped packets).
Shaping per service level does not however, provide for micro-flow Shaping per service level does not however, provide for micro-flow
traffic separation. As a consequence, a renegade traffic source may traffic separation. As a consequence, a renegade traffic source
cause the profile to be exceeded for a specific service level, may cause the profile to be exceeded for a specific service level,
negatively impacting all customer flows which are marked for that negatively impacting all customer flows which are marked for that
service level. Therefore, it is often in the customer's interest to service level. Therefore, it is often in the customer's interest
shape or at least to police, with micro-flow granularity. to meter and shape or at least to police, with micro-flow
granularity.
4.6.5 Functionality at Provider's Egress 4.6.5 Functionality at Provider's Egress
At the egress from a provider's domain there may be an SLA in place At the egress from a provider's domain there may be an SLA in
with a peer DS domain, which might be either another provider or an place with a peer DS domain, which might be either another
end user domain. As in Sec. 4.6.4, it is in the provider's best provider or an end user domain. As in Sec. 4.6.4, it is in the
interests to shape the traffic leaving the domain. provider's best interests to shape the traffic leaving the domain.
Depending on the SLA, the egress may be required to remark and/or Depending on the SLA, the egress may be required to remark and/or
police or shape the traffic. Note that the forwarding treatment police or shape the traffic. Note that the forwarding treatment
applied to the packet in the egress node of the domain would be that applied to the packet in the egress node of the domain would be
selected by the codepoint before it was remarked (otherwise, the that selected by the codepoint before it was remarked (otherwise,
egress node has to support multiple codepoint to PHB mappings). the egress node has to support multiple codepoint to PHB
mappings).
If the peer domain is a non-DS domain the egress may be required
to remark all packets to conform to one of the previous standards
for the use of the TOS byte [RFC791,RFC1349].
The provider may also wish to offer additional services to a The provider may also wish to offer additional services to a
customer by policing egress traffic with micro-flow granularity if customer by policing egress traffic with micro-flow granularity if
the customer might expect to receive excessive traffic in a single the customer might expect to receive excessive traffic in a single
BA and wishes to apply greater control than could be achieved by BA and wishes to apply greater control than could be achieved by
normal policing of the aggregate. This would be specified via an normal policing of the aggregate. This would be specified via an
SLA in the usual way. SLS in the usual way.
Bernet, et al Expires: September 1999 13
4.7 Internal Provisioning 4.7 Internal Provisioning
The provider must provision internal nodes in the provider network The provider must provision internal nodes in the provider network
to meet the assurances offered by SLAs negotiated at the boundaries to meet the assurances offered by SLSs negotiated at the
of the network. To do so, the provider may use similar traffic boundaries of the network. To do so, the provider may use similar
conditioning mechanisms to those used at the network boundaries. traffic conditioning mechanisms to those used at the network
However, providers are unlikely to apply MF classification within boundaries. However, providers are unlikely to apply MF
the interior of the network. The provider may police periodically classification within the interior of the network. The provider
within the network, by reshaping, remarking or discarding traffic. may police periodically within the network, by reshaping,
remarking or discarding traffic.
Service providers are experienced in provisioning large networks Service providers are experienced in provisioning large networks
which offer uniform service, assisted by predictive tools, traffic which offer uniform service. They are assisted in this by
modeling tools and real time measurements. Current techniques will predictive tools, traffic modeling tools and real time
likely be applied to differentiated services networks, although, the measurements. Current techniques will likely be applied to
complexity of provisioning will increase significantly. In a differentiated services networks, although, the complexity of
differentiated service network, the provider must ensure that provisioning will increase significantly. In a differentiated
resources granted to traffic of one service level does not service network, the provider must ensure that resources granted
inappropriately compromise assurances regarding traffic at other to traffic of one service level does not inappropriately
service levels (for example, in example service 6, traffic in AF13 compromise assurances regarding traffic at other service levels
can legitimately compromise traffic in AF11 if an increase in AF13 (for example, in example service 6, traffic in AF12 can
traffic causes more AF11 traffic to be dropped). As mentioned legitimately compromise traffic in AF13 if an increase in AF12
previously, internal provisioning in the case of dynamic SLAs will traffic causes more AF13 traffic to be dropped). As mentioned
previously, internal provisioning in the case of dynamic SLSs will
likely require dynamic resource allocation protocols. likely require dynamic resource allocation protocols.
Blake, et al Expires: April 1999 11
4.8 End-to-End Service Construction 4.8 End-to-End Service Construction
The Differentiated Services architecture proposes that an end-to-end The Differentiated Services architecture proposes that an end-to-
service can be constructed by the concatenation of domain services end service can be constructed by the concatenation of domain
and their associated customer-provider SLAs for each of the domains services and their associated customer-provider SLAs for each of
which the service traffic has to cross. the domains which the service traffic has to cross.
Clearly, not all PHBs and services can be meaningfully concatenated, Clearly, not all PHBs and services can be meaningfully
and the definition of suitable services and their associated PHBs concatenated, and the definition of suitable services and their
will be a major focus of future Differentiated Services development. associated PHBs will be a major focus of future Differentiated
This is discussed at greater length in Sect. 7. Services development. This is discussed at greater length in Sec.
7.
5. Service Examples 5. Service Examples
In this section, we describe service examples and show how they can In this section, we describe service examples and show how they
be supported by specific PHBs. We base these examples on PHBs which can be supported by specific PHBs. We base these examples on PHBs
are defined in [AF]and [EF]. These examples are intended to be which are defined in [AF]and [EF]. These examples are intended to
illustrative of the wide range of services that can be employed be illustrative of the wide range of services that can be employed
using the differentiated services model, and are not intended to be using the differentiated services model, and are not intended to
an exhaustive list. be an exhaustive list. Further examples can be found in the
Appendix of [AF] (`Olympic' service _ related gold, silver and
bronze service levels, a proportional bandwidth service and an
alternative for a low latency service) and [2BIT].
5.1 Better than Best-Effort (BBE) Service 5.1 Better than Best-Effort (BBE) Service
Bernet, et al Expires: September 1999 14
This is a qualitative service which promises to carry specific web This is a qualitative service which promises to carry specific web
server traffic at a higher priority than competing best-effort server traffic at a higher priority than competing best-effort
traffic. Such a service offers relatively loose (not quantifiable) traffic. Such a service offers relatively loose (not quantifiable)
performance from a given ingress point to any egress point. Such a performance from a given ingress point to any egress point. Such a
service is suitable for example for businesses offering access to service is suitable for example for businesses offering access to
web based content. The BBE service enables the web content provider web based content. The BBE service enables the web content
to provide content at a generally higher rate than other content provider to provide content at a generally higher rate than other
providers are able to, in so reducing the latency experienced by content providers are able to, in so reducing the latency
consumers of the web site. experienced by consumers of the web site.
5.1.1 Service Implementation 5.1.1 Service Implementation
In this example, we assume that there is an SLA which defines the In this example, we assume that there is an SLS which defines the
service at the customer's ingress point. This is the point at which service at the customer's ingress point. This is the point at
the customer injects web server responses into the differentiated which the customer injects web server responses into the
services network. The information in the TCA can be represented in differentiated services network. The information in the TCS can be
the following form [AF]: represented in the following form [AF]:
AF13 Mark : 1 Mbps : Any egress point : Excess traffic handled by AF11 Mark : 1 Mbps : Any egress point : Excess traffic handled by
marking with AF11 mark. marking with AF13 mark : .
Packets submitted for the BBE service should be marked with the DS- Packets submitted for the BBE service should be marked with the
field codepoint corresponding to the AF13 PHB. The provider is DS- field codepoint corresponding to the AF11 PHB. The provider is
promising to carry up to 1 Mbps of traffic from the ingress point to promising to carry up to 1 Mbps of traffic from the ingress point
any egress point at a higher priority than best-effort traffic. A to any egress point at a higher priority than best-effort traffic.
lesser class of service corresponding to the AF11 PHB will be A lesser class of service corresponding to the AF13 PHB will be
applied to traffic submitted for the AF13 PHB, in excess of 1 Mbps. applied to traffic submitted for the AF11 PHB, in excess of 1
Mbps.
Blake, et al Expires: April 1999 12 The provider will provision a policer at the ingress point.
The provider will provision a policer at the ingress point. Traffic Traffic submitted up to the 1 Mbps limit will be directed to the
submitted up to the 1 Mbps limit will be directed to the AF13 PHB. AF11 PHB. Traffic submitted in excess of 1 Mbps will be remarked
Traffic submitted in excess of 1 Mbps will be remarked for the AF11 for the AF13 PHB. Note that the scheme will preserve ordering of
PHB. Note that the scheme will preserve ordering of packets since packets since AF11 and AF13 use a single queue..
AF13 and AF11 use a single queue..
In order to provide this service, the provider will have to In order to provide this service, the provider will have to
implement the AF13 and AF11 PHBs in core network equipment. The AF13 implement the AF11 and AF13 PHBs in core network equipment. The
and AF11 PHBs can be implemented for example, using a single RIO AF11 and AF13 PHBs can be implemented for example, using a single
queue. The provider will also have to provision equipment within the RIO queue. The provider will also have to provision equipment
core of the provider's network to provide the AF13/AF11 service. By within the core of the provider's network to provide the AF11/AF13
provisioning the appropriate RED parameters, for example, the service. By provisioning the appropriate RED parameters, for
provider is able to control the priority of AF13 traffic relative to example, the provider is able to control the priority of AF11
AF11 traffic at each network node. Since there are no quantitative traffic relative to AF13 traffic at each network node. Since there
guarantees, the provider can be quite liberal in its provisioning are no quantitative guarantees, the provider can be quite liberal
strategy and may realize significant statistical multiplexing gains. in its provisioning strategy and may realize significant
Also, the absence of quantitative guarantees makes it easy to statistical multiplexing gains. Also, the absence of quantitative
provide this type of service across multiple DS provider domains. guarantees makes it easy to provide this type of service across
This is because is not necessary to negotiate, then provision and multiple DS provider domains. This is because is not necessary to
enforce quantitative guarantees at multiple boundaries. negotiate, then provision and enforce quantitative guarantees at
multiple boundaries.
Bernet, et al Expires: September 1999 15
5.2 Leased Line Emulation Service 5.2 Leased Line Emulation Service
This is a quantitative service which emulates traditional leased This is a quantitative service which emulates traditional leased
line service. As such, it promises to deliver customer traffic with line service. As such, it promises to deliver customer traffic
very low latency and very low drop probability, up to a negotiated with very low latency and very low drop probability, up to a
rate. Above this rate, traffic is dropped. Such a service is negotiated rate. Above this rate, traffic is dropped. Such a
typically offered between two specific points. It is suitable for service is typically offered between two specific points. It is
many customer applications. However, due to the high quality suitable for many customer applications. However, due to the high
guarantees, it is likely to be priced higher than alternate services quality guarantees, it is likely to be priced higher than
and therefore, to be used only for applications which really require alternate services and therefore, to be used only for applications
this type of service. An example of such an application is IP which really require this type of service. An example of such an
telephony. A corporate customer might purchase leased line emulation application is IP telephony. A corporate customer might purchase
service between each pair of a number of corporate network sites. leased line emulation service between each pair of a number of
corporate network sites.
5.2.1 Service Implementation 5.2.1 Service Implementation
In this example, we consider a customer with three geographically In this example, we consider a customer with three geographically
dispersed networks interconnected via a single provider network. dispersed networks interconnected via a single provider network.
Customer attachment points are represented as A, B and C. At each Customer attachment points are represented as A, B and C. At each
attachment point, an SLA describes the leased line service to be attachment point, an SLS describes the leased line service to be
provided to the other two points. The table below represents the provided to the other two points. The table below represents the
information required in the TCA at attachment point A: information required in the TCS at attachment point A:
EF-Mark : 100 Kbps : Egress point B : Discard non-conforming traffic
EF-Mark : 50 Kbps : Egress point C : Discard non-conforming traffic EF-Mark : 100 Kbps : Egress point B : Discard non-conforming
traffic
Packets submitted for leased line service should be marked with the EF-Mark : 50 Kbps : Egress point C : Discard non-conforming
DS-field codepoint corresponding to the EF PHB [EF]. From the traffic
ingress point A, to the egress point B, the provider is promising to
Blake, et al Expires: April 1999 13 Packets submitted for leased line service should be marked with
carry up to 100 Kbps of traffic. Excess traffic will be discarded. the DS-field codepoint corresponding to the EF PHB [EF]. From the
From ingress point A, to egress point C, the provider promises to ingress point A, to the egress point B, the provider is promising
carry 50 Kbps of traffic. Of course, there is some tolerance to carry up to 100 Kbps of traffic. Excess traffic will be
required in policing the traffic and thus, there may be a discarded. From ingress point A, to egress point C, the provider
specification of tolerated jitter or burst size. However, for a promises to carry 50 Kbps of traffic. Of course, there is some
leased line service, the primary traffic profile parameter would be tolerance required in policing the traffic and thus, there may be
the sustained traffic rate. a specification of tolerated jitter or burst size. However, for a
leased line service, the primary traffic profile parameter would
be the sustained traffic rate.
The provider will provision a policer at ingress point A to limit The provider will provision a policer at ingress point A to limit
traffic destined for egress point B, to 100 Kbps. Similarly, a traffic destined for egress point B, to 100 Kbps. Similarly, a
policer will be configured to limit traffic destined for egress policer will be configured to limit traffic destined for egress
point C, to 50 Kbps. These policers will require classification point C, to 50 Kbps. These policers will require classification
based on the DS-Mark and the destination address in each packet. based on the DS-Mark and the destination address in each packet.
In order to provide this service, the provider will have to In order to provide this service, the provider will have to
implement the EF PHB in core network equipment. The EF PHB can be implement the EF PHB in core network equipment. The EF PHB can be
implemented using strict priority queuing or alternatively, by implemented using strict priority queuing or alternatively, by
assigning EF marked packets to a heavily weighted queue in a WFQ assigning EF marked packets to a heavily weighted queue in a WFQ
scheme. The provider will have to provision equipment within the scheme. The provider will have to provision equipment within the
Bernet, et al Expires: September 1999 16
core of the provider's network. For example, routers carrying core of the provider's network. For example, routers carrying
traffic between point A and points B and/or C will have to be traffic between point A and points B and/or C will have to be
provisioned considering the resources committed by the TCA at point provisioned considering the resources committed by the TCS at
A. This means that a router which is both in the path from A to B point A. This means that a router which is both in the path from A
and from A to C, will have to be considered to have committed 150 to B and from A to C, will have to be considered to have committed
Kbps of bandwidth as a result of the TCA in place at A. A router 150 Kbps of bandwidth as a result of the TCS in place at A. A
that is only in the path from A to B, will have to be considered to router that is only in the path from A to B, will have to be
have committed 100 Kbps as a result of this TCA, and so on. Of considered to have committed 100 Kbps as a result of this TCS, and
course, routing is subject to change and so, failover paths may have so on. Of course, routing is subject to change and so, failover
to be provisioned as well. These may be provisioned to provide some paths may have to be provisioned as well. These may be provisioned
fraction of the service in the case of failover or alternatively, to provide some fraction of the service in the case of failover or
the SLA at point A might reflect appropriate service availability alternatively, the SLS at point A might reflect appropriate
parameters. To enhance the assurances offered by EF service, service availability parameters. To enhance the assurances offered
providers may employ route pinning mechanisms or QoS routing by EF service, providers may employ route pinning mechanisms or
mechanisms. QoS routing mechanisms.
5.3 Quantitative Assured Media Playback Service 5.3 Quantitative Assured Media Playback Service
This service offers looser assurances than the leased line service This service offers looser assurances than the leased line service
described above, but is still considered a quantitative service. In described above, but is still considered a quantitative service.
particular, it promises to deliver traffic with a high degree of In particular, it promises to deliver traffic with a high degree
reliability and with variable but bounded latency, up to a of reliability and with variable but bounded latency, up to a
negotiated rate. Above this rate, traffic is subject to significant negotiated rate. Above this rate, traffic is subject to
delay or drop. Such a service is typically offered between a significant delay or drop. Such a service is typically offered
specific set of points. It is suitable for many customer between a specific set of points. It is suitable for many customer
applications. It would likely be priced lower than a leased line applications. It would likely be priced lower than a leased line
service, due to the latency variability. However, due to the latency service, due to the latency variability. However, due to the
bound and high degree of delivery, it is likely to be priced higher latency bound and high degree of delivery, it is likely to be
than alternate services. This service is particularly suitable for priced higher than alternate services. This service is
video or audio playback, in which considerable bandwidth is required particularly suitable for video or audio playback, in which
on a continual basis, but the non-interactive nature of the traffic considerable bandwidth is required on a continual basis, but the
makes it somewhat delay tolerant. non-interactive nature of the traffic makes it somewhat delay
tolerant.
Blake, et al Expires: April 1999 14
5.3.1 Service Implementation 5.3.1 Service Implementation
In this example, we again consider a customer with three In this example, we again consider a customer with three
geographically dispersed networks interconnected via a single geographically dispersed networks interconnected via a single
provider network. The table below represents the information provider network. The table below represents the information
required in the TCA at attachment point A: required in the TCS at attachment point A:
AF13-Mark : 100 Kbps sustained, 100 Kb bursts tolerated at up to 200 AF11-Mark : 100 Kbps sustained, 100 Kb bursts tolerated at up to
Kbps : Egress point B : Excess burst traffic over sustained rate 200 Kbps : Egress point B : Excess burst traffic over sustained
marked with AF12-mark : Non-conforming traffic marked with AF11-mark rate marked with AF12-mark : Non-conforming traffic marked with
: Max latency = 1 second AF13-mark : Max latency = 1 second
AF13-Mark : 50 Kbps sustained, 100 Kb bursts tolerated at up to 100 AF11-Mark : 50 Kbps sustained, 100 Kb bursts tolerated at up to
Kbps : Egress point C : Excess burst traffic over sustained rate 100 Kbps : Egress point C : Excess burst traffic over sustained
marked with AF12-mark : Non-conforming traffic marked with AF11-mark rate marked with AF12-mark : Non-conforming traffic marked with
: Max latency = 2 seconds AF13-mark : Max latency = 2 seconds
Packets submitted for the assured playback service should be marked Bernet, et al Expires: September 1999 17
with the DS-field codepoint corresponding to the AF13 PHB. From the Packets submitted for the assured playback service should be
ingress point A, to the egress point B, the provider is promising to marked with the DS-field codepoint corresponding to the AF11 PHB.
carry up to 100 Kbps of sustained traffic with bursts of 100 Kb in From the ingress point A, to the egress point B, the provider is
size at a peak rate of 200 Kbps. Excess burst traffic will be marked promising to carry up to 100 Kbps of sustained traffic with bursts
with the codepoint for AF12 and out of profile traffic will be of 100 Kb in size at a peak rate of 200 Kbps. Excess burst traffic
carried but with the AF13 codepoint. So long as these conditions are will be marked with the codepoint for AF12 and out of profile
met, latency will be limited to 1 second. Note that for this traffic will be carried but with the AF13 codepoint. So long as
service, the traffic profile is described using a full set of token these conditions are met, latency will be limited to 1 second.
bucket parameters. Since the latency bounds for such a service are Note that for this service, the traffic profile is described using
less strict than those required for the leased line service, a a full set of token bucket parameters. Since the latency bounds
certain degree of traffic burstiness can be tolerated. for such a service are less strict than those required for the
leased line service, a certain degree of traffic burstiness can be
tolerated.
The provider must support the AF11, AF12 and AF13 PHBs in core The provider must support the AF11, AF12 and AF13 PHBs in core
network routers. These PHBs might be provided, for example, by network routers. These PHBs might be provided, for example, by
assigning AF11, AF12 and AF13 marked traffic to a single RIO queue assigning AF11, AF12 and AF13 marked traffic to a single RIO queue
with high drop thresholds. The policers at the edge would limit with high drop thresholds. The policers at the boundary would
competing traffic in line with the TCA, in order to assure that the limit competing traffic in line with the TCS, in order to assure
latency bounds can be met. In addition, the service provider will that the latency bounds can be met. In addition, the service
have to provision devices in the core of the network. The provider will have to provision devices in the core of the
provisioning considerations discussed in the context of the leased network. The provisioning considerations discussed in the context
line service apply here as well, however, in general, the service of the leased line service apply here as well, however, in
provider has the liberty of being less conservative in provisioning general, the service provider has the liberty of being less
and realizing better statistical gains. conservative in provisioning and realizing better statistical
gains.
5.4 Superposition of Quantitative and Qualitative Services in the Same 5.4 Superposition of Quantitative and Qualitative Services in the
Network Same Network
A compelling model would provide both quantitative and qualitative A compelling model would provide both quantitative and qualitative
services in the same differentiated service network(s) as follows. A services in the same differentiated service network(s) as follows.
number of corporate campus networks would be interconnected by a A number of corporate campus networks would be interconnected by a
differentiated service network providing quantitative services differentiated service network providing quantitative services
between the sites. For example, a mesh of leased line services would between the sites. For example, a mesh of leased line services
would enable IP telephony between the sites. A mesh of media
Blake, et al Expires: April 1999 15 playback service using the AF11 PHB would enable audio/video
enable IP telephony between the sites. A mesh of media playback playback between the sites. In addition, each corporate site would
service using the AF11 PHB would enable audio/video playback between be allotted some level of BBE service to arbitrary destinations.
the sites. In addition, each corporate site would be allotted some In this model, the differentiated service network is effectively
level of BBE service to arbitrary destinations. In this model, the providing a mesh of quantitative services between fixed locations
differentiated service network is effectively providing a mesh of (similar to a VPN). This mesh is superimposed on a cloud
quantitative services between fixed locations (similar to a VPN). supporting BBE service.
This mesh is superimposed on a cloud supporting BBE service.
6. Provisioning and Configuration 6. Provisioning and Configuration
The provision of differentiated services requires careful network The provision of differentiated services requires careful network
wide provisioning and configuration. Provisioning refers to the wide provisioning and configuration. Provisioning refers to the
determination and allocation of the resources needed at various determination and allocation of the resources needed at various
points in the network. Provisioning may dictate the addition or points in the network. Provisioning may dictate the addition or
removal of physical resources at various points (physical removal of physical resources at various points (physical
provisioning). Provisioning may also dictate the modification of provisioning). Provisioning may also dictate the modification of
Bernet, et al Expires: September 1999 18
operating parameters within existing physical network equipment to operating parameters within existing physical network equipment to
alter the relative share of the equipment's resources which are alter the relative share of the equipment's resources which are
allotted to one or another class of traffic (logical provisioning). allotted to one or another class of traffic (logical
Configuration refers to the distribution of the appropriate provisioning). Configuration refers to the distribution of the
operating parameters to network equipment to realize the appropriate operating parameters to network equipment to realize
provisioning objectives. the provisioning objectives.
In Secs. 4.6 and 4.7, we briefly discussed provisioning and In Secs. 4.6 and 4.7, we briefly discussed provisioning and
configuration requirements both at the network boundaries and in the configuration requirements both at the network boundaries and in
network interior. In this section we will focus primarily on the the network interior. In this section we will focus primarily on
coordination of provisioning and configuration throughout the the coordination of provisioning and configuration throughout the
network, such that end-to-end services can be provided reliably. We network, such that end-to-end services can be provided reliably.
will discuss the roles of protocols such as SNMP, CLI, RSVP, COPS We will discuss the roles of protocols such as SNMP, CLI, RSVP,
and LDAP in the provisioning process. COPS and LDAP in the provisioning process.
6.1 Boundary vs. Interior Provisioning and Configuration 6.1 Boundary vs. Interior Provisioning and Configuration
For the sake of brevity, consider the term 'provisioning' to refer For the sake of brevity, consider the term 'provisioning' to refer
both to provisioning and configuration, except where otherwise both to provisioning and configuration, except where otherwise
noted. It is helpful to consider provisioning at the network noted. It is helpful to consider provisioning at the network
boundaries, separately from provisioning of the interior. Since the boundaries, separately from provisioning of the interior. Since
differentiated service provider is selling a contract (SLA) at the the differentiated service provider is selling a contract (SLA) at
network boundary, we can consider the boundary provisioning which the network boundary, we can consider the boundary provisioning
supports SLAs, to drive the interior provisioning. The two are not which supports SLSs, to drive the interior provisioning. The two
entirely separable in that each affects the other. For example, a are not entirely separable in that each affects the other. For
network operator cannot offer an SLA which cannot be met by the example, a network operator cannot offer an SLS which cannot be
resources available in the interior of the network. In general, the met by the resources available in the interior of the network. In
overall provisioning process iterates between the boundaries and the general, the overall provisioning process iterates between the
interior. From here on we will refer to provisioning with respect to boundaries and the interior. From here on we will refer to
the TCA rather than the SLA, since the TCA is the component of the provisioning with respect to the TCS rather than the SLS, since
SLA that defines detailed traffic handling parameters. the TCS is the component of the SLS that defines detailed traffic
handling parameters.
Blake, et al Expires: April 1999 16
6.1.1 Boundary Provisioning 6.1.1 Boundary Provisioning
Boundary provisioning was considered briefly in Sec. 2.6. We Boundary provisioning was considered briefly in Sec. 2.6. We
discussed the minimal provisioning that a provider must implement to discussed the minimal provisioning that a provider must implement
enforce a TCA. We also discussed additional configuration which a to enforce a TCS. We also discussed additional configuration which
provider may use to provide additional (especially per-flow) a provider may use to provide additional (especially per-flow)
services to a customer. The latter is not actually related to the services to a customer. The latter is not actually related to the
provisioning of resources within the differentiated services provisioning of resources within the differentiated services
network, but rather assists the customer by determining which network, but rather assists the customer by determining which
subsets of the customer's traffic make use of the resources subsets of the customer's traffic make use of the resources
provisioned within the differentiated services network. As such, it provisioned within the differentiated services network. As such,
is out of the scope of this section. Here, we consider only the it is out of the scope of this section. Here, we consider only the
minimal provisioning required at the boundary. minimal provisioning required at the boundary.
At a minimum, the provider must assure that sufficient physical At a minimum, the provider must assure that sufficient physical
resources are provisioned at the boundary to meet the requirements resources are provisioned at the boundary to meet the requirements
of the TCA. For example, if the sum of the profiles supported at a of the TCS. For example, if the sum of the profiles supported at a
particular ingress point would allow 10 Mbps of traffic to be 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 supported, it is unacceptable to provision a T-1 access link. A T-
however, would be sufficient. Once the physical provisioning is
Bernet, et al Expires: September 1999 19
3 however, would be sufficient. Once the physical provisioning is
implemented, it is necessary to apply the appropriate logical implemented, it is necessary to apply the appropriate logical
provisioning. This is achieved by configuring policers which limit provisioning. This is achieved by configuring policers which limit
the amount of traffic accepted from the T-3 access link, at each 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 service level and, for double ended TCSs, for the appropriate
egress points. It may also be necessary to set up the amount of
buffering available for the queues used for the service. Similar buffering available for the queues used for the service. Similar
provisioning is also appropriate at each egress point if the provisioning is also appropriate at each egress point if the
aggregate of profiles provisioned to the egress exceeds the capacity aggregate of profiles provisioned to the egress exceeds the
of the output link. capacity of the output link.
6.1.2 Interior Provisioning 6.1.2 Interior Provisioning
For the purpose of provisioning the interior of the network, it is For the purpose of provisioning the interior of the network, it is
desirable to understand or to control the volume of traffic of each desirable to understand or to control the volume of traffic of
class which traverses each network node. The greater this each class which traverses each network node. The greater this
understanding, the more efficiently the network can be provisioned understanding, the more efficiently the network can be provisioned
while still meeting the requirements of the TCAs. It is feasible to while still meeting the requirements of the TCSs. It is feasible
understand the volume of traffic traversing each node if this to understand the volume of traffic traversing each node if this
traffic is admitted according to a TCA which dictates egress point traffic is admitted according to a TCS which dictates egress point
as well as ingress point. (This case generally applies to as well as ingress point. (This case generally applies to
quantitative services and was discussed in the context of the EF PHB quantitative services and was discussed in the context of the EF
and the leased line service in Sec. 3.2.1). While traffic volumes PHB and the leased line service in Sec. 3.2.1). While traffic
cannot be anticipated with 100% accuracy, it is possible to volumes cannot be anticipated with 100% accuracy, it is possible
approximate them quite well, especially with the help of route to approximate them quite well, especially with the help of route
pinning mechanisms. It is therefore possible to provision the pinning mechanisms. It is therefore possible to provision the
network reasonably accurately for traffic submitted for quantitative network reasonably accurately for traffic submitted for
services. Although such provisioning may be quite difficult in a quantitative services. Although such provisioning may be quite
large network, it is nonetheless a tractable problem. We will refer difficult in a large network, it is nonetheless a tractable
to this component of the provisioning problem as quantitative problem. We will refer to this component of the provisioning
provisioning. problem as quantitative provisioning.
Blake, et al Expires: April 1999 17
On the other hand, many (if not most) of the services offered by On the other hand, many (if not most) of the services offered by
differentiated service networks will not specify egress points (as differentiated service networks will not specify egress points (as
is the case for qualitative services) and will not restrict is the case for qualitative services) and will not restrict
submitted traffic to specific egress points, let alone specific submitted traffic to specific egress points, let alone specific
routes. Thus, interior nodes will have to be provisioned without an routes. Thus, interior nodes will have to be provisioned without
a-priori understanding of the volume of traffic submitted for an a-priori understanding of the volume of traffic submitted for
qualitative services which will arrive at each node. It is necessary qualitative services which will arrive at each node. It is
to be able to provision differentiated service networks to support necessary to be able to provision differentiated service networks
both quantitative services with specific egress points as well as to support both quantitative services with specific egress points
qualitative services, which do not have specific egress points on as well as qualitative services, which do not have specific egress
the same physical resources. To this end, it is necessary to isolate points on the same physical resources. To this end, it is
the impact of qualitative traffic on the resources reserved for necessary to isolate the impact of qualitative traffic on the
quantitative traffic. This can only be achieved if the former is resources reserved for quantitative traffic. This can only be
treated with lower priority than the latter. Thus, in general, achieved if the former is treated with lower priority than the
resources will have to be provisioned first for quantitative latter. Thus, in general, resources will have to be provisioned
traffic, using quantitative provisioning mechanisms. Then, first for quantitative traffic, using quantitative provisioning
qualitative provisioning can be used to allocate remaining resources mechanisms. Then, qualitative provisioning can be used to allocate
to qualitative traffic. Qualitative provisioning can also be remaining resources to qualitative traffic. Qualitative
applied to services which offer a relative quantification of traffic provisioning can also be applied to services which offer a
volumes. relative quantification of traffic volumes.
Bernet, et al Expires: September 1999 20
The impact of the two types of traffic will have to be isolated by The impact of the two types of traffic will have to be isolated by
ensuring that they do not share PHB codepoints. PHBs used for ensuring that they do not share PHB codepoints. PHBs used for
quantitative services will always have higher priority access to quantitative services will always have higher priority access to
resources than those used for qualitative services. As a result, it resources than those used for qualitative services. As a result,
is necessary to carefully police traffic submitted for quantitative it is necessary to carefully police traffic submitted for
PHBs. Failure to do so can result in the starvation of lower quantitative PHBs. Failure to do so can result in the starvation
priority traffic. In general it can be expected that only a small of lower priority traffic. In general it can be expected that only
fraction of the resources at each node will be provisioned for a small fraction of the resources at each node will be provisioned
quantitative traffic. for quantitative traffic.
Similarly, a significant fraction of the traffic capacity should Similarly, a significant fraction of the traffic capacity should
remain for best-efforts service to provide a 'soft' target for remain for best-efforts service to provide a 'soft' target for
traffic dropping if congestion occurs or it is necessary to redirect traffic dropping if congestion occurs or it is necessary to
non-best efforts traffic in the event of failure. redirect non-best efforts traffic in the event of failure.
6.1.2.1 Quantitative Provisioning of the Interior 6.1.2.1 Quantitative Provisioning of the Interior
As discussed previously, quantitative provisioning is a difficult As discussed previously, quantitative provisioning is a difficult
but tractable problem. With knowledge of the network routing but tractable problem. With knowledge of the network routing
topology and the TCAs at the boundaries, it is possible to compute topology and the TCSs at the boundaries, it is possible to compute
the resources required at each interior node to carry the the resources required at each interior node to carry the
quantitative traffic offered at the edges. Based on the results of quantitative traffic offered at the edges. Based on the results of
this computation, interior nodes must be provisioned and configured this computation, interior nodes must be provisioned and
with sufficient capacity to accommodate the quantitative traffic configured with sufficient capacity to accommodate the
which will arrive at the node, while leaving sufficient capacity quantitative traffic which will arrive at the node, while leaving
remaining to accommodate some amount of qualitative traffic. sufficient capacity remaining to accommodate some amount of
qualitative traffic.
The provisioning mechanism described assumes a top-down approach, in
which the network administrator studies the network topology and
traffic routing and computes the provisioning requirements. An
Blake, et al Expires: April 1999 18 The provisioning mechanism described assumes a top-down approach,
alternative approach uses signalling to automate the process [MPLS]. in which the network administrator studies the network topology
For example, RSVP messages could be launched along the paths that and traffic routing and computes the provisioning requirements. An
will be followed by submitted quantitative traffic. If a TCA calls alternative approach uses signaling to automate the process
for 100 Kbps of leased-line service from ingress point A to egress [MPLS]. For example, RSVP messages could be launched along the
point B, an RSVP message could be transmitted from point A towards paths that will be followed by submitted quantitative traffic. If
point B, with a flowspec specifying 100 Kbps. This message would a TCS calls for 100 Kbps of leased-line service from ingress point
traverse each node at which resources would have to be committed. A to egress point B, an RSVP message could be transmitted from
Conventional RSVP routers would install a reservation. In a point A towards point B, with a flowspec specifying 100 Kbps. This
differentiated service network, RSVP could be adapted to provision message would traverse each node at which resources would have to
the resources required per the differentiated services model. In a be committed. Conventional RSVP routers would install a
network which offers a number of static TCAs, such RSVP messages reservation. In a differentiated service network, RSVP could be
could be launched from the TCA ingress point at the time the TCA is adapted to provision the resources required per the differentiated
initially instantiated with the effect of instantiating the services model. In a network which offers a number of static TCSs,
appropriate cumulative provisioning in routers along the various such RSVP messages could be launched from the TCS ingress point at
routes. The advantage of this approach is that it does not require the time the TCS is initially instantiated with the effect of
explicit knowledge of the network topology. We will revisit these instantiating the appropriate cumulative provisioning in routers
two approaches to quantitative provisioning of the interior in a along the various routes. The advantage of this approach is that
later section. 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.
Bernet, et al Expires: September 1999 21
Once the resources required for quantitative traffic at each node Once the resources required for quantitative traffic at each node
have been determined, provisioning of the node consists of have been determined, provisioning of the node consists of
installing or configuring interfaces of the appropriate capacity to installing or configuring interfaces of the appropriate capacity
easily accommodate the quantitative traffic that will traverse the to easily accommodate the quantitative traffic that will traverse
node. Note that we do not state the precise meaning of 'to easily the node. Note that we do not state the precise meaning of 'to
accommodate'. A number of factors must be considered when easily accommodate'. A number of factors must be considered when
determining the appropriate capacity, given a certain volume of determining the appropriate capacity, given a certain volume of
predicted quantitative traffic. These include: predicted quantitative traffic. These include:
1. Margin of error 1. Margin of error
2. Statistical gain desired 2. Statistical gain desired
3. Capacity remaining for qualitative (including best efforts) 3. Capacity remaining for qualitative (including best efforts)
traffic traffic
The first, margin of error, accommodates mistakes in computation, The first, margin of error, accommodates mistakes in computation,
effects of transient route changes which are not otherwise accounted effects of transient route changes which are not otherwise
for, effects of traffic clustering as it moves through the network accounted for, effects of traffic clustering as it moves through
and so on. The statistical gain desired refers to the degree to the network and so on. The statistical gain desired refers to the
which a provider is willing to gamble that not all sources of degree to which a provider is willing to gamble that not all
quantitative traffic will be simultaneously active at the limit sources of quantitative traffic will be simultaneously active at
dictated by the TCAs at the ingress points (vs. the penalty the the limit dictated by the TCSs at the ingress points (vs. the
provider would be willing to pay in terms of refunded charges or penalty the provider would be willing to pay in terms of refunded
lost customers). Finally, the provider must determine how much charges or lost customers). Finally, the provider must determine
capacity will be reserved for qualitative traffic at each node. how much capacity will be reserved for qualitative traffic at each
Thus, if it is determined that 1 Mbps of quantitative traffic might node. Thus, if it is determined that 1 Mbps of quantitative
traverse a specific node in a specific direction, the provider might traffic might traverse a specific node in a specific direction,
install a 10 Mbps interface in the node, to serve the corresponding the provider might install a 10 Mbps interface in the node, to
traffic direction. This would leave 9 Mbps of capacity quite safely serve the corresponding traffic direction. This would leave 9 Mbps
for qualitative traffic. In this case, the provider would be of capacity quite safely for qualitative traffic. In this case,
assuming that statistical gains which might be realized will be used the provider would be assuming that statistical gains which might
to offset the margin of error which would compromise the resources be realized will be used to offset the margin of error which would
available. compromise the resources available.
Blake, et al Expires: April 1999 19 In addition to installing or configuring the appropriate capacity
In addition to installing or configuring the appropriate capacity at at each interface, it may be desirable to configure policers to
each interface, it may be desirable to configure policers to assure assure that the resources actually consumed by the higher priority
that the resources actually consumed by the higher priority quantitative traffic do not exceed expectations. This is
quantitative traffic do not exceed expectations. This is especially especially important if the provider is attempting to achieve a
important if the provider is attempting to achieve a high degree of high degree of statistical gain or has not allowed for a
statistical gain or has not allowed for a reasonable margin of reasonable margin of error. Policers need not be configured at
error. Policers need not be configured at each interior node, but each interior node, but should probably be configured at certain
should probably be configured at certain key nodes. It may also be key nodes. It may also be necessary to configure the internal
necessary to configure the internal resources of the router (queues resources of the router (queues and buffers) to deliver the
and buffers) to deliver the services required. services required.
6.1.2.2 Qualitative Provisioning of the Interior 6.1.2.2 Qualitative Provisioning of the Interior
As explained previously, it is necessary first to determine the As explained previously, it is necessary first to determine the
resources which must be provisioned at each node for quantitative resources which must be provisioned at each node for quantitative
traffic. Once these have been determined, interfaces must be traffic. Once these have been determined, interfaces must be
installed or provisioned to accommodate the required resources while installed or provisioned to accommodate the required resources
leaving sufficient capacity for qualitative traffic. In order to do while leaving sufficient capacity for qualitative traffic. In
so, it is necessary to determine the resources required at the node order to do so, it is necessary to determine the resources
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.
Once physical interfaces have been selected to accommodate the Bernet, et al Expires: September 1999 22
resources required by the computed quantitative traffic load and the required at the node for qualitative traffic. Since qualitative
estimated qualitative traffic load, additional configuration is traffic cannot be assumed to follow specific routes with the same
required to support qualitative traffic. Such configuration amounts degree of predictability as quantitative traffic, this
to the selection of relative weights for queues for different provisioning problem is far more difficult and provisioning
service levels (in a WFQ scheme), or the selection of RIO or RED parameters must be estimated based on heuristics, experience and
thresholds or alternate logical resource provisioning parameters. It possibly on real time measurement.
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.
Blake, et al Expires: April 1999 20 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 TCSs in place at the network boundaries.
6.2. Static vs. Dynamic Provisioning 6.2. Static vs. Dynamic Provisioning
So far, we have considered static provisioning techniques. Even the So far, we have considered static provisioning techniques. Even
example of RSVP usage for provisioning assumed that the RSVP the example of RSVP usage for provisioning assumed that the RSVP
messages were launched at the time a TCA was instantiated as opposed messages were launched at the time a TCS was instantiated as
to dynamically. In the case that TCAs are static, static opposed to dynamically. In the case that TCSs are static, static
provisioning is adequate for quantitative traffic. However, since provisioning is adequate for quantitative traffic. However, since
qualitative traffic [e.b.1] offers less predictable patterns, it is qualitative traffic offers less predictable patterns, it is likely
likely to cause traffic volumes at different nodes in the network to to cause traffic volumes at different nodes in the network to
change dynamically, even when the TCA is static. For this reason, change dynamically, even when the TCS is static. For this reason,
dynamic provisioning techniques are desirable and may assist the dynamic provisioning techniques are desirable and may assist the
service provider in making better use of network resources. In service provider in making better use of network resources. In
addition, dynamic provisioning may enable the service provider to addition, dynamic provisioning may enable the service provider to
provision more liberally for quantitative services, realizing provision more liberally for quantitative services, realizing
statistical gains. If we consider further, that it may be desirable statistical gains. If we consider further, that it may be
to provide dynamically changing TCAs, then the appeal of dynamic desirable to provide dynamically changing TCSs, then the appeal of
provisioning techniques is even stronger. dynamic provisioning techniques is even stronger.
Dynamic provisioning may be signalling based, measurement based or Dynamic provisioning may be signaling based, measurement based or
both. For example, a conventional RSVP router supports signalling both. For example, a conventional RSVP router supports signaling
based dynamic provisioning. Hosts signal the router to request more
or less resources and the router adjusts accordingly. The host may Bernet, et al Expires: September 1999 23
or may not actually submit traffic at the rate at which it signalled based dynamic provisioning. Hosts signal the router to request
it would, but regardless, the resources are committed in case it more or less resources and the router adjusts accordingly. The
does. Measurement based provisioning would adjust the resources host may or may not actually submit traffic at the rate at which
committed in response to the traffic loads actually measured at the it signaled it would, but regardless, the resources are committed
device. While differentiated services does not specify any form of in case it does. Measurement based provisioning would adjust the
signalled or measurement based provisioning, both may be useful. resources committed in response to the traffic loads actually
measured at the device. While differentiated services does not
specify any form of signaled or measurement based provisioning,
both may be useful.
6.3 Distributing Configuration Information 6.3 Distributing Configuration Information
The process of physical provisioning is by necessity relatively The process of physical provisioning is by necessity relatively
static and cannot be automated since it requires installation of static and cannot be automated since it requires installation of
physical equipment. However, logical provisioning and configuration physical equipment. However, logical provisioning and
can and should be automated to the degree possible. In this section, configuration can and should be automated to the degree possible.
we look at techniques for distributing configuration information. In this section, we look at techniques for distributing
configuration information.
6.3.1 Top Down Distribution of Configuration Information 6.3.1 Top Down Distribution of Configuration Information
In the simplest case, TCAs are static and both the boundaries and In the simplest case, TCSs are static and both the boundaries and
interior of the network are provisioned statically by 'pushing' interior of the network are provisioned statically by 'pushing'
configuration information down to the appropriate network nodes. configuration information down to the appropriate network nodes.
Configuration of boundary nodes requires primarily the pushing of Configuration of boundary nodes requires primarily the pushing of
policing information to enforce the TCAs in place. (Additional fine policing information to enforce the TCSs in place. (Additional
grain information may be pushed to provide traffic separation fine grain information may be pushed to provide traffic separation
services on behalf of the customer, but these are not addressed in services on behalf of the customer, but these are not addressed in
this context). Configuration information for boundary nodes is this context). Configuration information for boundary nodes is
determined at the time the TCA is negotiated. At this time, the determined at the time the TCS is negotiated. At this time, the
nodes are configured by the provider. The network administrator may nodes are configured by the provider. The network administrator
use one of several protocols to do so, including for example SNMP or may use one of several protocols to do so, including for example
CLI. SNMP or CLI.
Blake, et al Expires: April 1999 21 In order to accommodate the traffic submitted by the provisioning
In order to accommodate the traffic submitted by the provisioning of of new TCSs, it is necessary to provision the interior of the
new TCAs, it is necessary to provision the interior of the network. network. As discussed previously, it is possible to compute the
As discussed previously, it is possible to compute the resources resources required for quantitative traffic. Assuming that
required for quantitative traffic. Assuming that sufficient physical sufficient physical capacity has been provisioned, configuration
capacity has been provisioned, configuration amounts to logically amounts to logically provisioning sufficient capacity at each
provisioning sufficient capacity at each interior interface and to interior interface and to configuring policers for the
configuring policers for the quantitative traffic at various quantitative traffic at various interior nodes. In addition,
interior nodes. In addition, qualitative provisioning requires the qualitative provisioning requires the configuration of queues, WFQ
configuration of queues, WFQ weights and/or RIO parameters at weights and/or RIO parameters at various interior nodes, and may
various interior nodes, and may also include the configuration of also include the configuration of some number of policers. In the
some number of policers. In the case, of static, top down case, of static, top down configuration, interior configuration
configuration, interior configuration information is also pushed information is also pushed down via a configuration protocol such
down via a configuration protocol such as SNMP or CLI. as SNMP or CLI.
The difficulty of such top down provisioning is that it requires the The difficulty of such top down provisioning is that it requires
network administrator to coordinate the provisioning of each network the network administrator to coordinate the provisioning of each
node, at boundaries as well as in the interior, such that the network node, at boundaries as well as in the interior, such that
network is provisioned end-to-end in a consistent manner and is able
to efficiently deliver the services promised by the TCAs. In order Bernet, et al Expires: September 1999 24
to assist the network administrator in this task, it is useful to the network is provisioned end-to-end in a consistent manner and
consider a database which holds both current topology information as is able to efficiently deliver the services promised by the TCSs.
well as the current TCAs instantiated at the network boundaries. In order to assist the network administrator in this task, it is
This information is stored in a format dictated by a standard schema useful to consider a database which holds both current topology
as suggested in [Elleson]. information as well as the current TCSs instantiated at the
network boundaries. This information is stored in a format
dictated by a standard schema as suggested in [Ellesson].
Of course, the database is ideally maintained in a way which is Of course, the database is ideally maintained in a way which is
logically centralized (for ease of programming and modifying) but is logically centralized (for ease of programming and modifying) but
physically distributed (for the sake of robustness and fault is physically distributed (for the sake of robustness and fault
tolerance). Policy servers may be used to extract information from tolerance). Policy servers may be used to extract information from
the database and to convert it to configuration information which is the database and to convert it to configuration information which
pushed down to individual nodes. In this scenario, policy servers is pushed down to individual nodes. In this scenario, policy
would likely use a directory access protocol such as LDAP to servers would likely use a directory access protocol such as LDAP
retrieve information from the directory and would use a to retrieve information from the directory and would use a
configuration protocol such as SNMP or CLI to push the configuration configuration protocol such as SNMP or CLI to push the
information down to the network nodes. Note that in this example, configuration information down to the network nodes. Note that in
the policy servers and the directory schemas are in effect this example, the policy servers and the directory schemas are in
fulfilling the role of bandwidth broker [BB]. In particular, the effect fulfilling the role of bandwidth broker [ROTZY]. In
policy servers use an awareness of the network topology to provision particular, the policy servers use an awareness of the network
interior nodes such that certain end-to-end QoS routes can be topology to provision interior nodes such that certain end-to-end
constructed and assurances implied by the TCAs at the boundaries can QoS routes can be constructed and assurances implied by the TCSs
be delivered. at the boundaries can be delivered.
6.3.2 Distribution of Configuration Information via Signalling 6.3.2 Distribution of Configuration Information via Signaling
An alternate mechanism of distributing configuration information is An alternate mechanism of distributing configuration information
via signalling messages transmitted between boundary nodes of the is via signaling messages transmitted between boundary nodes of
same differentiated service domain (intra-domain signalling). It is the same differentiated service domain (intra-domain signaling).
also interesting to consider inter-domain signalling, but this will It is also interesting to consider inter-domain signaling, but
be addressed separately. An example of such signalling was described this will be addressed separately. An example of such signaling
previously, in the usage of a modified form of RSVP. Such signalling was described previously, in the usage of a modified form of RSVP.
Such signaling is particularly useful for the purpose of
installing configuration information for quantitative services
which affect specific paths and is somewhat less useful (though
not useless) for the purpose of configuring qualitative services.
It is likely that such a signaling approach would be used in
conjunction with top down provisioning. For example, the directory
schema might dictate the amount of resources to be available for
high priority quantitative services at each node. These limits
might be pushed down to individual nodes a-priori. Signaling from
the network boundaries, at TCS 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 signaling resource requests arrive at each node.
The latter model is similar to the use of per- flow RSVP signaling
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
Blake, et al Expires: April 1999 22 Bernet, et al Expires: September 1999 25
is particularly useful for the purpose of installing configuration that a variant of COPS would be used to communicate between
information for quantitative services which affect specific paths network nodes and the policy servers. Note that COPS may be used
and is somewhat less useful (though not useless) for the purpose of for distribution of top down configuration information as well,
configuring qualitative services. It is likely that such a though it is not specifically designed for this purpose.
signalling approach would be used in conjunction with top down
provisioning. For example, the directory schema might dictate the
amount of resources to be available for high priority quantitative
services at each node. These limits might be pushed down to
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.
One of the advantages of configuration via signalling, is that it One of the advantages of configuration via signaling, is that it
facilitates the support of dynamic TCAs. TCAs could be dynamically facilitates the support of dynamic TCSs. TCSs could be dynamically
renegotiated using inter-domain signalling. Such renegotiation would renegotiated using inter-domain signaling. Such renegotiation
require dynamically modifying the provisioning within the affected would require dynamically modifying the provisioning within the
domain, a process which requires some automated signalling protocol affected domain, a process which requires some automated signaling
such as an aggregated form of RSVP signalling between boundary nodes protocol such as an aggregated form of RSVP signaling between
in a provider's domain. This protocol would in effect, represent a boundary nodes in a provider's domain. This protocol would in
distributed bandwidth broker [BB] for the domain. effect, represent a distributed bandwidth broker [ROTZY] for the
domain.
6.3.3 Modification of Configuration Information Based on Real-Time 6.3.3 Modification of Configuration Information Based on Real-Time
Measurement Measurement
A third mechanism for the configuration of interior nodes would be A third mechanism for the configuration of interior nodes would be
based on measurement of current traffic loads at key network nodes. based on measurement of current traffic loads at key network
Measurement based configuration is less necessary for quantitative nodes. Measurement based configuration is less necessary for
provisioning, since quantitative traffic patterns are relatively quantitative provisioning, since quantitative traffic patterns are
predictable. However, it can significantly enhance the efficiency relatively predictable. However, it can significantly enhance the
with which qualitative provisioning can be achieved. For example, efficiency with which qualitative provisioning can be achieved.
network nodes may feed policy servers with current qualitative For example, network nodes may feed policy servers with current
traffic load measurements. In response, bandwidth brokers and policy qualitative traffic load measurements. In response, bandwidth
servers might recompute the relative weights for different service brokers and policy servers might recompute the relative weights
queues in a WFQ node and push the new configuration information to for different service queues in a WFQ node and push the new
the routers. It is likely that measurement based configuration for configuration information to the routers. It is likely that
qualitative services would be used in conjunction with signalling measurement based configuration for qualitative services would be
based configuration for quantitative services. used in conjunction with signaling based configuration for
quantitative services.
Blake, et al Expires: April 1999 23
7. Inter-Domain Considerations and End-to-End Services 7. Inter-Domain Considerations and End-to-End Services
So far we have considered differentiated service primarily in the So far we have considered differentiated service primarily in the
context of a single DS domain providing service to a single context of a single DS domain providing service to a single
customer. The ultimate customers of the differentiated service customer. The ultimate customers of the differentiated service
network are hosts and end users residing on peripheral stub network are hosts and end users residing on peripheral stub
networks. In general, these are interconnected by multiple domains networks. In general, these are interconnected by multiple domains
and require service which spans these domains. Therefore, it is and require service which spans these domains. Therefore, it is
important to consider the interaction of services provided by a important to consider the interaction of services provided by a
concatenation of differentiated service domains and the peripheral concatenation of differentiated service domains and the peripheral
stub networks, rather than the service provided by a single domain. stub networks, rather than the service provided by a single
In this section, we discus inter-domain issues related to TCAs, domain. The interactions of the services and the network
concatenation present a serious challenge to providers seeking to
provision the services scientifically. Whether algorithms or
heuristics can be developed to cover the full spectrum of service
combinations is an open question, but by analogy with QoS Routing
it is very likely that some of the problems are not computable.
In this section, we discuss inter-domain issues related to TCSs,
provisioning and service and PHB mapping. provisioning and service and PHB mapping.
7.1 TCAs Bernet, et al Expires: September 1999 26
7.1 TCSs
Each service provider is expected to negotiate bilateral agreements Each service provider is expected to negotiate bilateral
at each boundary node at which it connects to an adjacent provider's agreements at each boundary node at which it connects to an
network. Such agreements are captured in the form of two TCAs, one adjacent provider's network. Such The technical aspects of these
governing the services provided to provider A's traffic by provider agreements that relate to delivering differentiated services are
B and the other governing the services provided to provider B's captured in the form of two TCSs, one specifying the services
traffic by provider A. Note that provider A serves as a provider to provided to provider A's traffic by provider B and the other
provider B with respect to traffic flowing from provider B to specifying the services provided to provider B's traffic by
provider A. On the other hand provider A is a customer of provider B provider A. Note that provider A serves as a provider to provider
with respect to traffic flowing from provider A to provider B. The B with respect to traffic flowing from provider B to provider A.
two TCAs can be considered separately. On the other hand provider A is a customer of provider B with
respect to traffic flowing from provider A to provider B. The two
TCSs can be considered separately.
In general, the TCAs negotiated by a provider at any boundary will In general, the TCSs needed by a provider at any boundary will be
be dictated by TCAs negotiated at other boundaries. For example, dictated by TCSs negotiated at other boundaries. For example,
assume that provider A offers leased line service to a customer with assume that provider A offers leased line service to a customer
an ingress point in provider A's domain, but an egress point in with an ingress point in provider A's domain, but an egress point
provider B's domain. In this case, it is necessary that the TCA in provider B's domain. In this case, it is necessary that the TCS
between provider A and provider B be sufficient to accommodate the between provider A and provider B be sufficient to accommodate the
assurance made by provider A to its leased line service customer. assurance made by provider A to its leased line service customer.
Provider A may serve a number of customers with leased line services Provider A may serve a number of customers with leased line
terminating at various boundary points in provider B's network. services terminating at various boundary points in provider B's
Thus, the TCA between provider A and provider B must represent the network. Thus, the TCS between provider A and provider B must
aggregate requirements of the TCAs of all of provider A's customers. represent the aggregate requirements of the TCSs of all of
provider A's customers.
7.2 Inter-Domain Provisioning 7.2 Inter-Domain Provisioning
The inter-domain provisioning problem is not unlike the intra- The inter-domain provisioning problem is not unlike the intra-
domain provisioning problem. The provider would generally begin by domain provisioning problem. The provider would generally begin by
evaluating the TCAs it has negotiated with its customers, and then evaluating the TCSs it has negotiated with its customers, and then
computing the impact of each of these TCAs on the TCAs it has computing the impact of each of these TCSs on the TCSs it has
negotiated with its providers. For quantitative services, the negotiated with its providers. For quantitative services, the
provider can compute the quantitative requirements of TCAs at each provider can compute the quantitative requirements of TCSs at each
of its provider's boundary nodes, as described above in the context of its provider's boundary nodes, as described above in the
of the leased line service. For qualitative services, the process of context of the leased line service. For qualitative services, the
determining the requirements from its providers is fuzzier, since process of determining the requirements from its providers is
fuzzier, since the volume of qualitative traffic expected to be
Blake, et al Expires: April 1999 24 carried through any boundary is less deterministic.
the volume of qualitative traffic expected to be carried through any
boundary is less deterministic.
In the simplest case, provisioning is based on static TCAs. In this In the simplest case, provisioning is based on static TCSs. In
case, provisioning is an iterative process in which providers this case, provisioning is an iterative process in which providers
negotiate TCAs with each of their customers, then apply the negotiate TCSs with each of their customers, then apply the
appropriate internal provisioning techniques to meet these appropriate internal provisioning techniques to meet these
requirements. In the process of internal provisioning, a provider requirements. In the process of internal provisioning, a provider
might determine that a particular TCA cannot be met due to internal might determine that a particular TCS cannot be met due to
resource constraints. The provider would then either have to add internal resource constraints. The provider would then either have
internal resources or renegotiate one or more customer TCAs. to add internal resources or renegotiate one or more customer
Although the process may be somewhat iterative, it is relatively TCSs. Although the process may be somewhat iterative, it is
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.
Internal provisioning to meet the requirements of TCAs relies on Bernet, et al Expires: September 1999 27
provisioning techniques described previously. As TCAs are relatively static in that changes in boundary TCSs and internal
provisioning occur relatively infrequently (on the order of hours,
days or months) and require human intervention.
Internal provisioning to meet the requirements of TCSs relies on
provisioning techniques described previously. As TCSs are
negotiated, the provider must check that the existing internal negotiated, the provider must check that the existing internal
provisioning is sufficient to meet the requirements of the new TCA, provisioning is sufficient to meet the requirements of the new
or must alter the internal provisioning. Recall that internal TCS, or must alter the internal provisioning. Recall that internal
provisioning might be pushed in a top down manner, from a domain's provisioning might be pushed in a top down manner, from a domain's
logically centralized point of administration, or alternatively logically centralized point of administration, or alternatively
might be distributed from the edges via signalling. In the former might be distributed from the boundaries via signaling. In the
case, some form of a bandwidth broker would be directly consulted or former case, some form of a bandwidth broker would be directly
notified regarding changes in TCAs negotiated at the domain consulted or notified regarding changes in TCSs negotiated at the
boundaries. In the case that signalling is used, provisioning domain boundaries. In the case that signaling is used,
messages (such as described previously) would be launched from the provisioning messages (such as described previously) would be
boundary at which the new TCA is negotiated. These would claim a launched from the boundary at which the new TCS is negotiated.
share of existing provisioned resources, or would notify the These would claim a share of existing provisioned resources, or
bandwidth broker in the case that additional resources are required. would notify the bandwidth broker in the case that additional
resources are required.
A more sophisticated model would allow TCAs to be renegotiated A more sophisticated model would allow TCSs to be renegotiated
dynamically. In this case, the process would be automatic, and would dynamically. In this case, the process would be automatic, and
not require human intervention. Each domain would in effect, would not require human intervention. Each domain would in effect,
represent a bandwidth broker, via one protocol or another. A represent a bandwidth broker, via one protocol or another. A
specific inter-domain protocol might be used to communicate between specific inter-domain protocol might be used to communicate
centralized bandwidth broker agents, or alternatively, an inter- between centralized bandwidth broker agents, or alternatively, an
domain variant of RSVP might be used. In the latter case, there is inter- domain variant of RSVP might be used. In the latter case,
no direct interaction with a bandwidth broker per-se. However, the there is no direct interaction with a bandwidth broker per-se.
collection of network nodes, policy servers and directory behave However, the collection of network nodes, policy servers and
collectively as a bandwidth broker which communicates using RSVP. In directory behave collectively as a bandwidth broker which
either case, TCA renegotiations would be triggered by load communicates using RSVP. In either case, TCS renegotiations would
measurements at boundary nodes. These could be in the form of be triggered by load measurements at boundary nodes. These could
changes in actual measured traffic volume, or alternatively, based be in the form of changes in actual measured traffic volume, or
on explicit fine grain RSVP resource requests from hosts at the alternatively, based on explicit fine grain RSVP resource requests
periphery. Domains would approve renegotiations based both on from hosts at the periphery. Domains would approve renegotiations
resource constraints as well as predetermined policy constraints. based both on resource constraints as well as predetermined policy
constraints.
Blake, et al Expires: April 1999 25
7.3 Service, PHB and Codepoint Mapping 7.3 Service, PHB and Codepoint Mapping
In order to provide end-to-end service to customers, it must be In order to provide end-to-end service to customers, it must be
possible to extend services across multiple domains. Several possible to extend services across multiple domains. Several
complexities may arise at inter-domain boundaries, as follows: complexities may arise at inter-domain boundaries, as follows:
1. The services provided by a certain domain may not be compatible 1. The services provided by a certain domain may not be compatible
with the services provided by a neighbour domain. with the services provided by a neighbour domain.
2. The services provided by a certain domain may be compatible with 2. The services provided by a certain domain may be compatible
those provided by the neighbour domain, but the PHB used to with those provided by the neighbour domain, but the PHB used
obtain the service might be different. to obtain the service might be different.
3. The PHB might be the same, but the codepoint used to request the 3. The PHB might be the same, but the codepoint used to request
PHB might be different. the PHB might be different.
Bernet, et al Expires: September 1999 28
4. The PHB and codepoint are the same but differences in 4. The PHB and codepoint are the same but differences in
provisioning and charging models results in different services. provisioning and charging models results in different services.
Resolution of these complexities requires determination of the Resolution of these complexities requires determination of the
compatible services and negotiation of the PHB codepoints which will compatible services and negotiation of the PHB codepoints which
be used to request the services. This process is greatly simplified will be used to request the services. This process is greatly
by the provision of a set of universal services using universally simplified by the provision of a set of universal services using
recognized codepoints. The leased line service and EF codepoint is universally recognized codepoints. The leased line service and the
likely to be one such example. Generally, extension of quantitative recommended EF codepoint is likely to be one such example.
services across multiple domains will require more uniformity in the Generally, extension of quantitative services across multiple
nature of the services provided. Qualitative services on the other domains will require more uniformity in the nature of the services
hand, may be extended end-to-end by a concatenation of services provided. Qualitative services on the other hand, may be extended
which vary from domain to domain. For example, one domain may base a end-to-end by a concatenation of services which vary from domain
qualitative service on a WFQ scheme with RED while another may use to domain. For example, one domain may base a qualitative service
priority queuing with RIO. Since the assurances provided by on a WFQ scheme with RED while another may use priority queuing
qualitative services tend to be looser, it is possible that a with RIO. Since the assurances provided by qualitative services
meaningful service can be provided end-to-end by concatenating these tend to be looser, it is possible that a meaningful service can be
two service types. provided end-to-end by concatenating these two service types.
7.4 Host-Domain Boundaries 7.4 Host-Domain Boundaries
In certain cases, a host may be directly attached to a In certain cases, a host may be directly attached to a
differentiated service domain. This is likely both in the case of differentiated service domain. This is likely both in the case of
campus networks that provide differentiated services within the campus networks that provide differentiated services within the
network or in the case of dial-up users connecting to a network or in the case of dial-up users connecting to a
differentiated service provider. In these cases, the host can be differentiated service provider. In these cases, the host can be
considered the customer of the differentiated service network. considered the customer of the differentiated service network.
Legacy hosts are unlikely to mark their own packets for the Legacy hosts are unlikely to mark their own packets for the
appropriate DS-field and are also unlikely to shape or police their appropriate DS-field and are also unlikely to shape or police
traffic. In the case of legacy hosts, the differentiated service their traffic. In the case of legacy hosts, the differentiated
provider will have to provide these services on behalf of the service provider will have to provide these services on behalf of
customer. In the case of campus networks, some network wide policy the customer. In the case of campus networks, some network wide
would likely be used to configure these services in the DS boundary policy would likely be used to configure these services in the DS
devices. In the case of dial-up hosts, marking, shaping and boundary devices. In the case of dial-up hosts, marking, shaping
resources provided would likely be negotiated at the time the and resources provided would likely be negotiated at the time the
customer signs up with the provider. customer signs up with the provider.
Newer hosts may be capable both of marking and of traffic shaping. Newer hosts may be capable both of marking and of traffic shaping.
In this case, the overall per-host resource constraints are still In this case, the overall per-host resource constraints are still
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.
Blake, et al Expires: April 1999 26 8. Deployment Scenarios
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.
8. Inter-operability with RSVP/Integrated Services A number of scenarios can be envisaged for the junction of a non-
DS Domain and a DS Domain, and hence for deployment scenarios:
1. A service provider runs a DS Domain which offers Differentiated
Services to a customer who has a network which has no DS
capability - the junction occurs at the ingress to the service
Bernet, et al Expires: September 1999 29
provider's network. The service provider would provide
classification, marking and shaping of traffic as a value-added
service using information provided by the customer.
2. A service provider runs a DS Domain for a customer who has a
network which has mostly no DS capability except that the
customer's first hop or demarcation router acts as a
degenerate, one node DS Domain. The only (boundary) node in
this domain performs classification, marking and shaping,
whilst the provider's equipment just has to police the incoming
aggregate traffic.
3. The customer and provider both have fully capable DS Domains.
Hosts are embedded in the customer's DS Domain - the junction
between the non-DS and DS Domains is logically at the boundary
between the Operating System and the application.
Scenarios 1 and 2 provide simple initial deployment mechanisms for
DS as they do not require general modification of hosts. The
advantage of Scenario 2 over Scenario 1 is that the customer can
use, and keep private, local administrative knowledge to improve
the classification of packets. In Scenario 1 this information
would have to be made available in the service provider's domain
to achieve the same granularity of classification requiring that
the customer have greater trust in the provider.
Scenario 3 requires modification of hosts. Direct interaction
between applications and the DS Ingress node would therefore be
possible giving scope for sophisticated application of the DS
capabilities; even without such interaction, extremely fine-
grained classification of traffic packets would be possible in the
operating system kernel. Authentication of the application/host
and authorization to use DS services requires particular attention
in this case, although care has to be taken to avoid denial of
service attacks in all cases (see Sec. 11 and [DSARCH] for further
discussion of security).
A customer might also deploy a network of DS capable routers
before some or any of the associated hosts were DS capable.
Classification, marking and shaping would be provided by the
`first hop' router which the packet encounters on the first hop
after leaving the host; the core of the customer's network is
fully DS capable and the packets are forwarded in accordance with
their DSCP to another host in the same DS Domain or on to a
provider's domain.
It might be possible to utilize non-DS capable routers in the
interior of a DS Domain without compromising the QoS delivered
provided:
- The non-DS capable routers forward unchanged TOS byte all
packets marked with the values of DSCP used in the DS Domain.
- The non-DS capable routers forward these packets as if they
were best efforts traffic
Bernet, et al Expires: September 1999 30
- The non-DS capable routers are used only at points which rarely
or never experience congestion.
9. Inter-operability with RSVP/Integrated Services
In this section, we discuss alternatives for inter-operability In this section, we discuss alternatives for inter-operability
between differentiated services and RSVP/Integrated services. between differentiated services and RSVP/Integrated services.
8.1 RSVP/Integrated Services Over Differentiated Services 9.1 RSVP/Integrated Services Over Differentiated Services
This scenario is discussed in detail in [E2EQOS]. It assumes a model This scenario is discussed in detail in [E2EQOS]. It assumes a
in which peripheral stub networks are RSVP and Intserv aware. These model in which peripheral stub networks are RSVP and Intserv
are interconnected by differentiated service networks. In this aware. These are interconnected by differentiated service
model, the scalability of differentiated service networks helps to networks. In this model, the scalability of differentiated service
extend the reach of RSVP/Integrated service (Intserv)networks. networks helps to extend the reach of RSVP/Integrated service
Intervening differentiated service networks appear as a single RSVP (Intserv)networks. Intervening differentiated service networks
hop to the RSVP/Intserv networks. Hosts attached to the peripheral appear as a single RSVP hop to the RSVP/Intserv networks. Hosts
RSVP/Intserv networks signal to each other for per-flow resource attached to the peripheral RSVP/Intserv networks signal to each
requests across the differentiated service networks. Standard other for per-flow resource requests across the differentiated
RSVP/Intserv processing is applied within the RSVP/Intserv service networks. Standard RSVP/Intserv processing is applied
peripheral networks. RSVP signalling messages are carried within the RSVP/Intserv peripheral networks. RSVP signaling
transparently through the differentiated service networks. Devices messages are carried transparently through the differentiated
at the boundaries between the RSVP/Intserv networks and the service networks. Devices at the boundaries between the
differentiated service networks process the RSVP messages and RSVP/Intserv networks and the differentiated service networks
provide admission control based on the availability of appropriate process the RSVP messages and provide admission control based on
resources within the differentiated service network. the availability of appropriate resources within the
differentiated service network.
This model is predicated on the availability of services within the This model is predicated on the availability of services within
differentiated service network which can extend the reach of intserv the differentiated service network which can extend the reach of
type services. For example, the leased line service can extend the intserv type services. For example, the leased line service can
intserv guaranteed service across a differentiated service network. extend the intserv guaranteed service across a differentiated
Multiple guaranteed service micro-flows which exist in peripheral service network. Multiple guaranteed service micro-flows which
networks are aggregated into the EF behaviour aggregate at the edge exist in peripheral networks are aggregated into the EF behaviour
of the diffserv network. When an RSVP request for guaranteed service aggregate at the boundary of the diffserv network. When an RSVP
arrives at the edge of a differentiated service network, RSVP style request for guaranteed service arrives at the boundary of a
admission control is applied based on the amount of resources differentiated service network, RSVP style admission control is
requested in the intserv flowspec and the availability of applied based on the amount of resources requested in the intserv
differentiated services at the corresponding service level (per the flowspec and the availability of differentiated services at the
TCA). If admission control succeeds, the originating host (or its corresponding service level (per the TCS). If admission control
agent) marks traffic on the signalled microflow, for the appropriate succeeds, the originating host (or its agent) marks traffic on the
differentiated service level. signaled microflow, for the appropriate differentiated service
level.
The RSVP/Intserv over differentiated service model is especially The RSVP/Intserv over differentiated service model is especially
suitable for providing quantitative end-to-end services. The use of suitable for providing quantitative end-to-end services. The use
differentiated services eliminates the scalability concerns of of differentiated services eliminates the scalability concerns of
RSVP/Intserv networks. The use of RSVP signalling provides admission RSVP/Intserv networks. The use of RSVP signaling provides
control to the differentiated service network, based on resource admission control to the differentiated service network, based on
availability and policy decisions. It also greatly simplifies the resource availability and policy decisions. It also greatly
simplifies the configuration of differentiated service
Blake, et al Expires: April 1999 27 classifiers, policers and other traffic conditioning components.
configuration of differentiated service classifiers, policers and
other traffic conditioning components.
Bernet, et al Expires: September 1999 31
Variations on this theme would enable some number of nodes within Variations on this theme would enable some number of nodes within
the differentiated service networks to process the per-flow RSVP the differentiated service networks to process the per-flow RSVP
messages passing through. These could be used to aid in dynamic messages passing through. These could be used to aid in dynamic
provisioning without necessarily requiring any per-flow state or provisioning without necessarily requiring any per-flow state or
processing within the differentiated service network. In yet another processing within the differentiated service network. In yet
model, the transition of per-flow RSVP messages through the another model, the transition of per-flow RSVP messages through
differentiated service network might trigger aggregated RSVP the differentiated service network might trigger aggregated RSVP
signalling between differentiated service domain edges, for the signaling between differentiated service domain boundaries, for
purpose of renegotiating TCAs and adjusting provisioning dynamically the purpose of renegotiating TCSs and adjusting provisioning
[GBH97, CLASSY]. dynamically [GBH97, CLASSY].
8.2 Parallel Operation 9.2 Parallel Operation
Another alternative for the interoperation of differentiated service Another alternative for the interoperation of differentiated
and RSVP/Intserv networks is simple parallel operation. In this service and RSVP/Intserv networks is simple parallel operation. In
mode, each node within the differentiated service network may also this mode, each node within the differentiated service network may
be an RSVP capable node. Some strategy would have to be selected for also be an RSVP capable node. Some strategy would have to be
determining which packets are handled using RSVP and which are selected for determining which packets are handled using RSVP and
handled using differentiated services. For example, those that which are handled using differentiated services. For example,
classify to an RSVP installed filter might be handled using RSVP, those that classify to an RSVP installed filter might be handled
while those not classifying to specific RSVP filters would be using RSVP, while those not classifying to specific RSVP filters
handled according to the DS-field using differentiated service would be handled according to the DS-field using differentiated
mechanisms. Such a model is likely to be deployed in smaller service mechanisms. Such a model is likely to be deployed in
networks (since the RSVP/Intserv component is less suited for large smaller networks (since the RSVP/Intserv component is less suited
networks). In particular, the stub networks cited in [E2EQOS] would for large networks). In particular, the stub networks cited in
likely provide differentiated services for those qualitative [E2EQOS] would likely provide differentiated services for those
applications which do not signal, while providing RSVP/Intserv qualitative applications which do not signal, while providing
services for those quantitative applications which do signal. RSVP/Intserv services for those quantitative applications which do
signal.
9. Multicast Services 10. Multicast Services
The basic concept of Differentiated Services appears to offer an
excellent fit with a multicast service insofar as traffic may be
forwarded from an ingress to several egresses. Unfortunately, as
we shall see, provisioning a multicast service is extremely
difficult.
Because the Differentiated Services Architecture deals only with Because the Differentiated Services Architecture deals only with
unidirectional flows, a 'multicast' service in a DS network will in unidirectional flows, a 'multicast' service in a DS network will
fact offer a point-to-multipoint unidirectional service. Each in fact offer a point-to-multipoint unidirectional service. Each
source of traffic that wishes to send to the multicast group using source of traffic that wishes to send to the multicast group using
this service needs a separate SLA which applies at the ingress point this service needs a separate SLS which applies at the ingress
where the traffic enters the network. point where the traffic enters the network.
The network resources that must be provisioned for a multicast The network resources that must be provisioned for a multicast
service will be affected by the mechanisms used by the routers to service will be affected by the mechanisms used by the routers to
provide the service. Depending on the capabilities of the routers provide the service. Depending on the capabilities of the routers
and the multicast routing protocol employed, sub-optimal replication and the multicast routing protocol employed, sub-optimal
of a packet may result in multiple copies travelling over the same replication of a packet may result in multiple copies travelling
link. over the same link.
If receivers can be added dynamically to a multicast group whilst a Bernet, et al Expires: September 1999 32
flow is in progress, the complexity of provisioning grows If receivers can be added dynamically to a multicast group whilst
considerably: The amount of network resources that will be consumed a flow is in progress, the complexity of provisioning grows
considerably: The amount of network resources that will be
consumed 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.
Blake, et al Expires: April 1999 28 All multicast receivers must also be capable of handling the
by multicast traffic originating from a particular upstream network existing or proposed traffic on the multicast tree. This is an
may be difficult to forecast in advance. Consequently, it may not extension of the receiver control problem discussed in Sec. 4.4.1
be possible to offer quantitative services where dynamic addition of where it is clearly not desirable for a single inadequate receiver
receivers adds to the paths through the network already used by the to limit the traffic on a complete tree. It is therefore
flow. essential that a multicast service specify a minimum receiver
capacity _ where the service passes from one domain to another the
TCS on the receiving domain must offer at least this capacity.
9.1 Codepoints and PHBs for Multicast Services Note that application level multicast does not normally fall into
the multicast service category because it is normally realised as
a number of independent unicasts each of which is delivered by a
unicast service.
10.1 Codepoints and PHBs for Multicast Services
To achieve resource isolation of multicast traffic from unicast To achieve resource isolation of multicast traffic from unicast
traffic, it may be necessary to use separate codepoints and separate traffic, it may be necessary to use separate codepoints and
instances of a PHB or different PHBs for the multicast and unicast separate instances of a PHB or different PHBs for the multicast
services. If the multicast traffic is not adequately isolated, and unicast services. If the multicast traffic is not adequately
dynamic addition of new members of the multicast group can adversely isolated, dynamic addition of new members of the multicast group
affect existing unicast traffic. can adversely affect existing unicast traffic.
Because a multicast service traffic flow can exit from a domain to 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 several peer domains, care must be taken to use a codepoint and
that is compatible with the peering SLAs at the egress points. This PHB that is compatible with the peering SLSs at the egress points.
may be a more stringent requirement than for a unicast service where This may be a more stringent requirement than for a unicast
a flow need only be compatible with a single egress point SLA. service where a flow need only be compatible with a single egress
point SLS.
9.2 Provisioning Multicast Services 10.2 Provisioning Multicast Services
The scope of a multicast service would normally be either case 1 The scope of a multicast service would normally be either case 1
(any egress point) or case 3 (a pre-defined set of egress points) of (any egress point) or case 3 (a pre-defined set of egress points)
Sec. 4.4. of Sec. 4.4.
For a quantitative service the scope will, in general, need to be For a quantitative service the scope will, in general, need to be
case 3. The service can be provisioned in a similar way to case 3. The service can be provisioned in a similar way to
corresponding unicast services with the same volume of traffic along corresponding unicast services with the same volume of traffic
each of the paths from ingress to egress, but taking into account along each of the paths from ingress to egress, but taking into
that all paths will be used simultaneously and allowing for multiple account that all paths will be used simultaneously and allowing
copies of traffic if necessary. If the multicast routing protocol for multiple copies of traffic if necessary. If the multicast
used can generate different multicast trees depending on the order
in which members join the group, provisioning may not be possible. Bernet, et al Expires: September 1999 33
Solving this problem may require pinning of the multicast tree routing protocol used can generate different multicast trees
branch points; the solution of this problem is outside the scope of depending on the order in which members join the group,
this framework. 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.
For a qualitative service, provisioning is essentially the same as For a qualitative service, provisioning is essentially the same as
the unicast case, but statistical multiplexing gains are likely to the unicast case, but statistical multiplexing gains are likely to
be less because all paths may be used at once. be less because all paths may be used at once.
The traffic conditioning mechanisms for multicast services are not The traffic conditioning mechanisms for multicast services are not
significantly different from those for the unicast services but significantly different from those for the unicast services but
multiple shapers may be required where traffic exits from several multiple shapers may be required where traffic exits from several
interfaces on a single router or multiple replicas exit from one interfaces on a single router or multiple replicas exit from one
interface. interface.
Blake, et al Expires: April 1999 29 An additional problem arises when a service is actually used as
part of a multipoint-to-multipoint service. The traffic patterns
resulting from this usage and the required provisioning cannot be
easily generalised from the point-to-multipoint case, with the
result that it is difficult to determine how much extra capacity
should be provisioned when a link is a common path for traffic
from several sources.
10. Security and Tunnelling Considerations 11. Security and Tunneling Considerations
The security and tunnelling implications for the actual data The security and tunneling implications for the actual data
transport of the services of the Differentiated Services transport of the services of the Differentiated Services
Architecture have been extensively discussed in {DSARCH] and Architecture have been extensively discussed in [DSARCH] and
[DSHEAD] to which the reader is referred. [DSHEAD] to which the reader is referred.
Additional security considerations arise from the services overlaid Additional security considerations arise from the services
on the data transport: overlaid on the data transport:
1. The services are the subject of differential charging. 1. The services maybe the subject of differential charging.
Accordingly, the service users have to be authenticated and Accordingly, the service users have to be authenticated and
authorised, and the accounting data needed must be secured. authorized, and the accounting data needed must be secured.
2. The mechanisms used to create and distribute the policy and 2. The mechanisms used to create and distribute the policy and
resource allocations must be secured. resource allocations must be secured.
3. Statistical data needed to audit service delivery must be 3. Statistical data needed to audit service delivery must be
secured. secured.
The mechanisms used to provide this security are outside the scope The mechanisms used to provide this security are outside the scope
of this framework, but are under consideration by the AAA working of this framework, but are under consideration by the AAA working
group. group.
The use of tunnels in general and IPsec tunnels in particular The use of tunnels in general and IPsec tunnels in particular
impedes the work of MF Classifiers by concealing the fields used by impedes the work of MF Classifiers by concealing the fields used
L4 and higher layer classifiers. Thus traffic conditioners within by L4 and higher layer classifiers. Thus traffic conditioners
the area where IPsec encryption is used will need to rely only on IP within the area where IPsec encryption is used will need to rely
header fields, including the DS field (BA Classifiers will work only on IP header fields, including the DS Field (BA Classifiers
normally). If more sophisticated Mf classification is required it will work normally). If more sophisticated MF classification is
will have to take place before the tunnel ingress and the required it will have to take place before the tunnel ingress and
application of IPsec encryption. If IPsec encryption is used end-
to-end, then Differentiated Services may require host marking. Bernet, et al Expires: September 1999 34
the application of IPsec encryption. If IPsec encryption is used
end-to-end, then Differentiated Services may require host marking
Similarly, there is a constraint on quantitative services in
general because IPsec hides the final destination address, so that
it may be difficult to police quantitative services when IPsec is
used because the traffic conditioner cannot determine the egress
address easily.
If a tunnel carries multiple flows with different traffic types, If a tunnel carries multiple flows with different traffic types,
they may be marked with different DS codepoints so that they are they may be marked with different DS codepoints so that they are
subjected to appropriate behaviors in the network interior. This subjected to appropriate behaviors in the network interior. This
may be considered to be a security breach as it allows traffic may be considered to be a security breach as it allows traffic
patterns to become visible. If just one codepoint is used for all patterns to become visible. If just one codepoint is used for all
traffic it should be selected carefully to be appropriate for all traffic it should be selected carefully to be appropriate for all
the traffic in the tunnel. the traffic in the tunnel.
11. Acknowledgements 12. 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, David
Carpenter, David Black, Konstantinos Dovrolis, Shivkumar Kalyana, Black, Konstantinos Dovrolis, Shivkumar Kalyana, Wu-chang Feng,
Wu-chang Feng, Marty Borden, and Ronald Bonica. Marty Borden, and Ronald Bonica.
Blake, et al Expires: April 1999 30
12. References 13. References
[BB] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit [2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet", Internet Differentiated Services Architecture for the Internet", Internet
Draft Draft
[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
[CLASSY] S. Berson and S. Vincent, "Aggregation of Internet [CLASSY] S. Berson and S. Vincent, "Aggregation of Internet
Integrated Services State", Internet Draft, November 1997. Integrated Services State", Internet Draft, November 1997.
[COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A. [COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A.
Sastry, "COPS (Common Open Policy Service) Protocol", March 1998. Sastry, "COPS (Common Open Policy Service) Protocol", March 1998.
[DSARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and W. [DSARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and
Weiss, "An Architecture for Differentiated Services", Internet W. Weiss, "An Architecture for Differentiated Services", Internet
Draft, May 1998. Draft, May 1998.
[DSHEAD] K. Nichols and S. Blake, "Definition of the Differentiated [DSHEAD] K. Nichols and S. Blake, "Definition of the
Services Field (DS Byte) in the IPv4 and IPv6 Headers", Internet Differentiated Services Field (DS Byte) in the IPv4 and IPv6
Draft, May 1998. Headers", Internet Draft, May 1998.
[AF] J.Heinanen, _Assured Forwarding PHB Group_Internet Draft, [AF] J.Heinanen, _Assured Forwarding PHB Group_Internet Draft,
August 1998. August 1998.
[EF] V.Jacobson, _Expedited Fowarding Per Hop Behavior_, Internet [EF] V.Jacobson, _Expedited Forwarding Per Hop Behavior_,
Draft, August 1998. Internet Draft, August 1998.
[Ellesson] E. Ellesson and S. Blake, "A Proposal for the Format and Bernet, et al Expires: September 1999 35
Semantics of the TOS Byte and Traffic Class Byte in IPv4 and IPv6", [Ellesson] E. Ellesson and S. Blake, "A Proposal for the Format
Internet Draft, November 1997. and Semantics of the TOS Byte and Traffic Class Byte in IPv4 and
IPv6", Internet Draft, November 1997.
[E2EQOS] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, and L. Zhang, [E2EQOS] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K.
"A Framework for End-to-End QoS Combining RSVP/Intserv and Nichols and M. Speer, "A Framework for the Use of RSVP with Diff-
Differentiated Services", Internet Draft, March 1998. serv Networks", Internet Draft, November 1998.
[GBH97] R. Guerin, S. Blake, and S. Herzog, "Aggregating RSVP- based [DiffEdge] Y. Bernet, D. Durham and F. Reichmeyer, _Requirements
QoS Requests", Internet Draft, November 1997. of Diff-serv Boundary Routers_, Internet Draft, November 1998.
[IntServ] R. Braden, D. Clark, and S. Shenker, "Integrated Services [ROTZY] F. Reichmeyer, L. Ong, A. Terzis, L. Zhang, and
in the Internet Architecture: An Overview", Internet RFC 1633, July R. Yavatkar, _A Two-Tier Resource Management Model for
1994. Differentiated Services Networks_, Internet Draft, November 1998
[MPLS] B. Thomas, N. Feldman, P. Doolan, L. Andersson and
A. Fredette, "Label Distribution Protocol Specification", Internet
Draft, January 1999.
[GBH97] R. Guerin, S. Blake, and S. Herzog, "Aggregating RSVP-
based QoS Requests", Internet Draft, November 1997.
[IntServ] R. Braden, D. Clark, and S. Shenker, "Integrated
Services in the Internet Architecture: An Overview", Internet RFC
1633, July 1994.
[RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) -- [RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", Internet RFC 2205, September Version 1 Functional Specification", Internet RFC 2205, September
1997. 1997.
Blake, et al Expires: April 1999 31 [RFC791] Information Sciences Institute, "Internet Protocol",
Internet RFC 791, September 1981.
11. Author's Addresses [RFC1349] P. Almquist, "Type of Service in the Internet Protocol
Suite", Internet RFC 1349, July 1992.
14. Author's Addresses
Bernet, Yoram 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
Email: yoramb@microsoft.com Email: yoramb@microsoft.com
Bernet, et al Expires: September 1999 36
Binder, James 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
Email: james_binder@3com.com Email: james_binder@3com.com
Blake, Steven Blake, Steven
Torrent Networking Technologies Torrent Networking Technologies
3000 Aerial Center, Suite 140 3000 Aerial Center, Suite 140
skipping to change at line 1625 skipping to change at line 1919
Fax: +1-919-468-0174 Fax: +1-919-468-0174
Email: slblake@torrentnet.com Email: slblake@torrentnet.com
Carlson, Mark 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
Email: mac@redcape.com Email: mac@redcape.com
Carpenter, Brian E
IBM United Kingdom Laboratories
MP185
Hursley Park
Winchester
Hampshire SO21 2JN
UK
Phone: +44 1962 816833
Email: brian@hursley.ibm.com
Davies, Elwyn Davies, Elwyn
Nortel UK Nortel Networks
London Road London Road
Harlow, Essex CM17 9NA, UA Harlow, Essex CM17 9NA, UA
Phone: +44-1279-405498 Phone: +44-1279-405498
Email: elwynd@nortel.co.uk Email: elwynd@nortelnetworks.com
Ohlman, Borje 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
Email: Borje.Ohlman@ericsson.com Email: Borje.Ohlman@ericsson.com
Blake, et al Expires: April 1999 32 Bernet, et al Expires: September 1999 37
Srinivasan Keshav Srinivasan Keshav
4107B Uspon Hall 4107B Uspon Hall
Cornell University Cornell University
Ithaca, NY 14853 Ithaca, NY 14853
Phone: +607-255-5395 Phone: +607-255-5395
Email: skeshav@cs.cornell.edu Email: skeshav@cs.cornell.edu
Dinesh Verma IBM T. J. Watson Research Center Dinesh Verma IBM T. J. Watson Research Center
P.O. Box 704 P.O. Box 704
Yorktown Heights, NY 10598 Yorktown Heights, NY 10598
skipping to change at line 1665 skipping to change at line 1969
Bell Labs Lucent Tech Bell Labs Lucent Tech
101 Crawfords Corner Road 101 Crawfords Corner Road
Holmdel, NJ 07733 Holmdel, NJ 07733
Email: zhwang@bell-labs.com Email: zhwang@bell-labs.com
Walter Weiss Walter Weiss
Lucent Technologies Lucent Technologies
300 Baker Avenue, Suite 100 Concord, MA 01742-2168 300 Baker Avenue, Suite 100 Concord, MA 01742-2168
Email: wweiss@lucent.com Email: wweiss@lucent.com
Blake, et al Expires: April 1999 33 Bernet, et al Expires: September 1999 38
 End of changes. 234 change blocks. 
985 lines changed or deleted 1289 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/