draft-ietf-diffserv-rsvp-01.txt   draft-ietf-diffserv-rsvp-02.txt 
Internet Engineering Task Force Y. Bernet, Microsoft Internet Draft Y. Bernet, Microsoft
Internet Draft R. Yavatkar, Intel Expiration: August 1999 R. Yavatkar, Microsoft
draft-ietf-diffserv-rsvp-01.txt P. Ford, Microsoft File: draft-ietf-diffserv-rsvp-02.ps P. Ford, Microsoft
F. Baker, Cisco F. Baker, Cisco
L. Zhang, UCLA L. Zhang, UCLA
K. Nichols, Cisco Systems K. Nichols, Cisco
M. Speer, Sun Microsystems M. Speer, Sun Microsystems
R. Braden, ISI
November, 1998 Interoperation of RSVP/Int-Serv and Diff-Serv Networks
A Framework for Use of RSVP with Diff-serv Networks
Status of this Memo
This document is an Internet Draft. Internet Drafts are working documents of
the Internet Engineering Task Force (IETF), its Areas, and its Working Groups.
Note that other groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress".
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
A revised version of this draft document will be submitted to the February 26, 1999
RFC editor as an Informational RFC for the Internet Community.
Discussion and suggestions for improvement are requested. This
document will expire before May 1999. Distribution of this
draft is unlimited.
Use Of RSVP with Diffserv June, 1998 Status of Memo
1. Abstract This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
In the past several years, work on QoS enabled networks led to the Internet-Drafts are draft documents valid for a maximum of six months
development of the Integrated Services (Intserv) architecture [12] and and may be updated, replaced, or obsoleted by other documents at any
the RSVP signaling protocol [1]. RSVP, as specified, enables applica- time. It is inappropriate to use Internet- Drafts as reference
tions to signal per-flow requirements to the network. Intserv parame- material or to cite them other than as "work in progress."
ters are used to quantify these requirements for the purpose of admis-
sion control. However, as work on RSVP and Intserv has proceeded, we
have recognized the following basic limitations, which impede deploy-
ment of these mechanisms in the Internet at large:
1) The reliance of RSVP on per-flow state and per-flow processing The list of current Internet-Drafts can be accessed at
raises scalability concerns in large networks. http://www.ietf.org/ietf/1id-abstracts.txt
2) Today, only a small number of hosts generate RSVP signaling.
While this number is expected to grow dramatically, many
applications may never generate RSVP signaling.
3) Many applications require a form of QoS, but are unable to
express these requirements using the intserv model.
At present, the market is pushing for immediate deployment of a QoS The list of Internet-Draft Shadow Directories can be accessed at
solution that addresses the needs of the Internet as well as enter- linebreak http://www.ietf.org/shadow.html.
prise networks. This push has led to the development of Differentiated
services (diff-serv). In contrast to RSVP's per-flow orientation,
diff-serv networks classify packets to one of a small number of aggre-
gated flows, based on the setting of bits in the TOS field of each
packet's IP header. Thus, in addition to eliminating the reliance on
per-flow state, diff-serv QoS can initially be deployed using top-down
provisioning, with no requirement for end-to-end signaling.
At the same time however, it is important to assure that the diff-serv Abstract
mechanisms deployed, interoperate effectively with hosts and networks
that provide per-flow QoS in response to end-to-end signaling. This is
important, as we believe that in the coming years, there will be a
proliferation of applications that depend on QoS and of hosts which
will signal end-to-end on their behalf.
This draft proposes a framework in which diff-serv capable networks Differentiated Services (diff-serv) and RSVP/Integrated Services
provide aggregate QoS services, and they co-exist and inter-operate (RSVP/int-serv) provide complementary approaches to the problem of
with RSVP/Intserv capable hosts and stub networks, which use end-to- providing QoS for Internet end systems. These approachs must be able
end signaling. to coexist and effectively interoperate. This document outlines one
important model for such interoperation, in which diff-serv is used
by transit networks in the core of the Internet while hosts and edge
networks use RSVP/int-serv. It also contains a brief discussion of
some alternative models for interoperation.
For instance, in one example of such a model, diff-serv mechanisms are 1. Introduction
used within transit networks and at the boundaries between them, while
either diff-serv or RSVP/Intserv mechanisms are used within stub net-
works and at the boundaries between stub networks and transit diff-
serv networks. Managers of the transit networks will provision a pool
of network resources to be available in response to end-to-end signal-
ing. The remaining resources will be allotted using traditional 'top-
Use Of RSVP with Diffserv June, 1998 Work on QoS-enabled IP networks has led to two distinct approaches:
the Integrated Services (int-serv) architecture [12] and its
signaling protocol RSVP [1], and the Differentiated Services (diff-
serv) architecture [10].
down' provisioning methods. RSVP enables applications to signal per-flow QoS requirements to the
network, with explicit admission control. Int-serv uses RSVP
signaling to request tight QoS with quantitative parameters. Int-
serv also imposes fine-grain policing and scheduling of traffic, to
ensure that admitted flows receive their service requests in strict
isolation from each other and from best-effort traffic. RSVP
signaling configures packet classifiers in the int-serv capable
routers along the path of the flow. These classifiers perform a
fine-grain or `MF' [10] classification of packets, using on IP
addresses and port numbers for example.
However, our model does not preclude other possibilities: use of Some basic limitations to the RSVP/int-serv model have impeded its
diff-serv mechanisms and top-down provisioning in both stub and tran- deployment in the Internet at large.
sit networks to support applications that do not use any explicit sig-
naling, or use of RSVP signaling for admission control in conjunction
with diff-serv mechanisms in transit networks. In particular, the pro-
posed framework will allow for a scenario in which RSVP signaling is
used for dynamic provisioning and admission control in the diffserv
region of the network. In such a case, routers in the diff-serv region
will continue use the DSCP value in the IP datagram to identify and
offer services to flow aggregates. However, some of these services
will use dynamic provisioning and require admission control using
explicit signaling when a new flow is to be added to the aggregate.
Under such a scenario, one can envision use of RSVP signaling to com-
municate the flow specification and desired DSCP (flow aggregate) to
the routers in the diff-serv region of the network.
Our framework allows the deployment of diff-serv networks and o The use of per-flow state and per-flow processing raises
RSVP/Intserv networks to proceed at their own pace, providing immedi- scalability concerns for large networks.
ate incremental benefits in areas of the network in which one or the
other is deployed and additional benefits where both are deployed.
This framework builds upon current work in the IETF including diff-
serv [10] and RSVP aggregation [8].
Many of the ideas in this document have been previously discussed in o Only a small number of hosts currently generate RSVP signaling.
the original intserv architecture document [12]. While this number is expected to grow dramatically, some
applications may never generate RSVP signaling.
2. Goals of This Draft o Some applications require a form of QoS that cannot be expressed
using the int-serv model.
This draft is based on the assumption that end-to-end QoS is required o The necessary policy control mechanisms -- access control,
to support the needs of certain applications. Such applications authentication, and accounting -- are not available.
include IP-telephony, video-on-demand, and various non-multimedia
mission-critical applications.
In our view, intserv and diff-serv are complementary tools in the pur- The market is pushing for immediate deployment of a QoS solution that
suit of end-to-end QoS. Each serves an important purpose in the end- addresses the needs of the Internet as well as enterprise networks.
to-end QoS enabled network. The primary goal of this draft is to This push led to the development of Differentiated Services. In
encourage the continued development of each in a manner that does not contrast to the per-flow orientation of int-serv and RSVP, diff-serv
preclude realization of the proposed framework. To this end, we will: networks classify packets into one of a small number of aggregated
flows or "classes", based on bits set in the TOS field of each
packet's IP header. This is known as `BA' classification [10]. In
addition to eliminating the requirement for per-flow state, diff-serv
QoS can initially be deployed using long-term provisioning rather
than short-term reservations established by end-to-end signaling.
1. List the requirements of a network that provides end-to-end QoS. We view int-serv and diff-serv as complementary tools in the pursuit
2. Present a framework that uses intserv as a customer of diff-serv of end-to-end QoS. For many applications, the loose or "qualitative"
to meet these requirements. QoS provided by diff-serv will be adequate. However, some
3. Identify dependencies of intserv on diff-serv. applications will require the tight quantitative end-to-end QoS
assurance provided by int-serv and RSVP. Current examples of
applications that need tight QoS include IP-telephony, video-on-
demand, and various non-multimedia mission-critical applications, and
such applications may proliferate in the future. The diff-serv
mechanisms that are deployed must be able to interoperate effectively
with hosts and networks that provide per-flow QoS using int-serv
models.
Ultimately, we aim to clearly define a manner in which RSVP/Intserv There are several different models for coexistence and interoperation
between RSVP/int-serv and diff-serv. This draft is primarily
concerned with one important model, although Section 5 presents a
brief look at other models. Under our model, diff-serv mechanisms
are used within transit networks in the `core' of the network, while
RSVP/int-serv mechanisms are used within stub networks at the 'edge'.
From the int-serv viewpoint, the diff-serv transit network is treated
as a virtual link connecting int-serv/RSVP capable routers. This
model builds upon work in progress on RSVP aggregation [8, 15].
Use Of RSVP with Diffserv June, 1998 This model will provide a framework that will allow deployment of
diff-serv networks and deployment of RSVP/int-serv networks to
proceed at their own pace, providing immediate incremental benefits
in areas of the network in which one or the other is deployed and
additional benefits where both are deployed. Ultimately, we want
RSVP/int-serv and diff-serv mechanisms to interact seamlessly.
Network administrators should be able to determine for their own
networks the degree to which diff-serv capabilities are pushed
towards the edge of their networks, or the degree to which RSVP/int-
serv capabilities are pushed towards the core of the Internet.
and diff-serv mechanisms interact seamlessly. We expect that by doing Section 2 provides an overview of our model for interoperation
so, we will enable network administrators to determine the degree to between int-serv and diff-serv, and discusses some of the
which diff-serv capabilities are pushed towards the edge of their net- assumptions. Section 3 presents the model in more detail, while
works (or, the degree to which RSVP/Intserv capabilities are pushed Section 4 discusses its implications for diff-serv. Finally, Section
towards the core). 5 briefly lists some other possible models for interoperation.
Appendix A contains a list of some important terms used in this
document.
Even though one of the goals of this draft is to describe a framework Even though one of the goals of this draft is to describe a framework
for co-existence of RSVP/intserv with diff-serv, the draft currently for co-existence of RSVP/int-serv with diff-serv, the draft currently
does not address the issues specific to IP multicast flows such as does not address the issues specific to IP multicast flows. See
merging dissimilar reservations. Section 5.
3. Terminology
The following terms are used in this draft:
a. Intserv region (or intserv capable network) - the part of an
internet that uses per-flow identification, signaling, and admission
control to deliver per-flow QoS guarantees
b. Diff-serv region (or diff-serv capable network) - the part of an
internet that provides aggregate QoS services
c. Quantitative QoS applications - applications for which QoS
requirements are readily quantifiable, and which rely on these QoS
requirements to function properly.
d. Qualitative QoS applications - applications for which relative
QoS requirements exist, but are not readily quantifiable.
e. QoS applications - applications that require some form of QoS,
either qualitative or quantitative.
f. Loose QoS - QoS assurances which are relative, rather than
absolute, or generally not quantifiable.
g. Tight QoS - QoS assurances which are quantifiable,
though they may or may not provide 100% guarantee.
h. Top-down (or open-loop) provisioning - traditional provisioning
methods which configure network capacities using heuristics and
experience, typically from a console, with no explicit knowledge of
exact traffic volumes or exact paths taken by the affected traffic.
i. RSVP/Intserv - RSVP is a signaling protocol. Intserv (in this
context) is a model for quantifying traffic that is useful for
admission control purposes. In this document, we use the terms
together, to discuss the RSVP/Intserv network, in contrast to the
diff-serv network. However, the two are separable and much of the
Use Of RSVP with Diffserv June, 1998
following discussion could be applied to a model in which RSVP
signals using parameters that are not Intserv specific.
4. Requirements for the End-to-End QoS Framework An end-to-end QoS
network must serve the requirements of network managers as well as
those of both quantitative and qualitative QoS applications. We con-
sider these requirements in the context of the following general
topology:
/ Stub \ / Transit \ / Stub \
/ Network \ / Network \ / Network \
|---| | |---| |---| |---| |---| | |---|
|Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx |
|---| | |-- | |---| |---| |---| | |---|
\ / \ / \ /
\ / \ / \ /
Figure 1: Sample Network Configuration
This network consists of a diff-serv capable transit network and two
intserv capable stub networks. In the interest of simplicity, we show
a single QoS sender on one of the stub networks and a single QoS
receiver on the other. We show edge routers (ER1, ER2) at the inter-
faces of the intserv networks to the diff-serv network. We show boun-
dary routers (BR1, BR2) at the interfaces of the diff-serv network to
the intserv networks.
The transit network contains a mesh of routers, at least some of which 2. Overview of the Model
are diff-serv capable. The stub networks contain a mesh of routers, at
least some of which are intserv capable.
We define the following requirements of the framework: This section examines the issues in providing tight quantitative
end-to-end QoS over end-to-end paths that includes both int-serv
networks and diff-serv networks, and introduces our model.
4.1 Definition of a Set of Services 2.1 Quantitative End-to-End QoS
There must be a set of useful end-to-end services available to Quanti- The primary focus of this document on end-to-end quantitative QoS.
tative QoS applications. Routers internal to the diff-serv network are Although quantitative QoS applications may generate only a small
assumed to provide a set of 'per-hop-behaviors' (PHBs [10]). We expect fraction of all traffic, servicing this traffic may comprise a
that concatenation of certain well-defined PHBs will yield certain significant fraction of the revenues associated with QoS. In
well-understood services across the diff-serv network. We also expect addition, while qualitative QoS applications can be satisfied by
that the intserv regions of the network will be able to extend these conventional diff-serv alone, quantitative QoS applications
services such that they can be realized in a true end-to-end manner. require additional support.
In addition, there must be a set of end-to-end services available to Diff-serv is expected to define some well-defined edge-to-edge
Qualitative QoS applications. However, the services that these services, which will be formed by concatenation of the `per-hop-
behaviors' (PHBs [10]) that are being defined for internal diff-
serv routers, possibly with some defined shaping and/or policing
at the ingress. Our model assumes that it will be possible to map
the quantitative QoS services defined by int-serv into these
diff-serv services within the diff-serv network, in order to
satisfy the end-to-end requirement of a quantitative QoS
application.
Use Of RSVP with Diffserv June, 1998 2.2 Packet Marking
applications require are generally less demanding. They can be loosely Within the diff-serv regions of the network, traffic is allotted
provisioned (in a top-down manner) in the diff-serv regions of the service based on the contents of the DS-field in the IP headers.
network and will likely receive best-effort treatment in the intserv Setting the DS-field is referred to as `marking' the packet. QoS
regions of the network. applications must be able to effect the correct marking of DS-
fields before their packets enter a diff-serv network. There are
two choices for accomplishing this.
In this draft we focus primarily on the requirements of quantitative Host Marking
QoS applications. Although these may generate only a small fraction of Hosts may directly mark DS-fields in the packets transmitted
all traffic, servicing this traffic may comprise a significant frac- by QoS applications. Such marking may be based on host
tion of the revenues associated with QoS. In addition, while qualita- configuration or on local communication between QoS
tive QoS applications can be satisfied by conventional diff-serv applications and the host operating system.
alone, quantitative QoS applications require additional support.
4.2 Allotment of Diff-serv Service Levels to Specific Traffic Flows Int-serv Router Marking
Routers external to the diff-serv network may mark DS-fields
on behalf of QoS applications, based on MF classification.
The MF classifier might be dynamically configured by RSVP
signaling between QoS applications, or it might be controlled
statically by manual configuration or automated configuration
scripts.
It must be possible for QoS applications to invoke specific end-to-end MF classification is expected to be limited to examination of the
service levels for their traffic flows. Within the intserv regions of network and transport-layer (port) fields of a packet. An
the network quantitative QoS applications do so by using RSVP signal- advantage of host marking is that it allows marking to depend upon
ing to configure classifiers which operate on IP addresses and port application-specific information that cannot be deduced from MF
numbers. We will refer to such classifiers from here on as 'MF' clas- classification. For example, consider the need to give
sifiers [10]. preferential service to a website's home page (over other, less
important pages at the site) or the case of encrypted traffic
flows (IPSEC).
Within the diff-serv regions of the network, traffic is allotted ser- The information required to express useful mappings of application
vice based on the contents of the DS-field in packet headers. There- traffic flows to service levels is likely to be quite complex and
fore, it is necessary for QoS applications to effect the correct mark- to change frequently. Thus, manual configuration is likely to
ing of DS-fields before their packets are submitted to the diff-serv impose a significant management burden. If the configuration
network. (This is particularly true for quantitative QoS applications, information is very simple and does not change over time, the
less so for qualitative QoS applications that need not play as active management burden may be relatively minor; however, this means
a role in securing specific QoS from the network). There are two gen- that the granularity of allotting service levels to flows will be
eral mechanisms for doing so: sub-optimal. These considerations argue for host-based marking or
for dynamic configuration of a router's classifier/marker in
response to application requests.
1. Hosts may directly mark DS-fields in the transmitted packets of 2.3 Granularity of Allotment
QoS applications.
2. Routers external to the diff-serv network may mark DS-fields on
behalf of QoS applications based on MF classification.
In the first case, marking will be done based on host configuration or The term `granularity' is used here to refer to the degree of
local communication between QoS applications and the host operating specificity that is available in allotting a specific service
system. In the second case, marking will be done based on top-down level to a specific traffic flow. There are two measures of
configuration of the marking router's MF classifier/marker (by manual allotment granularity: granularity of packet classification and
configuration or via automated configuration scripts) or based on temporal granularity.
standard signaling between QoS applications and the marking router's
classifier/marker.
The following three requirements argue either for host based marking Fine grain classification might implement the following
or for dynamic configuration of a router's classifier/marker in requirement: "Telephony traffic from user X is allotted service
response to application requests. level A, while telephony traffic from user Y is allotted service
level B, and web traffic from any user is allotted service level
C." Coarse grain classification might be limited to something of
the form: "All traffic from subnet 1.0.0.0 receives service level
A, while all traffic from subnet 2.0.0.0 receives service level
B."
4.2.1 Minimal Management Burden Temporal granularity determines the frequency with which the
service allotted to a flow may change. A temporally fine grain
system would allow immediate changes in allotment of service
levels to traffic flows, with times of the order of seconds or
less. A temporally coarse-grained system might have service
levels set by static provisioning with time frames of days or
weeks.
Use Of RSVP with Diffserv June, 1998 2.4 Policing
The information required to express useful mappings of application It may be necessary to protect the network by policing at various
traffic flows to service levels is likely to be quite complex and to points, within the stub network and/or at the interface to the
change frequently. Thus, manual configuration is likely to impose a transit network. For example, within the stub network, first-hop
significant management burden. If the configuration information is routers may police the aggregate traffic coming from a host to
very simple and does not change over time, the management burden may ensure that the host is not exceeding its traffic limit.
be relatively minor. However, this means that the granularity of
allotting service levels to flows will be sub-optimal.
4.2.2 Granularity of Allotment It should be noted that some diff-serv PHBs (e.g., a "billing" PHB
[14]) may not require any policing at all at any point in the
network.
The term 'granularity' is used here to refer to the degree of specifi- 2.5 Admission Control
city that is available in allotting a specific service level to a
specific traffic flow. There are two measures of granularity; one is
the granularity with which an individual flow or a group of flows is
identified. The other is the frequency at which the service allotted
to a flow may change. A fine grain QoS system would allow the follow-
ing requirement to be expressed: telephony traffic from user X should
be allotted service level A, while telephony traffic from user Y
should be allotted service level B, and web traffic from any user
should be allotted service level C. A coarse grain system would be
limited to something of the form: all traffic from subnet 1.0.0.0
should receive service level A, while all traffic from subnet 2.0.0.0
should receive service level B. A temporally fine grain system would
allow immediate changes in allotment of service levels to traffic
flows. A temporally coarse grain system may allow infrequent changes
only.
4.2.3 Difficulties in Identification of Application Flows Under RSVP/int-serv, quantitative QoS applications use RSVP to
submit QoS requests to explicit admission control at each hop of
the end-to-end path. Integrated Services admission control (ISAC)
may be avoided only on hops that are known to be sufficiently
over-provisioned to satisfy the service requirements. When a
request is rejected, the host application may choose to try again
with a smaller request or to accept the best-effort service
available everywhere along the path, or it may simply avoid
sending traffic. These mechanisms protect traffic on flows that
were previously admitted.
Routers may not be able to readily identify specific application flows In diff-serv regions of the network, admission control may be
based on network and/or transport layer fields in a packet. provided implicitly by policing at ingress points, based on
provisioning. However, to support end-to-end tight QoS, explicit
admission control must be applied to the virtual hop represented
by the diff-serv transit network. An diff-serv service level used
by the int-serv traffic is provisioned for some maximum level of
traffic. The admission control function must ensure that this
limit is not exceeded by the total int-serv traffic submitted for
this class.
For example, consider the need to give preferential service to a 2.6 Policy Control
website's home page (over other, less important pages at the site) or
the case of encrypted traffic flows (IPSEC).
4.3 Admission Control QoS support provides preferential treatment to particular traffic
flows. As a result, admission control must be based on policy as
well as on resource availability.
Quantitative QoS applications use RSVP to request that their flows be In an int-serv network, resource-based admission control is
admitted to intserv regions of the network. When a request is handled by RSVP enabled routers (and SBMs [2]), and is typically
rejected, the host application may avoid sending traffic and/or inter- at the granularity of individual users. Policy based admission
mediate RSVP capable nodes will only give best-effort service to control is handled by RSVP-capable policy servers. These assure
traffic on flows that were not admitted. These mechanisms protect that int-serv network resources are allotted to users according to
traffic on flows that were admitted. policy specific to the int-serv network. In addition, policy
servers within the int-serv network must assure that appropriate
policy is applied when diff-serv resources are allotted to int-
serv users.
In diff-serv regions of the network, admission control is provided In a diff-serv network, resource and policy-based admission
implicitly, by policing at ingress points based on provisioning. The control are handled by entities such as bandwidth brokers. Policy
problem with implicit admission control is that it breaks the end-to- decisions made within the diff-serv network are likely to be at
the granularity of peer networks. In general, the diff-serv
network may make multiple service levels available to a single
peer int-serv network.
Use Of RSVP with Diffserv June, 1998 3. Description of Model
end validity of explicit admission control. Specifically, an applica- We envision an internet that consists of RSVP/int-serv capable stub
tion may gain admission using RSVP signaling, even though there is no networks interconnected by diff-serv capable transit networks. The
capacity for that application's traffic within the diff-serv region of simplest example of this model is a diff-serv capable transit network
the network. Neither the application, nor intermediate RSVP capable and two RSVP/int-serv capable stub networks, as shown in Figure 1.
nodes will be aware that the application's traffic is not admissible. The transit network contains a mesh of routers, at least some of
As a result, neither can take corrective action and all traffic from which are diff-serv capable. The stub networks contain meshes of
that customer, at the corresponding service level, may be compromised. routers, at least some of which are int-serv capable.
This failure may be partially, but not completely alleviated by polic-
ing based on MF classification at the diff-serv ingress (rather than
BA classification [10]).
End-to-end QoS requires that quantitative QoS applications and RSVP / Stub / Transit / Stub / Network / Network / Network | | | | | |
capable intserv nodes be explicitly informed of admission control |---| | |---| |---| |---| |---| | |---|
failure in the diff-serv network. This enables them to take corrective |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx |
action and to avoid overdriving the diff-serv network. If the service |---| | |-- | |---| |---| |---| | |---|
agreement between the intserv and diff-serv regions of the network is | | | | | |
statically provisioned, then admission control functionality can be RSVP/ / diff-serv / RSVP/ /
provided by static configuration of admission control in intserv edge int-serv/ / int-serv/
routers. However, if the service agreement is dynamically variable,
then it will be necessary to dynamically propagate current diff-serv
resource availability to the intserv network for the purpose of expli-
cit admission control.
4.4 Policy Support Figure 1: Sample Network Configuration
End-to-end QoS leads to preferential treatment of certain traffic In the interest of simplicity, Figure 1 shows a single QoS sender Tx
flows over others. Within diff-serv regions of the network, policy on one of the stub networks and a single QoS receiver Rx on the
applies on a per-customer basis. In general, the diff-serv network other. The edge routers (ER1, ER2) within the RSVP/int-serv networks
makes multiple service levels available to a single customer's intserv interface to the border routers (BR1, BR1) of the diff-serv network.
network. In this case the customer must apply policy within its net-
work to assure appropriate allocation of resources (customer network
resources as well as diff-serv network resources) to individual hosts
in the customer's network. This requires that end-to-end admission
control be based on policy as well as resource availability.
5. Intserv as a Customer of Diff-serv From an economic viewpoint, we may consider that the transit network
sells service to the stub networks, which in turn sell service to end
systems. Thus, we may think of the stub networks as customers of the
transit network. In the following, we use the term "customer" for
each of the stub networks in Figure 1.
To meet the above requirements, we envision a network that consists 3.1 Components of the Model
typically of relatively smaller, intserv capable stub networks, con-
nected by larger, diff-serv capable transit networks. In this sec-
tion, we will describe the operation of one instantiation of such a
network (see figure 1). The following assumptions apply:
5.1.1 Host Capabilities We now define the major components of the proposed model.
Both sending and receiving hosts use RSVP to communicate QoS require- 3.1.1 Hosts
ments of certain QoS aware applications running on the host. A QoS
process within the host operating system generates RSVP signaling on
Use Of RSVP with Diffserv June, 1998 Both sending and receiving hosts use RSVP to communicate the
quantitative QoS requirements of QoS-aware applications running
on the host. Typically, a QoS process within the host
operating system generates RSVP signaling on behalf of the
applications; this process may also invoke local traffic
control.
behalf of the applications. This process also invokes traffic control. Traffic control in the host may mark the DS-field in
Host traffic control includes marking the DS-field in transmitted transmitted packets, and it may shape transmitted traffic to
packets and shaping transmitted traffic per token bucket specifica- the requirements of the int-serv service in use.
tions. Note that host traffic control is assumed for this specific Alternatively, the first-hop router within the int-serv network
example, but is not a requirement of the framework in general. Leaf may provide these traffic control functions.
routers within the intserv network may provide the traffic control
functions.
5.1.2 Edge Routers 3.1.2 End-to-End RSVP Signaling
The edge routers are special routers that straddle the boundary We assume that RSVP signaling messages travel end-to-end
between the RSVP/Intserv region of the network and the diff-serv between hosts Tx and Rx to support int-serv reservations in the
region of the network. It is helpful to think of these routers as con- stub networks. We require that these end-to-end RSVP messages
sisting of two halves; the standard RSVP half, which interfaces to the be tunneled transparently across the diff-serv transit network.
stub networks, and the diff-serv half, which interfaces to the transit Mechanisms for this purpose are proposed in [8]; they do not
network. require the routers in the transit network to
understand/interpret RSVP messages and do not adversely impact
the transit network.
The RSVP half is at least partially RSVP capable; it is able to pro- 3.1.3 Edge Routers
cess PATH and RESV messages but it is not necessarily required to
store full RSVP state and it is not required to provide MF classifica-
tion.
The diff-serv half of the router provides the interface to the admis- We choose to place the boundary between the RSVP/int-serv
sion control function for the diff-serv network. We shall refer to region and the diff-serv region of the network within the edge
this function from here on as the 'DACS' (diff-serv admission control routers. It is helpful to think of an edge router as
service). The DACS is a process that is likely to (but is not required consisting of two halves: a standard RSVP half, which
to) run at least partially, on the routers. If the service agreement interfaces to a stub network, and a diff-serv half, which
between the stub networks and the transit networks is statically pro- interfaces to the transit network. The RSVP half has full RSVP
visioned then the DACS can be as simple as a table which specifies capability. It is able to do MF classification, if required,
capacity at each service level. If the service agreement is dynamic, and it is able to police traffic that will be passed to the
the DACS may communicate with counterparts within the diff-serv net- border router.
work (such as a bandwidth broker [4]) and may be able to make admis-
sion control decisions based on provisioned limits as well as the
topology and the capacity of the diff-serv network.
5.1.3 Boundary Routers The diff-serv half of the edge router provides an interface to
the diff-serv network's admission control function, which we
refer to as as `DSAC' (Diff-Serv Admission Control).
These are conventional boundary routers. In the example illustrated, The customer(s) (owner(s) of the stub networks) and the carrier
they are not required to run RSVP. They are expected to implement the owning the transit network will negotiate a contract for the
policing function of diff-serv ingress routers, based on the results capacity to be provided at each of a number of standard diff-
of a BA classifier. They are neither required to provide MF classifi- serv service levels. If the service agreement between the stub
cation nor must mark the DS-field (with the possible exception of dif- networks and the transit networks is statically provisioned,
ferential marking to indicate out of profile traffic [10, 8]). Note then the DSAC can be simply based upon a table that specifies
that this example places the boundary between the RSVP/Intserv network capacity at each service level. If the service agreement is
and the diff-serv network, within the edge routers at the stub net- dynamic, the DSAC may communicate with counterparts within the
works. In general, this boundary could be shifted to the left or to diff-serv network (such as a bandwidth broker [4]) in order to
the right. It could for example, be placed within the boundary routers make admission control decisions based on provisioned limits as
in the transit network. In this case, the DACS is implemented well as the topology and the capacity of the diff-serv network.
Use Of RSVP with Diffserv June, 1998 Since the individual int-serv flows are policed according to
int-serv rules within the stub network, the edge router needs
to shape only the aggregate stream, not the individual flows.
entirely within the diff-serv network (and is essentially, the 3.1.4 Border Routers
bandwidth broker proposed in [4]), but the diff-serv boundary routers
must be RSVP capable.
5.1.4 Stub Networks BR1 and BR2 are diff-serv capable border routers, and are not
required to run RSVP. They are expected to implement the
policing function of diff-serv ingress routers, based on the
results of a BA classifier. They are required neither to
provide MF classification nor to mark the DS-field (with the
possible exception of differential marking to indicate out-of-
profile traffic [10, 8]).
The stub networks consist of int-serv capable hosts and some number of 3.1.5 Stub Networks
leaf routers. Leaf routers within the stub networks may or may not be
int-serv capable. Since they are relatively small networks, it is rea-
sonable to assume that they are int-serv capable, but this is not
necessary. If they are not int-serv capable, we assume that they are
not capable of per-flow identification, signaling, and admission con-
trol and, in that case, will pass RSVP messages (requesting per-flow
QoS) unhindered.
5.1.5 Transit Network A stub network consists of int-serv capable hosts and some
number of routers. These routers may reasonably be assumed to
be RSVP/int-serv capable, although this might not be required
for a small over-provisioned stub network. If they are not
int-serv capable, we assume that they are not capable of per-
flow classification, signaling, or admission control and will
pass RSVP messages unhindered.
The transit network is not typically capable of per-flow identifica- 3.1.6 Transit Network
tion, signaling, and admission control. It provides two or more levels
of service based on the DS-field in the headers of carried packets
(diff-serv capable). Furthermore, the transit network is able to carry
RSVP messages transparently, with minimal or no impact on its perfor-
mance (see [8]). The transit network may include multiple carrier net-
works.
5.1.6 Carrier/Customer Agreement The transit network is not typically capable of per-flow
classification, signaling, and admission control. It provides
two or more levels of service based on the DS-field in the
headers of carried packets (diff-serv capable). Furthermore,
the transit network is able to carry RSVP messages
transparently, with minimal or no impact on its performance
(see [8]). The transit network may include multiple carrier
networks.
The customer (owner(s) of the leaf networks) and the carrier owning 3.1.7 Service Mapping
the transit network have negotiated a contract for the capacity to be
provided at each of a number of standard diff-serv service levels. The
capacity may be statically provisioned. In this case, the DACSs are
statically configured with the capacity available at each service
level and reside entirely within the edge routers. Alternatively, the
capacity may be dynamically variable with a pre-negotiated usage fee
and/or a pre-negotiated capacity limit. In this case, the DACS would
be required to communicate with counterparts within the diff-serv
transit network depending on the granularity of allotment (temporally
coarse or temporally fine grained).
5.1.7 Mapping from Intserv Service Type to DS-field RSVP signaling requests carry an int-serv service type and a
set of quantitative parameters known as a "flowspec"; these
describe the QoS expected from the int-serv regions of the
network. At each hop in an int-serv network, the generic int-
serv service requests are interpreted in a form meaningful to
the specific link layer medium. For example, at an ATM hop, a
VC of the correct type (CBR, ABR or VBR) is established [13].
At an 802.1 hop, the int-serv service type is mapped to an
appropriate 802.1p priority level [5].
In our proposal, we use RSVP signaling to provide admission control to In our model, the entire diff-serv network plays the role of a
specific service levels in the diff-serv, as well as the intserv net- single virtual link layer as far as RSVP/int-serv are
work. RSVP signaling requests carry an intserv service type, describ- concerned. Therefore, the int-serv service request must be
ing the type of service they expect from the intserv regions of the mapped to the DS-field when the packets enter the diff-serv
network. At each hop in an intserv network, the generic intserv ser- cloud. The requested int-serv service must be mapped to a
vice requests are interpreted in a form meaningful to the specific diff-serv service level that can reasonably extend the int-serv
media. For example, at an ATM hop, a VC of the correct type (CBR, ABR service type requested by the application. The edge router can
then provide admission control to the diff-serv network by
accepting or rejecting the request based on the capacity
available at the requested diff-serv service level.
Use Of RSVP with Diffserv June, 1998 One of two schemes may be used to map int-serv service types to
diff-serv service levels.
or VBR) is established [13]. At an 802.1 hop, the intserv service type Default
is mapped to an appropriate 802.1p priority level [5].
Similar mapping is necessary from Intserv Service type to DS-field. At In this scheme, there is some standard, well-known mapping
the boundary between the intserv network and a diff-serv network, it from int-serv service type to a PHB that will invoke the
is necessary for edge devices to map the requested intserv service to appropriate behavior in the diffserv network.
a diff-serv service level that can reasonably extend the intserv ser-
vice type requested by the application. The edge device can then pro-
vide admission control to the diff-serv network by accepting or
rejecting the request based on the capacity available at the requested
diff-serv service level.
We assume that one of two schemes is used to map intserv service types To improve the quality of the mapping, it may prove
to diff-serv service levels. In the first scheme (called "default map- necessary to add additional information to an int-serv QoS
ping"), we propose a standard, well-known mapping from intserv service request. For example, consider QoS requests for two
type to a PHB that will invoke the appropriate behavior in the diff- different flows, one interactive voice traffic and the
serv network. The mapping is not necessarily one-to-one. For example, other latency-tolerant traffic. They may both have the
controlled-load interactive voice traffic will likely map to a PHB same int-serv parameters (especially using the Controlled
having different latency characteristics than controlled-load latency Load service), but they are likely to map to different
tolerant traffic. For this reason we suggest adding a qualifier to the diff-serv services. For this reason, we suggest adding a
intserv service type indicating its relative latency tolerance (high qualifier to the int-serv service type indicating its
or low). The qualifier would be defined as a standard object in relative latency tolerance (high or low). The qualifier
intserv signaling messages. would be defined as a standard object in int-serv
signaling messages.
In an alternate scheme (called "customer-specified mapping"), we allow Customer-Specified
the devices at the edge of the diff-serv region of the network to
modify the well-known mapping. Under this approach, RESV messages ori-
ginating at hosts carry the usual intserv service type (with a qualif-
ier, as described above). When RESV messages arrive at the interface
of the int-serv and diff-serv regions (e.g. router ER1 in Figure 1,
where the traffic from the stub network enters the diff-serv region),
the edge device will determine the PHB that should be used to obtain
the corresponding diff-serv service level. This value is appended to
the RESV message by the edge device and is carried to the sending
host. When the RESV message arrives at the sending host, the sender
(or intermediate intserv routers) will mark outgoing packets with the
indicated PHBs.
The decision to modify the well-known mapping at the edge devices will In this scheme, the edge routers in the customer (stub)
be based on edge-device configuration and/or policy decision at the networks are allowed to modify the service mapping. RESV
edges. For example, when a reservation arrives at the edge of diff- messages originating at hosts will carry the usual int-
serv network and if enough reservations have already been accepted to serv service type (perhaps with a qualifier, as described
reach the pre-negotiated capacity limit at the corresponding service above). When a RESV message arrives at the edge router
level, the device may decide to use a PHB corresponding to a different from which the traffic enters the diff-serv region (e.g.,
(less assured?) service level based on an administratively set policy. router ER1 in Figure 1), the edge router determines the
PHB code point that should be used to obtain the
corresponding diff-serv service level. This information
is appended to the RESV message by ER1 and carried to the
sending host. When the RESV message arrives at the
sending host, the sender (or intermediate int-serv
routers) start marking outgoing packets with the indicated
PHB code point.
5.2 How End-to-End QoS is Obtained A decision to override the well-known service mapping at the
edge router may be based on configuration and/or a policy
decision. For example, when a reservation request arrives at
the ingress to a diff-serv network, if accepted reservations
have already reached the pre-negotiated capacity limit at the
corresponding service level then the edge router may decide to
use a PHB corresponding to a different service level, based on
an administratively-set policy.
Use Of RSVP with Diffserv June, 1998 3.2 Example: Obtaining End-to-End QoS
The following sequence illustrates the process by which an application The following sequence illustrates the process by which an
obtains end-to-end QoS: application obtains end-to-end QoS.
1. The sending host's QoS process generates an RSVP PATH message, 1. The QoS process on the sending host Tx generates an RSVP PATH
describing the traffic offered by the sending application. message that describes the traffic offered by the sending
application.
2. The PATH message is carried toward the receiving host. In the 2. The PATH message is carried toward the receiving host Rx. In
sending stub network, standard RSVP processing will be applied at the sender's stub network, standard RSVP processing is
RSVP capable nodes (routers, SBMs, etc). applied at RSVP capable nodes (routers, SBMs, etc).
3. At ER1, the PATH message is subjected to standard RSVP processing 3. At the edge router ER1, the PATH message is subjected to
and PATH state is installed in the router. The PATH message is sent standard RSVP processing and PATH state is installed in the
onward, to the transit network. router. The PATH message is sent onward, to the transit
network.
4. The PATH message is carried transparently through the transit 4. The PATH message is carried transparently through the transit
network. It is processed in the receiving stub network according to network, and then processed in stub router ER2 according to
standard RSVP processing rules. standard RSVP processing rules.
5. At the receiving host, the QoS process generates an RSVP RESV 5. When the PATH message reaches the receiving host Rx, its QoS
message, indicating interest in the offered traffic, at a certain process generates an RSVP RESV message, indicating interest
intserv service level. in the offered traffic at a certain int-serv service level.
6. The RESV message is carried back towards the sending host. 6. The RESV message is carried back towards the sending host.
Consistent with standard RSVP processing, it may be rejected at any Consistent with standard RSVP processing, it may be rejected
RSVP node in the receiving stub network if resources are deemed at any RSVP node in the receiver's stub network if resources
insufficient to carry the traffic requested. are deemed insufficient to carry the traffic requested.
7. At ER2, the RESV message is subjected to standard RSVP 7. At ER2, the RESV message is subjected to standard RSVP
processing. It may be rejected if resources on the downstream processing. It may be rejected if resources on the
interface of ER2 are deemed insufficient to carry the resources downstream interface of ER2 are deemed insufficient to carry
requested. If it is not rejected, it will be carried transparently the resources requested. If it is not rejected, it will be
through the transit network, arriving at ER1. carried transparently through the transit network, arriving
at ER1.
8. At this point, the RESV message triggers DACS processing. The
DACS compares the resources requested to the resources available at
the corresponding diff-serv service level, in the diff-serv enabled
transit network. If the RESV message is admitted, the DACS updates
the available capacity for the service class, by subtracting the
approved resources from the available capacity.
9. Assuming the available capacity is sufficient, the RESV message 8. In ER1, the RESV message triggers DSAC processing. The DSAC
is admitted and is allowed to continue upstream towards the sending compares the resources requested to the resources available
host. If the available capacity is insufficient, the RESV message at the corresponding diff-serv service level, in the diff-
will be rejected and the available capacity for the service class serv enabled transit network. If the RESV message is
will remain unchanged. admitted, the DSAC updates the available capacity for the
service class, by subtracting the approved resources from the
available capacity.
10. The RESV message proceeds through the sending stub network. RSVP 9. Assuming the available capacity is sufficient, the RESV
nodes in the sending stub network may reject it. If it is not message is admitted and is allowed to continue upstream
towards the sending host. If the available capacity is
insufficient, the RESV message is rejected and the available
capacity for the service class remains unchanged.
Use Of RSVP with Diffserv June, 1998 10. The RESV message proceeds through the sender's stub network.
RSVP nodes in the sending stub network may reject it. If it
is not rejected, it will arrive at the sender host Tx.
rejected, it will arrive at the sending host. 11. At Tx, the QoS process receives the RESV message. It
interprets receipt of the message as an indication that the
specified traffic has been admitted for the specified int-
serv service type (in the RSVP enabled regions of the
network) and for the corresponding diff-serv service level
(in the diff-serv enabled regions of the network).
11. At the sending host, the QoS process receives the RESV message. Tx begins to set the DS-field in the headers of transmitted
It interprets receipt of the message as an indication that the packets to the value which maps to the Intserv service type
specified traffic has been admitted for the specified intserv specified in the admitted RESV message.
service type (in the RSVP enabled regions of the network) and for
the corresponding diff-serv service level (in the diff-serv enabled
regions of the network). It begins to set the DS-field in the headers
of transmitted packets, to the value which maps to the Intserv
service type specified in the admitted RESV message.
In this manner, we are able to obtain end to end QoS through a combi- In this manner, we obtain end-to-end QoS through a combination of
nation of networks that support RSVP style reservations and networks networks that support RSVP style reservations and networks that
that support diff-serv style prioritization. The successful arrival of support diff-serv style prioritization. The successful arrival of
RESV messages at the original sender indicates that admission control RESV messages at the original sender indicates that admission
has succeeded both in the RSVP regions of the network and in the control has succeeded both in the RSVP regions of the network and
diff-serv regions of the network. in the diff-serv regions of the network.
5.3 Variations of the Model 3.3 Variations of the Model
It is useful to consider a number of variations of the model It is useful to consider some variations of the model just
presented. presented.
5.3.1 Admission Control 3.3.1 Moving the Boundary
5.3.1.1 Statically Provisioned Service Agreements
In the simplest model, service agreements are negotiated statically
between the stub networks and the transit networks. A service agree-
ment consists of a table of capacities available to a customer's stub
network, at each diff-serv service level. In this case, DACS func-
tionality is provided at the edge routers in the stub networks. The
'diff-serv half' of these routers appear to the 'RSVP half' as a send-
ing interface with resource limits defined by the service agreement
table. While there may be bandwidth brokers and dynamic provisioning
within the transit networks, these are not coupled with the intserv
stub networks and admission control in the two regions of the network
is completely independent.
5.3.1.2 Dynamic Service Agreements
In a more sophisticated model, service agreements between customer We have assumed that the boundary between the RSVP/int-serv
stub networks and carrier transit networks are more dynamic. Customers network and the diff-serv network lies in the edge routers.
may be able to dynamically request changes to the service agreement. Alternative models could shift this boundary to the left or to
In this case, a statically provisioned edge router cannot provide the the right in Figure 1. It could for example, be placed within
required DACS functionality. Instead, DACS functionality must be pro- the border routers in the transit network. In this case, the
vided by coupling the stub network's admission control with the DSAC would be implemented entirely within the diff-serv network
(and would essentially be the bandwidth broker proposed in
[4]); however, it would require that the diff-serv border
routers be RSVP capable.
Use Of RSVP with Diffserv June, 1998 Alternative, the boundary could be shifted all the way to the
end hosts. This would mean that the traffic was using diff-
serv mechanisms in the stub networks as well as the transit
network, while the int-serv mechanisms would be only in the
host. The QoS-aware application could still use RSVP within
the lost to signal its needs. The host would implement per-
flow policing, the DSAC function, and packet marking.
transit network's admission control. 3.3.2 Service Agreements
The two admission control mechanisms meet at the boundary between the o Statically-Provisioned Service Agreements
diff-serv network and the intserv network. This boundary may be imple-
mented at the edge router (in the stub network), at the boundary
router (in the transit network), or at the bandwidth broker for the
intserv network.
5.3.1.3 Limiting the Impact of Intserv Admission Control on the Diff- In the simplest model, service agreements are negotiated
serv Network statically between stub networks and transit networks. A
service agreement consists of a table of capacities
available to a stub network, at each diff-serv service
level. In this case, DSAC functionality is provided at
the edge routers in the stub networks. The `diff-serv
half' of these routers appear to the `RSVP half' as a
sending interface with resource limits defined by the
service agreement table. While there may be bandwidth
brokers and dynamic provisioning within the transit
networks, these are not coupled with the int-serv stub
networks, and admission control in the two regions of the
network is completely independent.
Note that coupling intserv and diff-serv admission control does not o Dynamic Service Agreements
imply that each intserv admission control request results in diff-serv
admission control work. Instead, intserv admission control requests
are aggregated at the boundary between the intserv and the diff-serv
network. For example, intserv admission control requests may trigger
diff-serv admission control requests to bandwidth brokers only when
some high-water or low-water resource threshold is crossed. Separate
high-water and low-water thresholds provide hysteresis to prevent
thrashing.
5.3.1.4 Roles of Policy and Resource Based Admission Control In a more sophisticated model, service agreements between
customer stub networks and carrier transit networks are
more dynamic. Customers may be able to dynamically
request changes to the service agreement. In this case, a
statically provisioned edge router cannot provide the
required DSAC functionality. Instead, DSAC functionality
must be provided by coupling the stub network's admission
control with the transit network's admission control.
It is necessary to provide both resource and policy based admission The two admission control mechanisms meet at the boundary
control in the diff-serv network as well as the intserv network. In between the diff-serv network and the int-serv network.
the diff-serv network, resource and policy based admission control are This boundary may be implemented at the edge router (in
handled by entities such as bandwidth brokers and reflected to the the stub network), at the border router (in the transit
intserv network as DACS (or RSVP). Policy decisions made within the network), or at the bandwidth broker for the int-serv
diff-serv network are likely to be at the per-intserv network (per- network.
customer of the diff-serv network) granularity.
In the intserv network, resource based admission control is handled by Note that coupling int-serv and diff-serv admission
RSVP enabled routers (and SBMs [2]). Policy based admission control is control does not imply that each int-serv admission
handled by RSVP capable policy servers. These assure that intserv control request will result in DSAC processing. Int-serv
resources are allotted to intserv customers according to policy admission control requests may be aggregated at the
specific to the intserv network. In addition, policy servers within boundary between the int-serv and the diff-serv network.
the intserv network must also assure that appropriate policy is For example, int-serv admission control requests may
applied when diff-serv resources are allotted to intserv customers. trigger DSAC requests to bandwidth brokers only when some
high-water or low-water resource threshold is crossed.
Separate high-water and low-water thresholds can provide
hysteresis to prevent thrashing.
5.3.2 Setting the DS-field at Intermediate Nodes %.cm In the latter case, any MF classification on %.cm behalf
of the diff-serv ingress point is provided as a service to the
%.cm customer and goes beyond policing requirements).
In the example described, hosts use RSVP signaling and mark the DS- 3.3.3 Setting the DS-field
byte corresponding to the admitted service level. Note that these
functions can be separated. In the example, the function of RSVP sig-
naling is to invoke QoS in the intserv network and to provide end-to-
end admission control. The function of marking the DS-field is to
reduce the need for MF classification at routers. (MF classification
is required at the ingress to a diff-serv network only to determine
Use Of RSVP with Diffserv June, 1998 Allowing hosts to set the DS-field directly may alarm network
administrators. The obvious concern is that hosts may attempt
to 'steal' resources. In fact, hosts may attempt to exceed the
negotiated capacity at a particular service level regardless of
whether they invoke this service level directly (by setting the
DS-byte) or indirectly (by submitting traffic that classifies
in an intermediate router to a particular diff-serv PHB).
the customer to whom the traffic belongs. If an interface is dedicated In summary, the security concerns of marking the DS-field at
to the customer, no MF classification need be done. In this case, any the edge of the network can be dismissed since each carrier
MF classification on behalf of the diff-serv ingress point is provided will have to do some form of policing (per-flow or per-host) at
as a service to the customer and goes beyond policing requirements). their boundary anyway. Furthermore, this approach reduces the
granularity at which border routers must police, thereby
pushing finer grain shaping and policing responsibility to the
edges of the network, where it scales better. The carriers are
thus focused on the task of protecting their transit networks,
while the customers are focused on the task of shaping and
policing their own traffic to be in compliance with their
negotiated token bucket parameters.
It is possible to mark the DS-field at intermediate routers rather It is also possible to mark the DS-field at intermediate
than at the host and still to realize many of the benefits of our routers rather than at the host and still realize many of the
approach. In this case, intermediate routers may use the RSVP signal- benefits of our approach. In this case, intermediate routers
ing to configure an MF classifier and marker. Therefore, the confi- may use the RSVP signaling to configure an MF classifier and
guration of MF classifiers and markers is dynamic (minimizing the marker. Then the configuration of MF classifiers and markers
management burden) and full resource and policy based admission con- would be dynamic (minimizing the management burden), and full
trol can be applied. resource- and policy-based admission control could be applied.
The disadvantages of marking the DS-field at intermediate routers The disadvantages of marking the DS-field at intermediate
(instead of the host) are that full MF classifiers are required at the routers (instead of the host) are that full MF classifiers are
intermediate nodes and that responsibility for traffic separation is required at the intermediate nodes and that responsibility for
shifted away from the host. traffic separation is shifted away from the host.
Nonetheless, this approach is necessary to support those hosts which Nonetheless, marking at intermediate routers will be necessary
may be capable of RSVP signaling, but which are not capable of marking to support those hosts which support RSVP signaling but are
the DS-field. In addition, there may be cases in which the network incapable of marking the DS-field. In addition, there may be
administrators wish to shift the responsibility for traffic separation cases in which the network administrators wish to shift the
away from the hosts. In particular, we expect that there will continue responsibility for traffic separation away from the hosts. In
to be a need for top-down provisioned MF classification, especially particular, we expect that there will continue to be a need for
for qualitative (as opposed to quantitative) QoS applications. top-down provisioned MF classification, especially for
qualitative (as opposed to quantitative) QoS applications. See
Section 5.2.
6. Managing Different Resource Pools 4. Implications for Diff-Serv
We have focused largely on the class of applications that use RSVP to We have described a framework for end-to-end QoS in which a diff-serv
explicitly signal per-flow QoS requirements and which expect end-to- network can be included as a segment of an int-serv path. This
end tight QoS assurances, spanning both the intserv and diff-serv section discusses some of the implications of this framework for
regions of the network. We have been referring to these applications diff-serv.
as 'quantitative QoS applications'.
However, diff-serv networks also provide loose QoS to applications 4.1 Requirements for Diff-Serv
that do not explicitly signal. Network managers can allot qualitative
QoS applications specific QoS in the diff-serv network. This is
achieved by configuring classifiers at the ingress to the diff-serv
network to recognize traffic from these applications. Thus, the clas-
sification fields are used as a form of implicit signaling.
Network administrators must therefore share diff-serv network In order to use a diff-serv network as described in this draft,
resources between three types of traffic: the diff-serv network must satisfy the following requirements.
a. Quantitative (explicitly signaled) QoS application traffic 1. A diff-serv network must be able to provide standard QoS
b. Qualitative (implicitly signaled) QoS application traffic services between its border routers, and such a service must
c. All other (best-effort) traffic be selectable by specifying a standard code in a (PHB) sub-
field of the DS-field of a packet.
Use Of RSVP with Diffserv June, 1998 2. There must be appropriate service mappings from int-serv
services into these diff-serv services.
Quantitative QoS applications rely on explicit admission control for 3. Diff-serv networks must provide admission control information
their traffic, at the edges of the diff-serv network. This traffic may to the int-serv network. This information can be provided by
be refused admission for a particular diff-serv service level. However a dynamic protocol or, at the very least, through static
- if admitted, the traffic is assured tight QoS. Of course, this is service level agreements.
true only to the extent that, at any ingress point, the total offered
traffic at each service level does not exceed the resources requested
through the sum of admission control requests.
Traffic from qualitative QoS applications is provided with implicit 4. Diff-serv networks must be able to transparently carry RSVP
admission control as a result of policing at ingress points. However, messages, in such a manner that they can be recovered at the
implicit admission control does not provide explicit feedback to egress point from the diff-serv network.
applications. Therefore, it is difficult to assure that the total
traffic offered at an ingress point will not exceed the provisioned
capacity for a particular service level. When the traffic exceeds the
allowed limit, the feedback to the applications is indirect in the
form of packet loss or through an ECN CE mark at the bottleneck.
Thus, traffic from qualitative applications is offered only loose QoS.
From the network manager's perspective, there are three pools of 4.2 End-to-End Integrity of the DS-field
resources in the diff-serv network; one for traffic sourced by quanti-
tative QoS applications, one for traffic sourced by qualitative QoS
applications and one for best-effort traffic. These pools must be iso-
lated from each other by the appropriate configuration of policers and
classifiers at ingress points to the diff-serv network, and by
appropriate provisioning within the diff-serv network. To provide pro-
tection for quantitative QoS traffic in diff-serv regions of the net-
work we suggest that the DS codepoints allotted to such traffic must
not overlap the codepoints assigned to other traffic (qualitative QoS
and best-effort traffic).
7. Issues Our model assumes that int-serv networks uses a code point of the
DS-field in order to specify the desired PHB within the transit
network. It also assumes that packets submitted to the transit
network specifying a certain DS-field will receive a standard
service throughout the transit network. Strictly speaking, this
does not dictate that the transit network must leave the DS-field
field intact. For example, the border router may map a DS-field
value set by the host or edge router to a different value before
forwarding the data packets.
7.1 Setting the DS-field at Hosts However, we see little value in allowing the PHB field to be
altered within the network. This is likely to perpetuate local
and incompatible interpretations of the field.
The thought of allowing hosts to set the DS-field directly, may alarm 4.3 Policing and Shaping
network administrators. The obvious concern is that hosts may attempt
to 'steal' resources. In fact, hosts may attempt to exceed the nego-
tiated capacity at a particular service level regardless of whether
they invoke this service level directly (by setting the DS-byte) or
indirectly (by submitting traffic that classifies in an intermediate
router to a particular diff-serv PHB).
In either case, it may sometimes be necessary to protect the network We are assuming that border routers will police in aggregate. As
by policing at various points, both within the stub network and/or at a result, the customer cannot rely on border routers to provide
the interface to the transit network. For example, within the stub traffic isolation between the customer's flows, when policing or
network, routers may police the aggregate traffic coming from a host shaping. Instead, it is the customer's responsibility to ensure
to ensure that the host is not exceeding its traffic limit. This that the customer's flows are properly shaped and policed within
assures protection against malicious users or malfunctioning equipment the customer's sending network. Overall, this approach simplifies
border routers and still allows protection against misbehaving
hosts/users.
Use Of RSVP with Diffserv June, 1998 Ideally, hosts should provide per-flow shaping at their sending
interfaces. However, there is always a chance that the customer's
traffic will become distorted as it nears the boundary between the
customer and the carrier. In this case, the customer should do
per flow policing (or even re-shaping) at the egress point from
the customer's network unless the policing agreement at the other
side is known to accommodate the transient bursts that can arise
from adding the flows.
and, overall, ensures that customers do not use more resources than 4.4 Managing Resource Pools
they are entitled to, at each service level. If the sending host does
not do the marking, intermediate and/or boundary routers must provide
MF classification, mark and police. If the sending host does do the
marking, these routers need only to provide BA classification and to
police the aggregate to ensure that the customer is not exceeding the
aggregate capacity negotiated for the service level. It should, how-
ever, be noted that some PHBs (e.g., a "billing" PHB [14]) may not
require any policing at all at any point in the network.
Requiring hosts to mark the DS-field has the effect of moving respon- Network administrators must be able to share diff-serv network
sibility to the edge of the network, in more ways than one. With this resources between three types of traffic:
approach, boundary routers police in aggregate. As a result, the cus-
tomer cannot rely on boundary routers to provide traffic isolation
between the customer's flows, when policing or shaping. Instead, it
is the customer's responsibility to ensure that the customer's flows
are properly shaped and policed within the customer's sending network.
Overall, this approach simplifies boundary routers and still allows
protection against misbehaving hosts/users.
Ideally, hosts should provide per-flow shaping at their sending inter- a. Quantitative (explicitly signaled) QoS application traffic
faces. However, there is always a chance that the customer's traffic
will become distorted as it nears the boundary between the customer
and the carrier. In this case, the customer should do per flow polic-
ing (or even re-shaping) at the egress point from the customer's net-
work unless the policing agreement at the other side is known to
accommodate the transient bursts that can arise from adding the flows.
In summary, the security concerns of marking the DS-field at the edge b. Qualitative (implicitly signaled) QoS application traffic
of the network can be dismissed since each carrier will have to do
some form of policing (per-flow or per-host) at their boundary anyway.
Furthermore, this approach reduces the granularity at which boundary
routers must police, thereby pushing finer grain shaping and policing
responsibility to the edges of the network, where it scales better.
The carriers are thus focused on the task of protecting their transit
networks, while the customers are focused on the task of shaping and
policing their own traffic to be in compliance with their negotiated
token bucket parameters.
7.2 End-to-End Integrity of the DS-field c. All other (best-effort) traffic
Our proposal assumes that hosts use a standard coding for specifying a These pools must be isolated from each other by the appropriate
desired PHB in some sub-field of the DS-field. It also assumes that configuration of policers and classifiers at ingress points to the
packets submitted to the network with a certain PHB specified, will diff-serv network, and by appropriate provisioning within the
receive a standard service throughout the diff-serv network. Strictly diff-serv network. To provide protection for quantitative QoS
speaking, this does not dictate that the transit network must leave traffic in diff-serv regions of the network, we suggest that the
the PHB field intact. For example, after a sending host marks the DS codepoints allotted to such traffic must not overlap the
codepoints assigned to other traffic (qualitative QoS and best-
effort traffic).
Use Of RSVP with Diffserv June, 1998 5. Other Models
packets with PHB value based on either the well-known, "default" or 5.1 RSVP and Diff-Serv
"customer-specified" mapping, the boundary router may re-map it to a
different value before forwarding the data packets. However, we see
little value in allowing the PHB field to be altered within the net-
work. This is likely to perpetuate local and incompatible interpreta-
tions of the field.
7.3 Carrying RSVP Messages across Transit Networks Since RSVP was originally designed to support int-serv, we use the
term "RVSP/int-serv" as the complement to diff-serv. However,
RSVP and int-serv are separable, and RSVP may be used as a
general-purpose QoS signaling protocol. For example, RSVP might
be used for dynamic provisioning and admission control in the
diff-serv region of the network. Routers in the diff-serv region
would continue use the DS-field in the IP header to identify and
offer services to flow aggregates.
Our proposal presumes end-to-end RSVP both as a means for communica- 5.2 Qualitative QoS
tion between sending host and receiving host and optionally, for the
support of true RSVP reservations in stub networks (or in intermediate
networks which are interested in the fine grain RSVP information).
Therefore, we require that RSVP messages be carried transparently
across the transit networks. In [8], mechanisms are proposed for doing
so in a manner that does not require the routers in the transit net-
work to understand/interpret RSVP messages and does not adversely
impact the transit network.
8. Dependencies of Intserv on Diff-Serv This document has focused largely on the class of applications
that use RSVP to explicitly signal per-flow QoS requirements and
that expect end-to-end tight QoS assurances. We have been
referring to these applications as `quantitative QoS
applications'. Suitable end-to-end services must also be
available to qualitative QoS applications. The services that
these applications require are generally less demanding.
We have described a framework for end-to-end QoS in which intserv net- Qualitative services can be obtained from the diff-serv regions of
works are customers of diff-serv networks. We believe that the bene- the network with loose top-down provisioning. Network managers
fits of this framework are sufficient to justify the consideration of can configure classifiers at the ingress to the diff-serv network
intserv dependencies as diff-serv work proceeds. In particular, we to recognize traffic requiring specific qualitative service
wish to draw attention to the following dependencies: levels. Thus, these classification fields are used as a form of
implicit signaling. In the int-serv portion of the network,
qualitative QoS applications can get best-effort service, which
may be good enough.
1. We expect that we can invoke a standard end-to-end (within the There would be no explicit admission control for such qualitative
diff-serv network) service by specifying a standard code in a (PHB) QoS applications. Therefore, it is difficult to assure that the
sub-field of the DS-field of a packet launched into a diff-serv total traffic offered at an ingress point will not exceed the
network. provisioned capacity for a particular service level. When the
traffic exceeds the allowed limit, there is only indirect feedback
to the applications, in the form of packet loss or an Congestion
Experienced mark from Explicit Congestion Notification (ECN).
Thus, traffic from qualitative applications can be offered only
loose QoS.
2. Diff-serv networks must provide admission control information to 5.3 Multicasting
the intserv network. At the very least, this is through static
service level agreements. Preferably, this is through a dynamic
protocol. If the intserv to diff-serv boundary is implemented in the
transit network boundary routers, then this protocol is RSVP.
3. We expect that diff-serv networks will transparently carry RSVP messages <To be written>
such that they can be recovered at the egress point from the diff-serv
network.
9. Security Considerations 6. Security Considerations
We are proposing that RSVP signaling be used to obtain resources in We are proposing that RSVP signaling be used to obtain resources in
both the diff-serv and intserv regions of the network. Therefore, all both the diff-serv and int-serv regions of the network. Therefore,
RSVP security considerations apply [11]. In addition, network all RSVP security considerations apply [11]. In addition, network
administrators are expected to protect network resources by
configuring secure policers at interfaces with untrusted customers.
Use Of RSVP with Diffserv June, 1998 7. Acknowledgments
administrators are expected to protect network resources by configur- Authors thank the following individuals for their comments that led
ing secure policers at interfaces with untrusted customers. to improvements to the previous version(s) of this draft: David Oran,
Andy Veitch, Curtis Villamizer, Walter Weiss, and Russel white.
10. References Many of the ideas in this document have been previously discussed in
the original int-serv architecture document [12].
8. References
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S.,
"Resource Reservation Protocol (RSVP) Version 1 Functional "Resource Reservation Protocol (RSVP) Version 1 Functional
Specification", RFC 2205, Proposed Standard, September 1997 Specification", RFC 2205, Proposed Standard, September 1997
[2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M., [2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M.,
"SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based Admission "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based Admission
[3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated [3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated
Services State", Internet Draft, December 1997. Services State", Internet Draft, December 1997.
skipping to change at page 19, line 34 skipping to change at page 18, line 46
[5] Seaman, M., Smith, A. and Crawley, E., "Integrated Services Over [5] Seaman, M., Smith, A. and Crawley, E., "Integrated Services Over
[6] Elleson, E. and Blake, S., "A Proposal for the Format and [6] Elleson, E. and Blake, S., "A Proposal for the Format and
Semantics of the TOS Byte and Traffic Class Byte in Ipv4 and Ipv6 Semantics of the TOS Byte and Traffic Class Byte in Ipv4 and Ipv6
Headers", Internet Draft, November 1997 Headers", Internet Draft, November 1997
[7] Ferguson, P., "Simple Differential Services: IP TOS and [7] Ferguson, P., "Simple Differential Services: IP TOS and
Precedence, Delay Indication, and Drop Preference", Internet Draft, Precedence, Delay Indication, and Drop Preference", Internet Draft,
November 1997 November 1997
[8] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based [8] Guerin, R., Blake, S. and Herzog, S.,"Aggregating RSVP based QoS
QoS Requests", Internet Draft, November 1997 Requests", Internet Draft, November 1997.
[9] Clark, D. and Wroclawski, J., "An Approach to Service [9] Nichols, Kathleen, et al., "Definition of the Differentiated
[10] Blake, S. and Nichols, K., "Differentiated Services Operational Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
Model and Definitions", Internet Draft, February 1998 December 1998.
[10] Blake, S., et al., "An Architecture for Differentiated
Services." RFC 2475, December 1998.
[11] Baker, F., "RSVP Cryptographic Authentication", Internet Draft, [11] Baker, F., "RSVP Cryptographic Authentication", Internet Draft,
August 1997 August 1997
[12] Braden, R., Clark, D. and Shenker, S., "Integrated Services in [12] Braden, R., Clark, D. and Shenker, S., "Integrated Services in
the Internet Architecture: an Overview", Internet RFC 1633, June [13] Garrett, M. W., and Borden, M., "Interoperation of Controlled-
1994 Load Service and Guaranteed Service with ATM", RFC2381, August 1998.
[13] Garrett, M. W., and Borden, M., "Interoperation of Controlled-Load [14] Weiss, Walter, Private communication, November 1998.
Use Of RSVP with Diffserv June, 1998 [15] Berson, S. and Vincent, S., "Aggregation of Internet Integrated
[14] Weiss, Walter, "private communication", November 1998. Services State", Internet Draft, August 1998.
11. Acknowledgments APPENDIX A. Terminology
Authors thank the following individuals for their comments that led to The following terms were used in this draft.
improvements to the previous version(s) of this draft: David Oran,
Andy Veitch, Curtis Villamizer, Walter Weiss, and Russel white.
12. Author's Addresses Int-serv
The part of an internet that uses per-flow classification,
signaling, and admission control to deliver per-flow QoS
guarantee.
[Diff-serv region (or diff-serv capable network)] The part of an
internet that provides aggregate QoS services
Quantitative
Application for which QoS requirements are readily quantifiable,
and which relies on these QoS requirements to function properly.
Qualitative
Applications for which relative, but not readily quantifiable,
QoS requirements exist.
QoS Application that requires some form of QoS, either qualitative
or quantitative.
LooseQoS assurances that are relative, rather than absolute, or
generally not quantifiable.
TightQoS assurances which are quantifiable, though they may or may
not provide 100% guarantee.
Top-down
Traditional provisioning methods that configure network
capacities using heuristics and experience, typically from a
console, based upon traffic predictions.
Author's Addresses
Yoram Bernet Yoram Bernet
Microsoft Microsoft
One Microsoft Way, One Microsoft Way,
Redmond, WA 98052 Redmond, WA 98052
Phone: (425) 936-9568 Phone: (425) 936-9568
Email: yoramb@microsoft.com Email: yoramb@microsoft.com
Raj Yavatkar Raj Yavatkar
Intel Corporation, JF3-206 Intel Corporation, JF3-206
skipping to change at page 21, line 5 skipping to change at page 21, line 42
Phone: (408) 526-4257 Phone: (408) 526-4257
Email: fred@cisco.com Email: fred@cisco.com
Lixia Zhang Lixia Zhang
UCLA UCLA
4531G Boelter Hall 4531G Boelter Hall
Los Angeles, CA 90095 Los Angeles, CA 90095
Phone: +1 310-825-2695 Phone: +1 310-825-2695
Email: lixia@cs.ucla.edu Email: lixia@cs.ucla.edu
Use Of RSVP with Diffserv June, 1998
Kathleen Nichols Kathleen Nichols
Cisco Systems Cisco Systems
Email: kmn@cisco.com Email: kmn@cisco.com
Michael Speer Michael Speer
Sun Microsystems, Inc Sun Microsystems, Inc
901 San Antonio Road UMPK15-215 901 San Antonio Road UMPK15-215
Palo Alto, CA 94303 Palo Alto, CA 94303
phone: +1 650-786-6368 phone: +1 650-786-6368
Email: speer@Eng.Sun.COM Email: speer@Eng.Sun.COM
Bob Braden
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
phone: 310-822-1511
Email: braden@isi.edu
 End of changes. 163 change blocks. 
758 lines changed or deleted 711 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/