draft-ietf-diffserv-rsvp-00.txt   draft-ietf-diffserv-rsvp-01.txt 
Internet Engineering Task Force Y.Bernet, Microsoft Internet Engineering Task Force Y.Bernet, Microsoft
Internet Draft R. Yavatkar, Intel Internet Draft R. Yavatkar, Intel
draft-ietf-diffserv-rsvp-00.txt P. Ford, Microsoft draft-ietf-diffserv-rsvp-01.txt P. Ford, Microsoft
F. Baker, Cisco F. Baker, Cisco
L. Zhang, UCLA L. Zhang, UCLA
K. Nichols, Bay Networks K. Nichols, Cisco Systems
M. Speer, Sun Microsystems M. Speer, Sun Microsystems
June, 1998 November, 1998
A Framework for Use of RSVP with Diff-serv Networks A Framework for Use of RSVP with Diff-serv Networks
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working documents of This document is an Internet Draft. Internet Drafts are working documents of
the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. the Internet Engineering Task Force (IETF), its Areas, and its Working Groups.
Note that other groups may also distribute working documents as Internet Note that other groups may also distribute working documents as Internet
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 37
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast). (US West Coast).
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 an Informational RFC for the Internet Community. RFC editor as an Informational RFC for the Internet Community.
Discussion and suggestions for improvement are requested. This Discussion and suggestions for improvement are requested. This
document will expire before December, 1998. Distribution of this document will expire before May 1999. Distribution of this
draft is unlimited. draft is unlimited.
Use Of RSVP with Diffserv June, 1998 Use Of RSVP with Diffserv June, 1998
1. Abstract 1. Abstract
In the past several years, work on QoS enabled networks led to the In the past several years, work on QoS enabled networks led to the
development of the Integrated Services (Intserv) architecture [12] and development of the Integrated Services (Intserv) architecture [12] and
the RSVP signaling protocol [1]. RSVP, as specified, enables applica- the RSVP signaling protocol [1]. RSVP, as specified, enables applica-
tions to signal per-flow requirements to the network. Intserv parame- tions to signal per-flow requirements to the network. Intserv parame-
skipping to change at page 2, line 36 skipping to change at page 2, line 36
At present, the market is pushing for immediate deployment of a QoS At present, the market is pushing for immediate deployment of a QoS
solution that addresses the needs of the Internet as well as enter- solution that addresses the needs of the Internet as well as enter-
prise networks. This push has led to the development of Differentiated prise networks. This push has led to the development of Differentiated
services (diff-serv). In contrast to RSVP's per-flow orientation, services (diff-serv). In contrast to RSVP's per-flow orientation,
diff-serv networks classify packets to one of a small number of aggre- 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 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 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 per-flow state, diff-serv QoS can initially be deployed using top-down
provisioning, with no requirement for end- to-end signaling. provisioning, with no requirement for end- to-end signaling.
At the same time however, it is important to assure that the diff- At the same time however, it is important to assure that the diff-serv
serv mechanisms deployed, interoperate effectively with hosts and net- mechanisms deployed, interoperate effectively with hosts and networks
works that provide per-flow QoS in response to end-to-end signaling. that provide per-flow QoS in response to end-to-end signaling. This is
This is important, as we believe that in the coming years, there will important, as we believe that in the coming years, there will be a
be a proliferation of applications that depend on QoS and of hosts proliferation of applications that depend on QoS and of hosts which
which will signal end-to-end on their behalf. will signal end-to-end on their behalf.
This draft proposes a framework in which diff-serv capable transit This draft proposes a framework in which diff-serv capable networks
networks provide aggregate QoS services, in support of RSVP/Intserv provide aggregate QoS services, and they co-exist and inter-operate
capable hosts and stub networks, which use end-to-end signaling. In with RSVP/Intserv capable hosts and stub networks, which use end-to-
our model, diff-serv mechanisms are used within transit networks and end signaling.
at the boundaries between them, while either diff-serv or RSVP/Intserv
mechanisms are used within stub networks 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 signaling. The remaining resources will be
allotted using traditional 'top-down' provisioning methods.
Our framework allows the deployment of diff-serv networks and For instance, in one example of such a model, diff-serv mechanisms are
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 Use Of RSVP with Diffserv June, 1998
down' provisioning methods.
However, our model does not preclude other possibilities: use of
diff-serv mechanisms and top-down provisioning in both stub and tran-
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
RSVP/Intserv networks to proceed at their own pace, providing immedi- RSVP/Intserv networks to proceed at their own pace, providing immedi-
ate incremental benefits in areas of the network in which one or the ate incremental benefits in areas of the network in which one or the
other is deployed and additional benefits where both are deployed. other is deployed and additional benefits where both are deployed.
This framework builds upon current work in the IETF including diff- This framework builds upon current work in the IETF including diff-
serv [10] and RSVP aggregation [8]. serv [10] and RSVP aggregation [8].
Many of the ideas in this document have been previously discussed in Many of the ideas in this document have been previously discussed in
the original intserv architecture document [12]. the original intserv architecture document [12].
2. Goals of This Draft 2. Goals of This Draft
This draft is based on the assumption that end-to-end QoS is required This draft is based on the assumption that end-to-end QoS is required
to support the needs of certain applications. Such applications to support the needs of certain applications. Such applications
include IP-telephony, video-on-demand and various non- multimedia include IP-telephony, video-on-demand, and various non-multimedia
mission-critical applications. mission-critical applications.
In our view, intserv and diff-serv are complementary tools in the pur- In our view, intserv and diff-serv are complementary tools in the pur-
suit of end-to-end QoS. Each serves an important purpose in the end- suit of end-to-end QoS. Each serves an important purpose in the end-
to-end QoS enabled network. The primary goal of this draft is to to-end QoS enabled network. The primary goal of this draft is to
encourage the continued development of each in a manner that does not encourage the continued development of each in a manner that does not
preclude realization of the proposed framework. To this end, we will: preclude realization of the proposed framework. To this end, we will:
1. List the requirements of a network that provides end-to-end QoS. 1. List the requirements of a network that provides end-to-end QoS.
2. Present a framework that uses intserv as a customer of diff-serv 2. Present a framework that uses intserv as a customer of diff-serv
to meet these requirements. to meet these requirements.
3. Identify dependencies of intserv on diff-serv. 3. Identify dependencies of intserv on diff-serv.
Ultimately, we aim to clearly define a manner in which RSVP/Intserv Ultimately, we aim to clearly define a manner in which RSVP/Intserv
Use Of RSVP with Diffserv June, 1998
and diff-serv mechanisms interact seamlessly. We expect that by doing and diff-serv mechanisms interact seamlessly. We expect that by doing
so, we will enable network administrators to determine the degree to so, we will enable network administrators to determine the degree to
which diff-serv capabilities are pushed towards the edge of their net- which diff-serv capabilities are pushed towards the edge of their net-
works (or, the degree to which RSVP/Intserv capabilities are pushed works (or, the degree to which RSVP/Intserv capabilities are pushed
towards the core). towards the core).
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
does not address the issues specific to IP multicast flows such as
merging dissimilar reservations.
3. Terminology 3. Terminology
The following terms are used in this draft: The following terms are used in this draft:
a. Intserv region (or intserv capable network) - the part of an a. Intserv region (or intserv capable network) - the part of an
internet that uses per-flow identification, signaling, and admission internet that uses per-flow identification, signaling, and admission
control to deliver per-flow QoS guarantees control to deliver per-flow QoS guarantees
b. Diff-serv region (or diff-serv capable network) - the part of an b. Diff-serv region (or diff-serv capable network) - the part of an
internet that provides aggregate QoS services internet that provides aggregate QoS services
c. Quantitative QoS applications - applications for which QoS c. Quantitative QoS applications - applications for which QoS
Use Of RSVP with Diffserv June, 1998
requirements are readily quantifiable, and which rely on these QoS requirements are readily quantifiable, and which rely on these QoS
requirements to function properly. requirements to function properly.
d. Qualitative QoS applications - applications for which relative d. Qualitative QoS applications - applications for which relative
QoS requirements exist, but are not readily quantifiable. QoS requirements exist, but are not readily quantifiable.
e. QoS applications - applications that require some form of QoS, e. QoS applications - applications that require some form of QoS,
either qualitative or quantitative. either qualitative or quantitative.
f. Loose QoS - QoS assurances which are relative, rather than f. Loose QoS - QoS assurances which are relative, rather than
absolute, or generally not quantifiable. absolute, or generally not quantifiable.
g. Tight QoS - QoS assurances which are absolute and quantifiable, g. Tight QoS - QoS assurances which are quantifiable,
though they may or may not provide 100% guarantee. though they may or may not provide 100% guarantee.
h. Top-down (or open-loop) provisioning - traditional provisioning h. Top-down (or open-loop) provisioning - traditional provisioning
methods which configure network capacities using heuristics and methods which configure network capacities using heuristics and
experience, typically from a console, with no explicit knowledge of experience, typically from a console, with no explicit knowledge of
exact traffic volumes or exact paths taken by the affected traffic. exact traffic volumes or exact paths taken by the affected traffic.
i. RSVP/Intserv - RSVP is a signaling protocol. Intserv (in this i. RSVP/Intserv - RSVP is a signaling protocol. Intserv (in this
context) is a model for quantifying traffic that is useful for context) is a model for quantifying traffic that is useful for
admission control purposes. In this document, we use the terms admission control purposes. In this document, we use the terms
together, to discuss the RSVP/Intserv network, in contrast to the together, to discuss the RSVP/Intserv network, in contrast to the
diff-serv network. However, the two are separable and much of 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 following discussion could be applied to a model in which RSVP
signals using parameters that are not Intserv specific. signals using parameters that are not Intserv specific.
4. Requirements for the End-to-End QoS Framework An end-to-end QoS 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 network must serve the requirements of network managers as well as
those of both quantitative and qualitative QoS applications. We con- those of both quantitative and qualitative QoS applications. We con-
sider these requirements in the context of the following general sider these requirements in the context of the following general
topology: topology:
/ Stub \ / Transit \ / Stub \ / Stub \ / Transit \ / Stub \
/ Network \ / Network \ / Network \ / Network \ / Network \ / Network \
|---| | |---| |---| |---| |---| | |---| |---| | |---| |---| |---| |---| | |---|
|Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx | |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx |
|---| | |-- | |---| |---| |---| | |---| |---| | |-- | |---| |---| |---| | |---|
\ / \ / \ / \ / \ / \ /
\ / \ / \ / \ / \ / \ /
Figure 1: Sample Network Configuration Figure 1: Sample Network Configuration
This network consists of a diff-serv capable transit network and two This network consists of a diff-serv capable transit network and two
Use Of RSVP with Diffserv June, 1998
intserv capable stub networks. In the interest of simplicity, we show 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 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- 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- 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 dary routers (BR1, BR2) at the interfaces of the diff-serv network to
the intserv networks. the intserv networks.
The transit network contains a mesh of routers, at least some of which The transit network contains a mesh of routers, at least some of which
are diff-serv capable. The stub networks contain a mesh of routers, at are diff-serv capable. The stub networks contain a mesh of routers, at
least some of which are intserv capable. least some of which are intserv capable.
We define the following requirements of the framework: We define the following requirements of the framework:
4.1 Definition of a Set of Services 4.1 Definition of a Set of Services
There must be a set of useful end-to-end services available to Quanti- There must be a set of useful end-to-end services available to Quanti-
tative QoS applications. Routers internal to the diff-serv network are tative QoS applications. Routers internal to the diff-serv network are
assumed to provide a set of 'per-hop-behaviours' (PHBs [10]). We assumed to provide a set of 'per-hop-behaviors' (PHBs [10]). We expect
expect that concatenation of certain well-defined PHBs will yield cer- that concatenation of certain well-defined PHBs will yield certain
tain well-understood services across the diff-serv network. We also well-understood services across the diff-serv network. We also expect
expect that the intserv regions of the network will be able to extend that the intserv regions of the network will be able to extend these
these services such that they can be realized in a true end-to-end services such that they can be realized in a true end-to-end manner.
manner.
In addition, there must be a set of end-to-end services available to In addition, there must be a set of end-to-end services available to
Qualitative QoS applications. However, the services that these appli- Qualitative QoS applications. However, the services that these
cations require are generally less demanding. They can be loosely pro-
visioned (in a top-down manner) in the diff-serv regions of the net- Use Of RSVP with Diffserv June, 1998
work and will likely receive best-effort treatment in the intserv
applications require are generally less demanding. They can be loosely
provisioned (in a top-down manner) in the diff-serv regions of the
network and will likely receive best-effort treatment in the intserv
regions of the network. regions of the network.
In this draft we focus primarily on the requirements of quantitative In this draft we focus primarily on the requirements of quantitative
QoS applications. Although these may generate only a small fraction of QoS applications. Although these may generate only a small fraction of
all traffic, servicing this traffic may comprise a significant frac- all traffic, servicing this traffic may comprise a significant frac-
tion of the revenues associated with QoS. In addition, while qualita- tion of the revenues associated with QoS. In addition, while qualita-
tive QoS applications can be satisfied by conventional diff- serv tive QoS applications can be satisfied by conventional diff- serv
alone, quantitative QoS applications require additional support. alone, quantitative QoS applications require additional support.
4.2 Allotment of Diff-serv Service Levels to Specific Traffic Flows 4.2 Allotment of Diff-serv Service Levels to Specific Traffic Flows
It must be possible for QoS applications to invoke specific end-to- It must be possible for QoS applications to invoke specific end-to-end
end service levels for their traffic flows. Within the intserv regions service levels for their traffic flows. Within the intserv regions of
of the network quantitative QoS applications do so by using RSVP sig- the network quantitative QoS applications do so by using RSVP signal-
naling to configure classifiers which operate on IP addresses and port ing to configure classifiers which operate on IP addresses and port
numbers. We will refer to such classifiers from here on as 'MF' clas- numbers. We will refer to such classifiers from here on as 'MF' clas-
sifiers [10]. sifiers [10].
Within the diff-serv regions of the network, traffic is allotted Within the diff-serv regions of the network, traffic is allotted ser-
vice based on the contents of the DS-field in packet headers. There-
Use Of RSVP with Diffserv June, 1998 fore, it is necessary for QoS applications to effect the correct mark-
ing of DS-fields before their packets are submitted to the diff-serv
service based on the contents of the DS-field in packet headers. network. (This is particularly true for quantitative QoS applications,
Therefore, it is necessary for QoS applications to effect the correct less so for qualitative QoS applications that need not play as active
marking of DS-fields before their packets are submitted to the diff- a role in securing specific QoS from the network). There are two gen-
serv network. (This is particularly true for quantitative QoS applica- eral mechanisms for doing so:
tions, less so for qualitative QoS applications that need not play as
active a role in securing specific QoS from the network). There are
two general mechanisms for doing so:
1. Hosts may directly mark DS-fields in the transmitted packets of 1. Hosts may directly mark DS-fields in the transmitted packets of
QoS applications. QoS applications.
2. Routers external to the diff-serv network may mark DS-fields on 2. Routers external to the diff-serv network may mark DS-fields on
behalf of QoS applications based on MF classification. behalf of QoS applications based on MF classification.
In the first case, marking will be done based on host configuration or In the first case, marking will be done based on host configuration or
local communication between QoS applications and the host operating local communication between QoS applications and the host operating
system. In the second case, marking will be done based on top-down system. In the second case, marking will be done based on top-down
configuration of the marking router's MF classifier/marker (by manual configuration of the marking router's MF classifier/marker (by manual
configuration or via automated configuration scripts) or based on configuration or via automated configuration scripts) or based on
standard signaling between QoS applications and the marking router's standard signaling between QoS applications and the marking router's
classifier/marker. classifier/marker.
The following three requirements argue either for host based marking The following three requirements argue either for host based marking
or for dynamic configuration of a router's classifier/marker in or for dynamic configuration of a router's classifier/marker in
response to application requests. response to application requests.
4.2.1 Minimal Management Burden 4.2.1 Minimal Management Burden
Use Of RSVP with Diffserv June, 1998
The information required to express useful mappings of application The information required to express useful mappings of application
traffic flows to service levels is likely to be quite complex and to traffic flows to service levels is likely to be quite complex and to
change frequently. Thus, manual configuration is likely to impose a change frequently. Thus, manual configuration is likely to impose a
significant management burden. If the configuration information is significant management burden. If the configuration information is
very simple and does not change over time, the management burden may very simple and does not change over time, the management burden may
be relatively minor. However, this means that the granularity of be relatively minor. However, this means that the granularity of
allotting service levels to flows will be sub-optimal. allotting service levels to flows will be sub-optimal.
4.2.2 Granularity of Allotment 4.2.2 Granularity of Allotment
skipping to change at page 7, line 4 skipping to change at page 7, line 28
city that is available in allotting a specific service level to a city that is available in allotting a specific service level to a
specific traffic flow. There are two measures of granularity; one is specific traffic flow. There are two measures of granularity; one is
the granularity with which an individual flow or a group of flows 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 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- 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 ing requirement to be expressed: telephony traffic from user X should
be allotted service level A, while telephony traffic from user Y 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 B, and web traffic from any user
should be allotted service level C. A coarse grain system would be 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 limited to something of the form: all traffic from subnet 1.0.0.0
Use Of RSVP with Diffserv June, 1998
should receive service level A, while all traffic from subnet 2.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 should receive service level B. A temporally fine grain system would
allow immediate changes in allotment of service levels to traffic allow immediate changes in allotment of service levels to traffic
flows. A temporally coarse grain system may allow infrequent changes flows. A temporally coarse grain system may allow infrequent changes
only. only.
4.2.3 Difficulties in Identification of Application Flows 4.2.3 Difficulties in Identification of Application Flows
Routers may not be able to readily identify specific application flows Routers may not be able to readily identify specific application flows
based on network and/or transport layer fields in a packet. based on network and/or transport layer fields in a packet.
skipping to change at page 7, line 34 skipping to change at page 8, line 4
Quantitative QoS applications use RSVP to request that their flows be Quantitative QoS applications use RSVP to request that their flows be
admitted to intserv regions of the network. When a request is admitted to intserv regions of the network. When a request is
rejected, the host application may avoid sending traffic and/or inter- rejected, the host application may avoid sending traffic and/or inter-
mediate RSVP capable nodes will only give best-effort service to mediate RSVP capable nodes will only give best-effort service to
traffic on flows that were not admitted. These mechanisms protect traffic on flows that were not admitted. These mechanisms protect
traffic on flows that were admitted. traffic on flows that were admitted.
In diff-serv regions of the network, admission control is provided In diff-serv regions of the network, admission control is provided
implicitly, by policing at ingress points based on provisioning. The implicitly, by policing at ingress points based on provisioning. The
problem with implicit admission control is that it breaks the end-to- problem with implicit admission control is that it breaks the end-to-
Use Of RSVP with Diffserv June, 1998
end validity of explicit admission control. Specifically, an applica- end validity of explicit admission control. Specifically, an applica-
tion may gain admission using RSVP signaling, even though there is no tion may gain admission using RSVP signaling, even though there is no
capacity for that application's traffic within the diff-serv region of capacity for that application's traffic within the diff-serv region of
the network. Neither the application, nor intermediate RSVP capable the network. Neither the application, nor intermediate RSVP capable
nodes will be aware that the application's traffic is not admissible. nodes will be aware that the application's traffic is not admissible.
As a result, neither can take corrective action and all traffic from As a result, neither can take corrective action and all traffic from
that customer, at the corresponding service level, may be compromised. that customer, at the corresponding service level, may be compromised.
This failure may be partially, but not completely alleviated by polic- This failure may be partially, but not completely alleviated by polic-
ing based on MF classification at the diff-serv ingress (rather than ing based on MF classification at the diff-serv ingress (rather than
BA classification [10]). BA classification [10]).
End-to-end QoS requires that quantitative QoS applications and RSVP End-to-end QoS requires that quantitative QoS applications and RSVP
capable intserv nodes be explicitly informed of admission control capable intserv nodes be explicitly informed of admission control
failure in the diff-serv network. This enables them to take corrective failure in the diff-serv network. This enables them to take corrective
action and to avoid overdriving the diff-serv network. If the service action and to avoid overdriving the diff-serv network. If the service
agreement between the intserv and diff-serv regions of the network is agreement between the intserv and diff-serv regions of the network is
statically provisioned, then admission control functionality can be statically provisioned, then admission control functionality can be
provided by static configuration of admission control in intserv edge provided by static configuration of admission control in intserv edge
routers. However, if the service agreement is dynamically variable, routers. However, if the service agreement is dynamically variable,
then it will be necessary to dynamically propagate current diff-serv then it will be necessary to dynamically propagate current diff-serv
resource availability to the intserv network for the purpose of resource availability to the intserv network for the purpose of expli-
cit admission control.
Use Of RSVP with Diffserv June, 1998
explicit admission control.
4.4 Policy Support 4.4 Policy Support
End-to-end QoS leads to preferential treatment of certain traffic End-to-end QoS leads to preferential treatment of certain traffic
flows over others. Within diff-serv regions of the network, policy flows over others. Within diff-serv regions of the network, policy
applies on a per-customer basis. In general, the diff-serv network applies on a per-customer basis. In general, the diff-serv network
makes multiple service levels available to a single customer's intserv makes multiple service levels available to a single customer's intserv
network. In this case the customer must apply policy within its net- network. In this case the customer must apply policy within its net-
work to assure appropriate allocation of resources (customer network work to assure appropriate allocation of resources (customer network
resources as well as diff-serv network resources) to individual hosts resources as well as diff-serv network resources) to individual hosts
skipping to change at page 8, line 29 skipping to change at page 8, line 50
control be based on policy as well as resource availability. control be based on policy as well as resource availability.
5. Intserv as a Customer of Diff-serv 5. Intserv as a Customer of Diff-serv
To meet the above requirements, we envision a network that consists To meet the above requirements, we envision a network that consists
typically of relatively smaller, intserv capable stub networks, con- typically of relatively smaller, intserv capable stub networks, con-
nected by larger, diff-serv capable transit networks. In this sec- nected by larger, diff-serv capable transit networks. In this sec-
tion, we will describe the operation of one instantiation of such a tion, we will describe the operation of one instantiation of such a
network (see figure 1). The following assumptions apply: network (see figure 1). The following assumptions apply:
5.0.1 Host Capabilities 5.1.1 Host Capabilities
Both sending and receiving hosts use RSVP to communicate QoS require- Both sending and receiving hosts use RSVP to communicate QoS require-
ments of certain QoS aware applications running on the host. A QoS ments of certain QoS aware applications running on the host. A QoS
process within the host operating system generates RSVP signaling on process within the host operating system generates RSVP signaling on
Use Of RSVP with Diffserv June, 1998
behalf of the applications. This process also invokes traffic control. behalf of the applications. This process also invokes traffic control.
Host traffic control includes marking the DS-field in transmitted Host traffic control includes marking the DS-field in transmitted
packets and shaping transmitted traffic per token bucket specifica- packets and shaping transmitted traffic per token bucket specifica-
tions. Note that host traffic control is assumed for this specific tions. Note that host traffic control is assumed for this specific
example, but is not a requirement of the framework in general. Leaf example, but is not a requirement of the framework in general. Leaf
routers within the intserv network may provide the traffic control routers within the intserv network may provide the traffic control
functions. functions.
5.0.2 Edge Routers 5.1.2 Edge Routers
The edge routers are special routers that straddle the boundary The edge routers are special routers that straddle the boundary
between the RSVP/Intserv region of the network and the diff-serv between the RSVP/Intserv region of the network and the diff-serv
region of the network. It is helpful to think of these routers as con- region of the network. It is helpful to think of these routers as con-
sisting of two halves; the standard RSVP half, which interfaces to the sisting of two halves; the standard RSVP half, which interfaces to the
stub networks, and the diff-serv half, which interfaces to the transit stub networks, and the diff-serv half, which interfaces to the transit
network. network.
The RSVP half is at least partially RSVP capable; it is able to pro- The RSVP half is at least partially RSVP capable; it is able to pro-
cess PATH and RESV messages but it is not necessarily required to 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- store full RSVP state and it is not required to provide MF classifica-
tion. tion.
Use Of RSVP with Diffserv June, 1998
The diff-serv half of the router provides the interface to the admis- The diff-serv half of the router provides the interface to the admis-
sion control function for the diff-serv network. We shall refer to sion control function for the diff-serv network. We shall refer to
this function from here on as the 'DACS' (diff-serv admission control this function from here on as the 'DACS' (diff-serv admission control
service). The DACS is a process that is likely to (but is not required service). The DACS is a process that is likely to (but is not required
to) run at least partially, on the routers. If the service agreement to) run at least partially, on the routers. If the service agreement
between the stub networks and the transit networks is statically pro- between the stub networks and the transit networks is statically pro-
visioned then the DACS can be as simple as a table which specifies visioned then the DACS can be as simple as a table which specifies
capacity at each service level. If the service agreement is dynamic, capacity at each service level. If the service agreement is dynamic,
the DACS may communicate with counterparts within the diff-serv net- the DACS may communicate with counterparts within the diff-serv net-
work (such as a bandwidth broker [4]) and may be able to make admis- 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 sion control decisions based on provisioned limits as well as the
topology and the capacity of the diff-serv network. topology and the capacity of the diff-serv network.
5.0.3 Boundary Routers 5.1.3 Boundary Routers
These are conventional boundary routers. In the example illustrated, These are conventional boundary routers. In the example illustrated,
they are not required to run RSVP. They are expected to implement the they are not required to run RSVP. They are expected to implement the
policing function of diff-serv ingress routers, based on the results policing function of diff-serv ingress routers, based on the results
of a BA classifier. They may, but are not required, to provide MF of a BA classifier. They are neither required to provide MF classifi-
classification nor to mark the DS-field (with the possible exception cation nor must mark the DS-field (with the possible exception of dif-
of the in/out bit). [10, 8] ferential marking to indicate out of profile traffic [10, 8]). Note
that this example places the boundary between the RSVP/Intserv network
Note that this example places the boundary between the RSVP/Intserv and the diff-serv network, within the edge routers at the stub net-
network and the diff-serv network, within the edge routers at the stub works. In general, this boundary could be shifted to the left or to
networks. In general, this boundary could be shifted to the left or to
the right. It could for example, be placed within the boundary routers the right. It could for example, be placed within the boundary routers
in the transit network. In this case, the DACS is implemented in the transit network. In this case, the DACS is implemented
Use Of RSVP with Diffserv June, 1998
entirely within the diff-serv network (and is essentially, the entirely within the diff-serv network (and is essentially, the
bandwidth broker proposed in [4]), but the diff- serv boundary routers bandwidth broker proposed in [4]), but the diff- serv boundary routers
must be RSVP capable. must be RSVP capable.
5.0.4 Stub Networks 5.1.4 Stub Networks
The stub networks consist of int-serv capable hosts and some number of The stub networks consist of int-serv capable hosts and some number of
leaf routers. Leaf routers within the stub networks may or may not be 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- 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 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 necessary. If they are not int-serv capable, we assume that they are
not capable of per-flow identification, signaling, and admission con- not capable of per-flow identification, signaling, and admission con-
trol and, in that case, will pass RSVP messages (requesting per-flow trol and, in that case, will pass RSVP messages (requesting per-flow
QoS) unhindered. QoS) unhindered.
5.0.5 Transit Network 5.1.5 Transit Network
The transit network is not capable of per-flow identification, signal-
ing, 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
Use Of RSVP with Diffserv June, 1998
messages transparently, with minimal or no impact on its performance The transit network is not typically capable of per-flow identifica-
(see [8]). The transit network may include multiple carrier networks. 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.0.6 Carrier/Customer Agreement 5.1.6 Carrier/Customer Agreement
The customer (owner(s) of the leaf networks) and the carrier owning The customer (owner(s) of the leaf networks) and the carrier owning
the transit network have negotiated a contract for the capacity to be 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 provided at each of a number of standard diff-serv service levels. The
capacity may be statically provisioned. In this case, the DACSs are capacity may be statically provisioned. In this case, the DACSs are
statically configured with the capacity available at each service statically configured with the capacity available at each service
level and reside entirely within the edge routers. Alternatively, the level and reside entirely within the edge routers. Alternatively, the
capacity may be dynamically variable with a pre- negotiated usage fee capacity may be dynamically variable with a pre- negotiated usage fee
and/or a pre-negotiated capacity limit. In this case, the DACS would and/or a pre-negotiated capacity limit. In this case, the DACS would
be required to communicate with counterparts within the diff-serv be required to communicate with counterparts within the diff-serv
transit network. transit network depending on the granularity of allotment (temporally
coarse or temporally fine grained).
5.0.7 Mapping from Intserv Service Type to DS-field 5.1.7 Mapping from Intserv Service Type to DS-field
In our proposal, we use RSVP signaling to provide admission control to In our proposal, we use RSVP signaling to provide admission control to
specific service levels in the diff-serv, as well as the intserv net- specific service levels in the diff-serv, as well as the intserv net-
work. RSVP signaling requests carry an intserv service type, describ- work. RSVP signaling requests carry an intserv service type, describ-
ing the type of service they expect from the intserv regions of the ing the type of service they expect from the intserv regions of the
network. At each hop in an intserv network, the generic intserv ser- network. At each hop in an intserv network, the generic intserv ser-
vice requests are interpreted in a form meaningful to the specific vice requests are interpreted in a form meaningful to the specific
media. media. For example, at an ATM hop, a VC of the correct type (CBR, ABR
For example, at an ATM hop, a VC of the correct type (CBR, ABR or VBR) Use Of RSVP with Diffserv June, 1998
is established [13]. At an 802.1 hop, the intserv service type is
mapped to an appropriate 802.1p priority level [5]. At the boundary or VBR) is established [13]. At an 802.1 hop, the intserv service type
between the intserv network and a diff-serv network, it is necessary is mapped to an appropriate 802.1p priority level [5].
for edge devices to map the requested intserv service to a diff-serv
service level that can reasonably extend the intserv service type Similar mapping is necessary from Intserv Service type to DS-field. At
requested by the application. The edge device can then provide admis- the boundary between the intserv network and a diff-serv network, it
sion control to the diff-serv network by accepting or rejecting the is necessary for edge devices to map the requested intserv service to
request based on the capacity available at the requested diff-serv a diff-serv service level that can reasonably extend the intserv ser-
service level. 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 We assume that one of two schemes is used to map intserv service types
to diff-serv service levels. In the first scheme (called "default map- to diff-serv service levels. In the first scheme (called "default map-
ping"), we propose a standard, well-known mapping from intserv service ping"), we propose a standard, well-known mapping from intserv service
type to a PHB that will invoke the appropriate behavior in the diff- type to a PHB that will invoke the appropriate behavior in the diff-
serv network. The mapping is not necessarily one-to-one. For example, serv network. The mapping is not necessarily one-to-one. For example,
controlled-load interactive voice traffic will likely map to a PHB controlled-load interactive voice traffic will likely map to a PHB
having different latency characteristics than controlled-load latency having different latency characteristics than controlled-load latency
tolerant traffic. For this reason we suggest adding a qualifier to the tolerant traffic. For this reason we suggest adding a qualifier to the
intserv service type indicating its relative latency tolerance (high intserv service type indicating its relative latency tolerance (high
or low). The qualifier would be defined as a standard object in or low). The qualifier would be defined as a standard object in
intserv signaling messages. intserv signaling messages.
Use Of RSVP with Diffserv June, 1998
In an alternate scheme (called "customer-specified mapping"), we allow In an alternate scheme (called "customer-specified mapping"), we allow
the devices at the edge of the diff-serv region of the network to 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- modify the well-known mapping. Under this approach, RESV messages ori-
ginating at hosts carry the usual intserv service type (with a qualif- ginating at hosts carry the usual intserv service type (with a qualif-
ier, as described above). When RESV messages arrive at the interface 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, 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), 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 edge device will determine the PHB that should be used to obtain
the corresponding diff-serv service level. This value is appended to the corresponding diff-serv service level. This value is appended to
the RESV message by the edge device and is carried to the sending 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 host. When the RESV message arrives at the sending host, the sender
(or intermediate intserv routers) will mark outgoing packets with the (or intermediate intserv routers) will mark outgoing packets with the
indicated PHBs. indicated PHBs.
The decision to modify the well-known mapping at the edge devices will The decision to modify the well-known mapping at the edge devices will
be based on edge-device configuration and/or policy decision at the be based on edge-device configuration and/or policy decision at the
edges. edges. For example, when a reservation arrives at the edge of diff-
serv network and if enough reservations have already been accepted to
reach the pre-negotiated capacity limit at the corresponding service
level, the device may decide to use a PHB corresponding to a different
(less assured?) service level based on an administratively set policy.
5.1 How End-to-End QoS is Obtained 5.2 How End-to-End QoS is Obtained
Use Of RSVP with Diffserv June, 1998
The following sequence illustrates the process by which an application The following sequence illustrates the process by which an application
obtains end-to-end QoS: obtains end-to-end QoS:
1. The sending host's QoS process generates an RSVP PATH message, 1. The sending host's QoS process generates an RSVP PATH message,
describing the traffic offered by the sending application. describing 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. In the
sending stub network, standard RSVP processing will be applied at sending stub network, standard RSVP processing will be applied at
RSVP capable nodes (routers, SBMs, etc). RSVP capable nodes (routers, SBMs, etc).
skipping to change at page 12, line 4 skipping to change at page 12, line 35
5. At the receiving host, the QoS process generates an RSVP RESV 5. At the receiving host, the QoS process generates an RSVP RESV
message, indicating interest in the offered traffic, at a certain message, indicating interest in the offered traffic, at a certain
intserv service level. intserv 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 at any
RSVP node in the receiving stub network if resources are deemed RSVP node in the receiving stub network if resources are deemed
insufficient to carry the traffic requested. 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
Use Of RSVP with Diffserv June, 1998
processing. It may be rejected if resources on the downstream processing. It may be rejected if resources on the downstream
interface of ER2 are deemed insufficient to carry the resources interface of ER2 are deemed insufficient to carry the resources
requested. If it is not rejected, it will be carried transparently requested. If it is not rejected, it will be carried transparently
through the transit network, arriving at ER1. through the transit network, arriving at ER1.
8. At this point, the RESV message triggers DACS processing. The 8. At this point, the RESV message triggers DACS processing. The
DACS compares the resources requested to the resources available at DACS compares the resources requested to the resources available at
the corresponding diff-serv service level, in the diff-serv enabled the corresponding diff-serv service level, in the diff-serv enabled
transit network. If the RESV message is admitted, the DACS updates transit network. If the RESV message is admitted, the DACS updates
the available capacity for the service class, by subtracting the the available capacity for the service class, by subtracting the
approved resources from the available capacity. approved resources from the available capacity.
9. Assuming the available capacity is sufficient, the RESV message 9. Assuming the available capacity is sufficient, the RESV message
is admitted and is allowed to continue upstream towards the sending is admitted and is allowed to continue upstream towards the sending
host. If the available capacity is insufficient, the RESV message host. If the available capacity is insufficient, the RESV message
will be rejected and the available capacity for the service class will be rejected and the available capacity for the service class
will remain unchanged. will remain unchanged.
10. The RESV message proceeds through the sending stub network. RSVP 10. The RESV message proceeds through the sending stub network. RSVP
nodes in the sending stub network may reject it. If it is not nodes in the sending stub network may reject it. If it is not
Use Of RSVP with Diffserv June, 1998
rejected, it will arrive at the sending host. rejected, it will arrive at the sending host.
11. At the sending host, the QoS process receives the RESV message. 11. At the sending host, the QoS process receives the RESV message.
It interprets receipt of the message as an indication that the It interprets receipt of the message as an indication that the
specified traffic has been admitted for the specified intserv specified traffic has been admitted for the specified intserv
service type (in the RSVP enabled regions of the network) and for service type (in the RSVP enabled regions of the network) and for
the corresponding diff-serv service level (in the diff-serv enabled 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 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 of transmitted packets, to the value which maps to the Intserv
service type specified in the admitted RESV message. 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 are able to obtain end to end QoS through a combi-
nation of networks that support RSVP style reservations and networks nation of networks that support RSVP style reservations and networks
that support diff-serv style priortization. The successful arrival of that 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 control
has succeeded both in the RSVP regions of the network and in the has succeeded both in the RSVP regions of the network and in the
diff-serv regions of the network. diff-serv regions of the network.
5.2 Variations of the Model 5.3 Variations of the Model
It is useful to consider a number of variations of the model It is useful to consider a number of variations of the model
presented. presented.
5.2.1 Admission Control 5.3.1 Admission Control
5.2.1.1 Statically Provisioned Service Agreements
Use Of RSVP with Diffserv June, 1998 5.3.1.1 Statically Provisioned Service Agreements
In the simplest model, service agreements are negotiated statically In the simplest model, service agreements are negotiated statically
between the stub networks and the transit networks. A service agree- between the stub networks and the transit networks. A service agree-
ment consists of a table of capacities available to a customer's stub 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- network, at each diff-serv service level. In this case, DACS func-
tionality is provided at the edge routers in the stub networks. The 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- 'diff-serv half' of these routers appear to the 'RSVP half' as a send-
ing interface with resource limits defined by the service agreement ing interface with resource limits defined by the service agreement
table. While there may be bandwidth brokers and dynamic provisioning table. While there may be bandwidth brokers and dynamic provisioning
within the transit networks, these are not coupled with the intserv within the transit networks, these are not coupled with the intserv
stub networks and admission control in the two regions of the network stub networks and admission control in the two regions of the network
is completely independent. is completely independent.
5.2.1.2 Dynamic Service Agreements 5.3.1.2 Dynamic Service Agreements
In a more sophisticated model, service agreements between customer In a more sophisticated model, service agreements between customer
stub networks and carrier transit networks are more dynamic. Customers stub networks and carrier transit networks are more dynamic. Customers
may be able to dynamically request changes to the service agreement. may be able to dynamically request changes to the service agreement.
In this case, a statically provisioned edge router cannot provide the In this case, a statically provisioned edge router cannot provide the
required DACS functionality. Instead, DACS functionality must be pro- required DACS functionality. Instead, DACS functionality must be pro-
vided by coupling the stub network's admission control with the tran- vided by coupling the stub network's admission control with the
sit network's admission control.
Use Of RSVP with Diffserv June, 1998
transit network's admission control.
The two admission control mechanisms meet at the boundary between the The two admission control mechanisms meet at the boundary between the
diff-serv network and the intserv network. This boundary may be imple- diff-serv network and the intserv network. This boundary may be imple-
mented at the edge router (in the stub network), at the boundary mented at the edge router (in the stub network), at the boundary
router (in the transit network), or at the bandwidth broker for the router (in the transit network), or at the bandwidth broker for the
intserv network. intserv network.
5.2.1.3 Limiting the Impact of Intserv Admission Control on the Diff- 5.3.1.3 Limiting the Impact of Intserv Admission Control on the Diff-
serv Network serv Network
Note that coupling intserv and diff-serv admission control does not Note that coupling intserv and diff-serv admission control does not
imply that each intserv admission control request results in diff- imply that each intserv admission control request results in diff-serv
serv admission control work. Instead, intserv admission control admission control work. Instead, intserv admission control requests
requests are aggregated at the boundary between the intserv and the are aggregated at the boundary between the intserv and the diff-serv
diff-serv network. For example, intserv admission control requests may network. For example, intserv admission control requests may trigger
trigger diff-serv admission control requests to bandwidth brokers only diff-serv admission control requests to bandwidth brokers only when
when some high-water or low-water resource threshold is crossed. some high-water or low-water resource threshold is crossed. Separate
Separate high-water and low-water thresholds provide hysteresis to high-water and low-water thresholds provide hysteresis to prevent
prevent thrashing. thrashing.
5.2.1.4 Roles of Policy and Resource Based Admission Control 5.3.1.4 Roles of Policy and Resource Based Admission Control
It is necessary to provide both resource and policy based admission It is necessary to provide both resource and policy based admission
control in the diff-serv network as well as the intserv network. In control in the diff-serv network as well as the intserv network. In
the diff-serv network, resource and policy based admission control are the diff-serv network, resource and policy based admission control are
handled by entities such as bandwidth brokers and reflected to the handled by entities such as bandwidth brokers and reflected to the
intserv network as DACS (or RSVP). Policy decisions made within the intserv network as DACS (or RSVP). Policy decisions made within the
Use Of RSVP with Diffserv June, 1998
diff-serv network are likely to be at the per-intserv network (per- diff-serv network are likely to be at the per-intserv network (per-
customer of the diff-serv network) granularity. customer of the diff-serv network) granularity.
In the intserv network, resource based admission control is handled by In the intserv network, resource based admission control is handled by
RSVP enabled routers (and SBMs [2]). Policy based admission control is RSVP enabled routers (and SBMs [2]). Policy based admission control is
handled by RSVP capable policy servers. These assure that intserv handled by RSVP capable policy servers. These assure that intserv
resources are allotted to intserv customers according to policy resources are allotted to intserv customers according to policy
specific to the intserv network. In addition, policy servers within specific to the intserv network. In addition, policy servers within
the intserv network must also assure that appropriate policy is the intserv network must also assure that appropriate policy is
applied when diff-serv resources are allotted to intserv customers. applied when diff-serv resources are allotted to intserv customers.
5.2.2 Setting the DS-field at Intermediate Nodes 5.3.2 Setting the DS-field at Intermediate Nodes
In the example described, hosts use RSVP signaling and mark the DS- In the example described, hosts use RSVP signaling and mark the DS-
byte corresponding to the admitted service level. Note that these byte corresponding to the admitted service level. Note that these
functions can be separated. In the example, the function of RSVP sig- 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- 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 end admission control. The function of marking the DS-field is to
reduce the need for MF classification at routers. (MF classification reduce the need for MF classification at routers. (MF classification
is required at the ingress to a diff-serv network only to determine is required at the ingress to a diff-serv network only to determine
Use Of RSVP with Diffserv June, 1998
the customer to whom the traffic belongs. If an interface is dedicated the customer to whom the traffic belongs. If an interface is dedicated
to the customer, no MF classification need be done. In this case, any to the customer, no MF classification need be done. In this case, any
MF classification on behalf of the diff-serv ingress point is provided MF classification on behalf of the diff-serv ingress point is provided
as a service to the customer and goes beyond policing requirements). as a service to the customer and goes beyond policing requirements).
It is possible to mark the DS-field at intermediate routers rather It is possible to mark the DS-field at intermediate routers rather
than at the host and still to realize many of the benefits of our than at the host and still to realize many of the benefits of our
approach. In this case, intermediate routers may use the RSVP signal- approach. In this case, intermediate routers may use the RSVP signal-
ing to configure an MF classifier and marker. Therefore, the confi- ing to configure an MF classifier and marker. Therefore, the confi-
guration of MF classifiers and markers is dynamic (minimizing the guration of MF classifiers and markers is dynamic (minimizing the
skipping to change at page 15, line 5 skipping to change at page 15, line 35
Nonetheless, this approach is necessary to support those hosts which Nonetheless, this approach is necessary to support those hosts which
may be capable of RSVP signaling, but which are not capable of marking may be capable of RSVP signaling, but which are not capable of marking
the DS-field. In addition, there may be cases in which the network the DS-field. In addition, there may be cases in which the network
administrators wish to shift the responsibility for traffic separation administrators wish to shift the responsibility for traffic separation
away from the hosts. In particular, we expect that there will continue away from the hosts. In particular, we expect that there will continue
to be a need for top-down provisioned MF classification, especially to be a need for top-down provisioned MF classification, especially
for qualitative (as opposed to quantitative) QoS applications. for qualitative (as opposed to quantitative) QoS applications.
6. Managing Different Resource Pools 6. Managing Different Resource Pools
Use Of RSVP with Diffserv June, 1998
We have focused largely on the class of applications that use RSVP to We have focused largely on the class of applications that use RSVP to
explicitly signal per-flow QoS requirements and which expect end- to- explicitly signal per-flow QoS requirements and which expect end- to-
end tight QoS assurances, spanning both the intserv and diff-serv end tight QoS assurances, spanning both the intserv and diff-serv
regions of the network. We have been referring to these applications regions of the network. We have been referring to these applications
as 'quantitative QoS applications'. as 'quantitative QoS applications'.
However, diff-serv networks also provide loose QoS to applications However, diff-serv networks also provide loose QoS to applications
that do not explicitly signal. Network managers can allot qualitative that do not explicitly signal. Network managers can allot qualitative
QoS applications specific QoS in the diff-serv network. This is QoS applications specific QoS in the diff-serv network. This is
achieved by configuring classifiers at the ingress to the diff-serv achieved by configuring classifiers at the ingress to the diff-serv
network to recognize traffic from these applications. Thus, the clas- network to recognize traffic from these applications. Thus, the clas-
sification fields are used as a form of implicit signaling. sification fields are used as a form of implicit signaling.
Network administrators must therefore share diff-serv network Network administrators must therefore share diff-serv network
resources between three types of traffic: resources between three types of traffic:
a. Quantitative (explicitly signaled) QoS application traffic a. Quantitative (explicitly signaled) QoS application traffic
b. Qualitative (implicitly signaled) QoS application traffic b. Qualitative (implicitly signaled) QoS application traffic
c. All other (best-effort) traffic c. All other (best-effort) traffic
Use Of RSVP with Diffserv June, 1998
Quantitative QoS applications rely on explicit admission control for Quantitative QoS applications rely on explicit admission control for
their traffic, at the edges of the diff-serv network. This traffic may their traffic, at the edges of the diff-serv network. This traffic may
be refused admission for a particular diff-serv service level. However be refused admission for a particular diff-serv service level. However
- if admitted, the traffic is assured tight QoS. Of course, this is - if admitted, the traffic is assured tight QoS. Of course, this is
true only to the extent that, at any ingress point, the total offered true only to the extent that, at any ingress point, the total offered
traffic at each service level does not exceed the resources requested traffic at each service level does not exceed the resources requested
through the sum of admission control requests. through the sum of admission control requests.
Traffic from qualitative QoS applications is provided with implicit Traffic from qualitative QoS applications is provided with implicit
admission control as a result of policing at ingress points. However, admission control as a result of policing at ingress points. However,
implicit admission control does not provide explicit feedback to implicit admission control does not provide explicit feedback to
applications. Therefore, it is difficult to assure that the total applications. Therefore, it is difficult to assure that the total
traffic offered at an ingress point will not exceed the levels allowed traffic offered at an ingress point will not exceed the provisioned
by policers. Thus, traffic from qualitative applications is offered capacity for a particular service level. When the traffic exceeds the
only loose QoS. 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 From the network manager's perspective, there are three pools of
resources in the diff-serv network; one for traffic sourced by quanti- resources in the diff-serv network; one for traffic sourced by quanti-
tative QoS applications, one for traffic sourced by qualitative QoS tative QoS applications, one for traffic sourced by qualitative QoS
applications and one for best-effort traffic. These pools must be iso- applications and one for best-effort traffic. These pools must be iso-
lated from each other by the appropriate configuration of policers and lated from each other by the appropriate configuration of policers and
classifiers at ingress points to the diff-serv network, and by classifiers at ingress points to the diff-serv network, and by
appropriate provisioning within the diff- serv network. 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 7. Issues
7.1 Setting the DS-field at Hosts 7.1 Setting the DS-field at Hosts
Use Of RSVP with Diffserv June, 1998
The thought of allowing hosts to set the DS-field directly, may alarm The thought of allowing hosts to set the DS-field directly, may alarm
network administrators. The obvious concern is that hosts may attempt network administrators. The obvious concern is that hosts may attempt
to 'steal' resources. In fact, hosts may attempt to exceed the nego- to 'steal' resources. In fact, hosts may attempt to exceed the nego-
tiated capacity at a particular service level regardless of whether tiated capacity at a particular service level regardless of whether
they invoke this service level directly (by setting the DS- byte) or they invoke this service level directly (by setting the DS- byte) or
indirectly (by submitting traffic that classifies in an intermediate indirectly (by submitting traffic that classifies in an intermediate
router to a particular diff-serv PHB). router to a particular diff-serv PHB).
In either case, it may be necessary to protect the network by policing In either case, it may sometimes be necessary to protect the network
at various points, both within the stub network and/or at the inter- by policing at various points, both within the stub network and/or at
face to the transit network. For example, within the stub network, the interface to the transit network. For example, within the stub
routers may police the aggregate traffic coming from a host to ensure network, routers may police the aggregate traffic coming from a host
that the host is not exceeding its traffic limit. This assures protec- to ensure that the host is not exceeding its traffic limit. This
tion against malicious users or malfunctioning equipment and, overall, assures protection against malicious users or malfunctioning equipment
ensures that customers do not use more resources than they are enti-
tled to, at each service level. If the sending host does not do the Use Of RSVP with Diffserv June, 1998
marking, intermediate and/or boundary routers must provide MF classif-
ication, mark and police. If the sending host does do the marking, and, overall, ensures that customers do not use more resources than
these routers need only to provide BA classification and to police the they are entitled to, at each service level. If the sending host does
aggregate to ensure that the customer is not exceeding the aggregate not do the marking, intermediate and/or boundary routers must provide
capacity negotiated for the service level. 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- Requiring hosts to mark the DS-field has the effect of moving respon-
sibility to the edge of the network, in more ways than one. With this sibility to the edge of the network, in more ways than one. With this
approach, boundary routers police in aggregate. As a result, the cus- approach, boundary routers police in aggregate. As a result, the cus-
tomer cannot rely on boundary routers to provide traffic isolation tomer cannot rely on boundary routers to provide traffic isolation
between the customer's flows, when policing or shaping. Instead, it between the customer's flows, when policing or shaping. Instead, it
is the customer's responsibility to ensure that the customer's flows is the customer's responsibility to ensure that the customer's flows
are properly shaped and policed within the customer's sending network. are properly shaped and policed within the customer's sending network.
Overall, this approach simplifies boundary routers and still allows Overall, this approach simplifies boundary routers and still allows
protection against misbehaving hosts/users. protection against misbehaving hosts/users.
skipping to change at page 16, line 49 skipping to change at page 17, line 37
Ideally, hosts should provide per-flow shaping at their sending inter- Ideally, hosts should provide per-flow shaping at their sending inter-
faces. However, there is always a chance that the customer's traffic faces. However, there is always a chance that the customer's traffic
will become distorted as it nears the boundary between the customer will become distorted as it nears the boundary between the customer
and the carrier. In this case, the customer should do per flow polic- 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- 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 work unless the policing agreement at the other side is known to
accommodate the transient bursts that can arise from adding the flows. accommodate the transient bursts that can arise from adding the flows.
In summary, the security concerns of marking the DS-field at the edge In summary, the security concerns of marking the DS-field at the edge
of the network can be dismissed since each carrier will have to do of the network can be dismissed since each carrier will have to do
some for of policing (per-flow or per-host) at their boundary anyway. some form of policing (per-flow or per-host) at their boundary anyway.
Furthermore, this approach reduces the granularity at which boundary Furthermore, this approach reduces the granularity at which boundary
routers must police, thereby pushing finer grain shaping and policing routers must police, thereby pushing finer grain shaping and policing
responsibility to the edges of the network, where it scales better. responsibility to the edges of the network, where it scales better.
The carriers are thus focused on the task of protecting their transit The carriers are thus focused on the task of protecting their transit
Use Of RSVP with Diffserv June, 1998
networks, while the customers are focused on the task of shaping and networks, while the customers are focused on the task of shaping and
policing their own traffic to be in compliance with their negotiated policing their own traffic to be in compliance with their negotiated
token bucket parameters. token bucket parameters.
7.2 End-to-End Integrity of the DS-field 7.2 End-to-End Integrity of the DS-field
Our proposal assumes that hosts use a standard coding for specifying a Our proposal assumes that hosts use a standard coding for specifying a
desired PHB in some sub-field of the DS-field. It also assumes that desired PHB in some sub-field of the DS-field. It also assumes that
packets submitted to the network with a certain PHB specified, will packets submitted to the network with a certain PHB specified, will
receive a standard service throughout the diff-serv network. Strictly receive a standard service throughout the diff-serv network. Strictly
speaking, this does not dictate that the transit network must leave speaking, this does not dictate that the transit network must leave
the PHB field intact. However, we see little value in allowing the PHB the PHB field intact. For example, after a sending host marks the
field to be altered within the network. This is likely to perpetuate
local and incompatible interpretations of the field. Use Of RSVP with Diffserv June, 1998
packets with PHB value based on either the well-known, "default" or
"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 7.3 Carrying RSVP Messages across Transit Networks
Our proposal presumes end-to-end RSVP both as a means for communica- Our proposal presumes end-to-end RSVP both as a means for communica-
tion between sending host and receiving host and optionally, for the tion between sending host and receiving host and optionally, for the
support of true RSVP reservations in stub networks (or in intermediate support of true RSVP reservations in stub networks (or in intermediate
networks which are interested in the fine grain RSVP information). networks which are interested in the fine grain RSVP information).
Therefore, we require that RSVP messages be carried transparently Therefore, we require that RSVP messages be carried transparently
across the transit networks. In [8] mechanisms are proposed for doing 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- so in a manner that does not require the routers in the transit net-
work to understand/interpret RSVP messages and does not adversely work to understand/interpret RSVP messages and does not adversely
impact the transit network. impact the transit network.
8. Dependencies of Intserv on Diff-Serv 8. Dependencies of Intserv on Diff-Serv
We have described a framework for end-to-end QoS in which intserv net- We have described a framework for end-to-end QoS in which intserv net-
works are customers of diff-serv networks. We believe that the bene- works are customers of diff-serv networks. We believe that the bene-
fits of this framework are sufficient to justify the consideration of fits of this framework are sufficient to justify the consideration of
intserv dependencies as diff-serv work proceeds. In particular, we intserv dependencies as diff-serv work proceeds. In particular, we
skipping to change at page 18, line 4 skipping to change at page 18, line 47
network. network.
2. Diff-serv networks must provide admission control information to 2. Diff-serv networks must provide admission control information to
the intserv network. At the very least, this is through static the intserv network. At the very least, this is through static
service level agreements. Preferably, this is through a dynamic service level agreements. Preferably, this is through a dynamic
protocol. If the intserv to diff-serv boundary is implemented in the protocol. If the intserv to diff-serv boundary is implemented in the
transit network boundary routers, then this protocol is RSVP. transit network boundary routers, then this protocol is RSVP.
3. We expect that diff-serv networks will transparently carry RSVP messages 3. We expect that diff-serv networks will transparently carry RSVP messages
such that they can be recovered at the egress point from the diff-serv such that they can be recovered at the egress point from the diff-serv
Use Of RSVP with Diffserv June, 1998
network. network.
9. Security Considerations 9. 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 intserv regions of the network. Therefore, all
RSVP security considerations apply [11]. In addition, network adminis- RSVP security considerations apply [11]. In addition, network
trators are expected to protect network resources by configuring
secure policers at interfaces with untrusted customers. Use Of RSVP with Diffserv June, 1998
administrators are expected to protect network resources by configur-
ing secure policers at interfaces with untrusted customers.
10. References 10. 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
skipping to change at page 19, line 5 skipping to change at page 19, line 41
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 Requests", Internet Draft, November 1997 QoS Requests", Internet Draft, November 1997
[9] Clark, D. and Wroclawski, J., "An Approach to Service [9] Clark, D. and Wroclawski, J., "An Approach to Service
[10] Blake, S. and Nichols, K., "Differentiated Services Operational [10] Blake, S. and Nichols, K., "Differentiated Services Operational
Model and Definitions", Internet Draft, February 1998 Model and Definitions", Internet Draft, February 1998
Use Of RSVP with Diffserv June, 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 the Internet Architecture: an Overview", Internet RFC 1633, June
1994 1994
[13] Garrett, M. W., and Borden, M., "Interoperation of Controlled- [13] Garrett, M. W., and Borden, M., "Interoperation of Controlled-Load
Load Service and Guaranteed Service with ATM", Internet Draft, March
1998 Use Of RSVP with Diffserv June, 1998
[14] Weiss, Walter, "private communication", November 1998.
11. Acknowledgments 11. Acknowledgments
Authors thank the following individuals for their comments that led to
improvements to the previous version(s) of this draft: David Oran,
Andy Veitch, Curtis Villamizer, Walter Weiss, and Russel white.
12. Author's Addresses 12. 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
2111 NE 25th. Avenue, 2111 NE 25th. Avenue,
Hillsboro, OR 97124 Hillsboro, OR 97124
Phone: (503) 264-9077 Phone: (503) 264-9077
Email: yavatkar@ibeam.intel.com Email: raj.yavatkar@intel.com
Peter Ford Peter Ford
Microsoft Microsoft
One Microsoft Way, One Microsoft Way,
Redmond, WA 98052 Redmond, WA 98052
Phone: (425) 703-2032 Phone: (425) 703-2032
Email: peterf@microsoft.com Email: peterf@microsoft.com
Fred Baker Fred Baker
Cisco Systems Cisco Systems
519 Lado Drive, 519 Lado Drive,
Santa Barbara, CA 93111 Santa Barbara, CA 93111
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
Use Of RSVP with Diffserv June, 1998
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
Bay Networks Cisco Systems
Email: Kathleen_Nichols@BayNetworks.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
 End of changes. 74 change blocks. 
175 lines changed or deleted 222 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/