draft-ietf-issll-diffserv-rsvp-04.txt   rfc2998.txt 
Y. Bernet, Microsoft Network Working Group Y. Bernet
R. Yavatkar, Intel Request for Comments: 2998 P. Ford
P. Ford, Microsoft Category: Informational Microsoft
F. Baker, Cisco R. Yavatkar
L. Zhang, UCLA Intel
M. Speer, Sun Microsystems F. Baker
R. Braden, ISI Cisco
B. Davie, Cisco L. Zhang
John Wroclawski, MIT LCS UCLA
E. Felstaine, Allot Communications M. Speer
Internet Draft Sun Microsystems
Expires: September, 2000 R. Braden
Document: draft-ietf-issll-diffserv-rsvp-04.txt March, 2000 ISI
B. Davie
Cisco
J. Wroclawski
MIT LCS
E. Felstaine
SANRAD
November 2000
A Framework For Integrated Services Operation Over Diffserv Networks A Framework for Integrated Services Operation over Diffserv Networks
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. Internet-Drafts are not specify an Internet standard of any kind. Distribution of this
Working documents of the Internet Engineering Task Force (IETF), its memo is unlimited.
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 and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
1. Abstract Abstract
The Integrated Services architecture provides a means for the The Integrated Services (Intserv) architecture provides a means for
delivery of end-to-end QoS to applications over heterogeneous the delivery of end-to-end Quality of Service (QoS) to applications
networks. To support this end-to-end model, the Intserv architecture over heterogeneous networks. To support this end-to-end model, the
must be supported over a wide variety of different types of network Intserv architecture must be supported over a wide variety of
elements. In this context, a network that supports Differentiated different types of network elements. In this context, a network that
Services (Diffserv) may be viewed as a network element in the total supports Differentiated Services (Diffserv) may be viewed as a
end-to-end path. This document describes a framework by which network element in the total end-to-end path. This document
Integrated Services may be supported over Diffserv networks. describes a framework by which Integrated Services may be supported
over Diffserv networks.
Bernet, ed. et al. 1 Table of Contents
Integrated Services Operation Over Diffserv Networks March, 2000 1. Introduction ................................................. 3
1.1 Integrated Services Architecture ............................ 3
1.2 RSVP ........................................................ 3
1.3 Diffserv .................................................... 4
1.4 Roles of Intserv, RSVP and Diffserv ......................... 4
1.5 Components of Intserv, RSVP and Diffserv .................... 5
1.6 The Framework ............................................... 6
1.7 Contents .................................................... 6
2. Benefits of Using Intserv with Diffserv ...................... 7
2.1 Resource Based Admission Control ............................ 7
2.2 Policy Based Admission Control .............................. 8
2.3 Assistance in Traffic Identification/Classification ......... 8
2.3.1 Host Marking .............................................. 9
2.3.2 Router Marking ............................................ 9
2.4 Traffic Conditioning ........................................ 10
3. The Framework ................................................ 10
3.1 Reference Network ........................................... 11
3.1.1 Hosts ..................................................... 11
3.1.2 End-to-End RSVP Signaling ................................. 12
3.1.3 Edge Routers .............................................. 12
3.1.4 Border Routers ............................................ 12
3.1.5 Diffserv Network Region ................................... 13
3.1.6 Non-Diffserv Network Regions .............................. 13
3.2 Service Mapping ............................................. 13
3.2.1 Default Mapping ........................................... 14
3.2.2 Network Driven Mapping .................................... 14
3.2.3 Microflow Separation ...................................... 14
3.3 Resource Management in Diffserv Regions ..................... 15
4. Detailed Examples of the Operation of
Intserv over Diffserv Regions ................................ 16
4.1 Statically Provisioned Diffserv Network Region .............. 16
4.1.1 Sequence of Events in Obtaining End-to-end QoS ............ 16
4.2 RSVP-Aware Diffserv Network Region .......................... 18
4.2.1 Aggregated or Tunneled RSVP ............................... 19
4.2.3 Per-flow RSVP ............................................. 20
4.2.4 Granularity of Deployment of RSVP Aware Routers ........... 20
4.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region ..... 21
5. Implications of the Framework for Diffserv Network Regions ... 21
5.1 Requirements from Diffserv Network Regions .................. 21
5.2 Protection of Intserv Traffic from Other Traffic ............ 22
6. Multicast .................................................... 22
6.1 Remarking of packets in branch point routers ................ 24
6.2 Multicast SLSs and Heterogeneous Trees ...................... 25
7. Security Considerations ...................................... 26
7.1 General RSVP Security ....................................... 26
7.2 Host Marking ................................................ 26
8. Acknowledgments .............................................. 27
9. References ................................................... 27
10. Authors' Addresses .......................................... 29
11. Full Copyright Statement ................................... 31
2. Introduction 1. Introduction
Work on QoS-enabled IP networks has led to two distinct approaches: Work on QoS-enabled IP networks has led to two distinct approaches:
the Integrated Services architecture (Intserv)[10] and its the Integrated Services architecture (Intserv) [10] and its
accompanying signaling protocol, RSVP [1], and the Differentiated accompanying signaling protocol, RSVP [1], and the Differentiated
Services architecture (Diffserv)[8]. This document describes ways in Services architecture (Diffserv) [8]. This document describes ways
which a Diffserv network can be used in the context of the Intserv in which a Diffserv network can be used in the context of the Intserv
architecture to support the delivery of end-to-end QOS. architecture to support the delivery of end-to-end QOS.
2.1 Integrated Services Architecture 1.1 Integrated Services Architecture
The integrated services architecture defined a set of extensions to The integrated services architecture defined a set of extensions to
the traditional best effort model of the Internet with the goal of the traditional best effort model of the Internet with the goal of
allowing end-to-end QOS to be provided to applications. One of the allowing end-to-end QOS to be provided to applications. One of the
key components of the architecture is a set of service definitions; key components of the architecture is a set of service definitions;
the current set of services consists of the controlled load and the current set of services consists of the controlled load and
guaranteed services. The architecture assumes that some explicit guaranteed services. The architecture assumes that some explicit
setup mechanism is used to convey information to routers so that setup mechanism is used to convey information to routers so that they
they can provide requested services to flows that require them. can provide requested services to flows that require them. While
While RSVP is the most widely known example of such a setup RSVP is the most widely known example of such a setup mechanism, the
mechanism, the Intserv architecture is designed to accommodate other Intserv architecture is designed to accommodate other mechanisms.
mechanisms.
Intserv services are implemented by "network elements". While it is Intserv services are implemented by "network elements". While it is
common for network elements to be individual nodes such as routers common for network elements to be individual nodes such as routers or
or links, more complex entities, such as ATM "clouds" or 802.3 links, more complex entities, such as ATM "clouds" or 802.3 networks
networks may also function as network elements. As discussed in more may also function as network elements. As discussed in more detail
detail below, a Diffserv network (or "cloud") may be viewed as a below, a Diffserv network (or "cloud") may be viewed as a network
network element within a larger Intserv network. element within a larger Intserv network.
2.3 RSVP 1.2 RSVP
RSVP is a signaling protocol that applications may use to request RSVP is a signaling protocol that applications may use to request
resources from the network. The network responds by explicitly resources from the network. The network responds by explicitly
admitting or rejecting RSVP requests. Certain applications that have admitting or rejecting RSVP requests. Certain applications that have
quantifiable resource requirements express these requirements using quantifiable resource requirements express these requirements using
Intserv parameters as defined in the appropriate Intserv service Intserv parameters as defined in the appropriate Intserv service
specification. As noted above, RSVP and Intserv are separable. RSVP specification. As noted above, RSVP and Intserv are separable. RSVP
is a signaling protocol which may carry Intserv information. Intserv is a signaling protocol which may carry Intserv information. Intserv
defines the models for expressing service types, quantifying defines the models for expressing service types, quantifying resource
resource requirements and for determining the availability of the requirements and for determining the availability of the requested
requested resources at relevant network elements (admission resources at relevant network elements (admission control).
control).
The current prevailing model of RSVP usage is based on a combined The current prevailing model of RSVP usage is based on a combined
RSVP/Intserv architecture. In this model, RSVP signals per-flow RSVP/Intserv architecture. In this model, RSVP signals per-flow
resource requirements to network elements, using Intserv parameters. resource requirements to network elements, using Intserv parameters.
These network elements apply Intserv admission control to signaled These network elements apply Intserv admission control to signaled
requests. In addition, traffic control mechanisms on the network requests. In addition, traffic control mechanisms on the network
element are configured to ensure that each admitted flow receives element are configured to ensure that each admitted flow receives the
the service requested in strict isolation from other traffic. To service requested in strict isolation from other traffic. To this
end, RSVP signaling configures microflow (MF) [8] packet classifiers
Bernet, ed. et al. 2 in Intserv capable routers along the path of the traffic flow. These
classifiers enable per-flow classification of packets based on IP
Integrated Services Operation Over Diffserv Networks March, 2000 addresses and port numbers.
this end, RSVP signaling configures microflow (MF) [8] packet
classifiers in Intserv capable routers along the path of the traffic
flow. These classifiers enable per-flow classification of packets
based on IP addresses and port numbers.
The following factors have impeded deployment of RSVP (and the The following factors have impeded deployment of RSVP (and the
Intserv architecture) in the Internet at large: Intserv architecture) in the Internet at large:
1. The use of per-flow state and per-flow processing raises 1. The use of per-flow state and per-flow processing raises
scalability concerns for large networks. scalability concerns for large networks.
2. Only a small number of hosts currently generate RSVP signaling. 2. Only a small number of hosts currently generate RSVP signaling.
While this number is expected to grow dramatically, many While this number is expected to grow dramatically, many
applications may never generate RSVP signaling. applications may never generate RSVP signaling.
3. The necessary policy control mechanisms -- access control, 3. The necessary policy control mechanisms -- access control,
authentication, and accounting -- have only recently become authentication, and accounting -- have only recently become
available [17]. available [17].
2.4 Diffserv 1.3 Diffserv
In contrast to the per-flow orientation of RSVP, Diffserv networks In contrast to the per-flow orientation of RSVP, Diffserv networks
classify packets into one of a small number of aggregated flows or classify packets into one of a small number of aggregated flows or
"classes", based on the Diffserv codepoint (DSCP) in the packet's IP "classes", based on the Diffserv codepoint (DSCP) in the packet's IP
header. This is known as behavior aggregate (BA) classification header. This is known as behavior aggregate (BA) classification [8].
[8]. At each Diffserv router, packets are subjected to a "per-hop At each Diffserv router, packets are subjected to a "per-hop
behavior" (PHB), which is invoked by the DSCP. The primary benefit behavior" (PHB), which is invoked by the DSCP. The primary benefit
of Diffserv is its scalability. Diffserv eliminates the need for of Diffserv is its scalability. Diffserv eliminates the need for
per-flow state and per-flow processing and therefore scales well to per-flow state and per-flow processing and therefore scales well to
large networks. large networks.
2.5 Roles of Intserv, RSVP and Diffserv 1.4 Roles of Intserv, RSVP and Diffserv
We view Intserv, RSVP and Diffserv as complementary technologies in We view Intserv, RSVP and Diffserv as complementary technologies in
the pursuit of end-to-end QoS. Together, these mechanisms can the pursuit of end-to-end QoS. Together, these mechanisms can
facilitate deployment of applications such as IP-telephony, video- facilitate deployment of applications such as IP-telephony, video-
on-demand, and various non-multimedia mission-critical applications. on-demand, and various non-multimedia mission-critical applications.
Intserv enables hosts to request per-flow, quantifiable resources, Intserv enables hosts to request per-flow, quantifiable resources,
along end-to-end data paths and to obtain feedback regarding along end-to-end data paths and to obtain feedback regarding
admissibility of these requests. Diffserv enables scalability across admissibility of these requests. Diffserv enables scalability across
large networks. large networks.
2.6 Components of Intserv, RSVP and Diffserv 1.5 Components of Intserv, RSVP and Diffserv
Before proceeding, it is helpful to identify the following Before proceeding, it is helpful to identify the following components
components of the QoS technologies described: of the QoS technologies described:
RSVP signaling - This term refers to the standard RSVP signaling RSVP signaling - This term refers to the standard RSVP signaling
protocol. RSVP signaling is used by hosts to signal application protocol. RSVP signaling is used by hosts to signal application
resource requirements to the network (and to each other). Network resource requirements to the network (and to each other). Network
elements use RSVP signaling to return an admission control decision elements use RSVP signaling to return an admission control decision
to hosts. RSVP signaling may or may not carry Intserv parameters. to hosts. RSVP signaling may or may not carry Intserv parameters.
Bernet, ed. et al. 3
Integrated Services Operation Over Diffserv Networks March, 2000
Admission control at a network element may or may not be based on Admission control at a network element may or may not be based on the
the Intserv model. Intserv model.
MF traffic control - This term refers to traffic control which is MF traffic control - This term refers to traffic control which is
applied independently to individual traffic flows and therefore applied independently to individual traffic flows and therefore
requires recognizing individual traffic flows via MF classification. requires recognizing individual traffic flows via MF classification.
Aggregate traffic control - This term refers to traffic control Aggregate traffic control - This term refers to traffic control which
which is applied collectively to sets of traffic flows. These sets is applied collectively to sets of traffic flows. These sets of
of traffic flows are recognized based on BA (DSCP) classification. traffic flows are recognized based on BA (DSCP) classification. In
In this document, we use the terms "aggregate traffic control" and this document, we use the terms "aggregate traffic control" and
"Diffserv" interchangeably. "Diffserv" interchangeably.
Aggregate RSVP. While the existing definition of RSVP supports only Aggregate RSVP. While the existing definition of RSVP supports only
per-flow reservations, extensions to RSVP are being developed to per-flow reservations, extensions to RSVP are being developed to
enable RSVP reservations to be made for aggregated traffic, i.e. enable RSVP reservations to be made for aggregated traffic, i.e.,
sets of flows that may be recognized by BA classification. This use sets of flows that may be recognized by BA classification. This use
of RSVP may be useful in controlling the allocation of bandwidth in of RSVP may be useful in controlling the allocation of bandwidth in
Diffserv networks. Diffserv networks.
Per-flow RSVP. The conventional usage of RSVP to perform resource Per-flow RSVP. The conventional usage of RSVP to perform resource
reservations for individual microflows. reservations for individual microflows.
RSVP/Intserv - This term is used to refer to the prevailing model of RSVP/Intserv - This term is used to refer to the prevailing model of
RSVP usage which includes RSVP signaling with Intserv parameters, RSVP usage which includes RSVP signaling with Intserv parameters,
Intserv admission control and per-flow traffic control at network Intserv admission control and per-flow traffic control at network
elements. elements.
Diffserv Region. A set of contiguous routers which support BA Diffserv Region. A set of contiguous routers which support BA
classification and traffic control. While such a region may also classification and traffic control. While such a region may also
support MF classification, the goal of this document is to describe support MF classification, the goal of this document is to describe
how such a region may be used in delivery of end-to-end QOS when how such a region may be used in delivery of end-to-end QOS when only
only BA classification is performed inside the Diffserv region. BA classification is performed inside the Diffserv region.
Non-Diffserv Region. The portions of the network outside the Non-Diffserv Region. The portions of the network outside the
Diffserv region. Such a region may also offer a variety of different Diffserv region. Such a region may also offer a variety of different
types of classification and traffic control. types of classification and traffic control.
Note that, for the purposes of this document, the defining features Note that, for the purposes of this document, the defining features
of a Diffserv region is the type of classification and traffic of a Diffserv region is the type of classification and traffic
control that is used for the delivery of end-to-end QOS for a control that is used for the delivery of end-to-end QOS for a
particular application. Thus, while it may not be possible to particular application. Thus, while it may not be possible to
identify a certain region as "purely Diffserv" with respect to all identify a certain region as "purely Diffserv" with respect to all
traffic flowing through the region, it is possible to define it in traffic flowing through the region, it is possible to define it in
this way from the perspective of the treatment of traffic from a this way from the perspective of the treatment of traffic from a
single application. single application.
2.7 The Framework 1.6 The Framework
In the framework we present, end-to-end, quantitative QoS is
provided by applying the Intserv model end-to-end across a network
Bernet, ed. et al. 4
Integrated Services Operation Over Diffserv Networks March, 2000
containing one or more Diffserv regions. The Diffserv regions may, In the framework we present, end-to-end, quantitative QoS is provided
but are not required to, participate in end-to-end RSVP signaling by applying the Intserv model end-to-end across a network containing
for the purpose of optimizing resource allocation and supporting one or more Diffserv regions. The Diffserv regions may, but are not
admission control. required to, participate in end-to-end RSVP signaling for the purpose
of optimizing resource allocation and supporting admission control.
From the perspective of Intserv, Diffserv regions of the network are From the perspective of Intserv, Diffserv regions of the network are
treated as virtual links connecting Intserv capable routers or hosts treated as virtual links connecting Intserv capable routers or hosts
(much as an 802.1p network region is treated as a virtual link in (much as an 802.1p network region is treated as a virtual link in
[5]). Within the Diffserv regions of the network routers implement [5]). Within the Diffserv regions of the network routers implement
specific PHBs (aggregate traffic control). The total amount of specific PHBs (aggregate traffic control). The total amount of
traffic that is admitted into the Diffserv region that will receive traffic that is admitted into the Diffserv region that will receive a
a certain PHB may be limited by policing at the edge. As a result certain PHB may be limited by policing at the edge. As a result we
we expect that the Diffserv regions of the network will be able to expect that the Diffserv regions of the network will be able to
support the Intserv style services requested from the periphery. support the Intserv style services requested from the periphery. In
In our framework, we address the support of end-to-end Integrated our framework, we address the support of end-to-end Integrated
Services over the Diffserv regions of the network. Our goal is to Services over the Diffserv regions of the network. Our goal is to
enable seamless inter-operation. As a result, the network enable seamless inter-operation. As a result, the network
administrator is free to choose which regions of the network act as administrator is free to choose which regions of the network act as
Diffserv regions. In one extreme the Diffserv region is pushed all Diffserv regions. In one extreme the Diffserv region is pushed all
the way to the periphery, with hosts alone having full Intserv the way to the periphery, with hosts alone having full Intserv
capability. In the other extreme, Intserv is pushed all the way to capability. In the other extreme, Intserv is pushed all the way to
the core, with no Diffserv region. the core, with no Diffserv region.
2.8 Contents 1.7 Contents
In section 3 we discuss the benefits that can be realized by using In section 3 we discuss the benefits that can be realized by using
the aggregate traffic control provided by Diffserv network regions the aggregate traffic control provided by Diffserv network regions in
in the broader context of the Intserv architecture. In section 4, we the broader context of the Intserv architecture. In section 4, we
present the framework and the reference network. Section 5 details present the framework and the reference network. Section 5 details
two possible realizations of the framework. Section 6 discusses the two possible realizations of the framework. Section 6 discusses the
implications of the framework for Diffserv. Section 7 presents some implications of the framework for Diffserv. Section 7 presents some
issues specific to multicast flows. issues specific to multicast flows.
3. Benefits of Using Intserv with Diffserv 2. Benefits of Using Intserv with Diffserv
The primary benefit of Diffserv aggregate traffic control is its The primary benefit of Diffserv aggregate traffic control is its
scalability. In this section, we discuss the benefits that scalability. In this section, we discuss the benefits that
interoperation with Intserv can bring to a Diffserv network region. interoperation with Intserv can bring to a Diffserv network region.
Note that this discussion is in the context of servicing Note that this discussion is in the context of servicing quantitative
quantitative QoS applications specifically. By this we mean those QoS applications specifically. By this we mean those applications
applications that are able to quantify their traffic and QoS that are able to quantify their traffic and QoS requirements.
requirements.
3.1 Resource Based Admission Control 2.1 Resource Based Admission Control
In Intserv networks, quantitative QoS applications use an explicit In Intserv networks, quantitative QoS applications use an explicit
setup mechanism (e.g. RSVP) to request resources from the network. setup mechanism (e.g., RSVP) to request resources from the network.
The network may accept or reject these requests in response. This is The network may accept or reject these requests in response. This is
"explicit admission control". Explicit admission control helps to "explicit admission control". Explicit and dynamic admission control
assure that network resources are optimally used. To further helps to assure that network resources are optimally used. To
understand this issue, consider a Diffserv network region providing further understand this issue, consider a Diffserv network region
only aggregate traffic control with no signaling. In the Diffserv providing only aggregate traffic control with no signaling. In the
Diffserv network region, admission control is applied in a relatively
Bernet, ed. et al. 5 static way by provisioning policing parameters at network elements.
For example, a network element at the ingress to a Diffserv network
Integrated Services Operation Over Diffserv Networks March, 2000 region could be provisioned to accept only 50 Kbps of traffic for the
EF DSCP.
network region, admission control is applied implicitly by
provisioning policing parameters at network elements. For example, a
network element at the ingress to a Diffserv network region could be
provisioned to accept only 50 Kbps of traffic for the EF DSCP.
While such implicit admission control does protect the network to While such static forms of admission control do protect the network
some degree, it can be quite ineffective. For example, consider that to some degree, they can be quite ineffective. For example, consider
there may be 10 IP telephony sessions originating outside the that there may be 10 IP telephony sessions originating outside the
Diffserv network region, each requiring 10 Kbps of EF service from Diffserv network region, each requiring 10 Kbps of EF service from
the Diffserv network region. Since the network element protecting the Diffserv network region. Since the network element protecting
the Diffserv network region is provisioned to accept only 50 Kbps of the Diffserv network region is provisioned to accept only 50 Kbps of
traffic for the EF DSCP, it will discard half the offered traffic. traffic for the EF DSCP, it will discard half the offered traffic.
This traffic will be discarded from the aggregation of traffic This traffic will be discarded from the aggregation of traffic marked
marked EF, with no regard to the microflow from which it originated. EF, with no regard to the microflow from which it originated. As a
As a result, it is likely that of the ten IP telephony sessions, result, it is likely that of the ten IP telephony sessions, none will
none will obtain satisfactory service when in fact, there are obtain satisfactory service when in fact, there are sufficient
sufficient resources available in the Diffserv network region to resources available in the Diffserv network region to satisfy five
satisfy five sessions. sessions.
In the case of explicit admission control, the network will signal In the case of explicitly signaled, dynamic admission control, the
rejection in response to requests for resources that would exceed network will signal rejection in response to requests for resources
the 50 Kbps limit. As a result, upstream network elements (including that would exceed the 50 Kbps limit. As a result, upstream network
originating hosts) and applications will have the information they elements (including originating hosts) and applications will have the
require to take corrective action. The application might respond by information they require to take corrective action. The application
refraining from transmitting, or by requesting admission for a might respond by refraining from transmitting, or by requesting
lesser traffic profile. The host operating system might respond by admission for a lesser traffic profile. The host operating system
marking the application's traffic for the DSCP that corresponds to might respond by marking the application's traffic for the DSCP that
best-effort service. Upstream network elements might respond by re- corresponds to best-effort service. Upstream network elements might
marking packets on the rejected flow to a lower service level. In respond by re-marking packets on the rejected flow to a lower service
some cases, it may be possible to reroute traffic over alternate level. In some cases, it may be possible to reroute traffic over
paths or even alternate networks (e.g. the PSTN for voice calls). In alternate paths or even alternate networks (e.g., the PSTN for voice
any case, the integrity of those flows that were admitted would be calls). In any case, the integrity of those flows that were admitted
preserved, at the expense of the flows that were not admitted. Thus, would be preserved, at the expense of the flows that were not
by appointing an Intserv-conversant admission control agent for the admitted. Thus, by appointing an Intserv-conversant admission
Diffserv region of the network it is possible to enhance the service control agent for the Diffserv region of the network it is possible
that the network can provide to quantitative QoS applications. to enhance the service that the network can provide to quantitative
QoS applications.
3.2 Policy Based Admission Control 2.2 Policy Based Admission Control
In network regions where RSVP is used, resource requests can be In network regions where RSVP is used, resource requests can be
intercepted by RSVP-aware network elements and can be reviewed intercepted by RSVP-aware network elements and can be reviewed
against policies stored in policy databases. These resource requests against policies stored in policy databases. These resource requests
securely identify the user and the application for which the securely identify the user and the application for which the
resources are requested. Consequently, the network element is able resources are requested. Consequently, the network element is able
to consider per-user and/or per-application policy when deciding to consider per-user and/or per-application policy when deciding
whether or not to admit a resource request. So, in addition to whether or not to admit a resource request. So, in addition to
optimizing the use of resources in a Diffserv network region (as optimizing the use of resources in a Diffserv network region (as
discussed in 3.1) RSVP conversant admission control agents can be discussed in 3.1) RSVP conversant admission control agents can be
used to apply specific customer policies in determining the specific used to apply specific customer policies in determining the specific
customer traffic flows entitled to use the Diffserv network region's customer traffic flows entitled to use the Diffserv network region's
resources. Customer policies can be used to allocate resources to resources. Customer policies can be used to allocate resources to
specific users and/or applications. specific users and/or applications.
Bernet, ed. et al. 6
Integrated Services Operation Over Diffserv Networks March, 2000
By comparison, in Diffserv network regions without RSVP signaling, By comparison, in Diffserv network regions without RSVP signaling,
policies are typically applied based on the Diffserv customer policies are typically applied based on the Diffserv customer network
network from which traffic originates, not on the originating user from which traffic originates, not on the originating user or
or application within the customer network. application within the customer network.
3.3 Assistance in Traffic Identification/Classification 2.3 Assistance in Traffic Identification/Classification
Within Diffserv network regions, traffic is allotted service based Within Diffserv network regions, traffic is allotted service based on
on the DSCP marked in each packet's IP header. Thus, in order to the DSCP marked in each packet's IP header. Thus, in order to obtain
obtain a particular level of service within the Diffserv network a particular level of service within the Diffserv network region, it
region, it is necessary to effect the marking of the correct DSCP in is necessary to effect the marking of the correct DSCP in packet
packet headers. There are two mechanisms for doing so, host marking headers. There are two mechanisms for doing so, host marking and
and router marking. In the case of host marking, the host operating router marking. In the case of host marking, the host operating
system marks the DSCP in transmitted packets. In the case of router system marks the DSCP in transmitted packets. In the case of router
marking, routers in the network are configured to identify specific marking, routers in the network are configured to identify specific
traffic (typically based on MF classification) and to mark the DSCP traffic (typically based on MF classification) and to mark the DSCP
as packets transit the router. There are advantages and as packets transit the router. There are advantages and
disadvantages to each scheme. Regardless of the scheme used, disadvantages to each scheme. Regardless of the scheme used,
explicit signaling offers significant benefits. explicit signaling offers significant benefits.
3.3.1 Host Marking 2.3.1 Host Marking
In the case of host marking, the host operating system marks the In the case of host marking, the host operating system marks the DSCP
DSCP in transmitted packets. This approach has the benefit of in transmitted packets. This approach has the benefit of shifting
shifting per-flow classification and marking to the source of the per-flow classification and marking to the source of the traffic,
traffic, where it scales best. It also enables the host to make where it scales best. It also enables the host to make decisions
decisions regarding the mark that is appropriate for each regarding the mark that is appropriate for each transmitted packet
transmitted packet and hence the relative importance attached to and hence the relative importance attached to each packet. The host
each packet. The host is generally better equipped to make this is generally better equipped to make this decision than the network.
decision than the network. Furthermore, if IPSEC encryption is used, Furthermore, if IPSEC encryption is used, the host may be the only
the host may be the only device in the network that is able to make device in the network that is able to make a meaningful determination
a meaningful determination of the appropriate marking for each of the appropriate marking for each packet, since various fields such
packet. as port numbers would be unavailable to routers for MF
classification.
Host marking requires that the host be aware of the interpretation Host marking requires that the host be aware of the interpretation of
of DSCPs by the network. This information can be configured into DSCPs by the network. This information can be configured into each
each host. However, such configuration imposes a management burden. host. However, such configuration imposes a management burden.
Alternatively, hosts can use an explicit signaling protocol such as Alternatively, hosts can use an explicit signaling protocol such as
RSVP to query the network to obtain a suitable DSCP or set of DSCPs RSVP to query the network to obtain a suitable DSCP or set of DSCPs
to apply to packets for which a certain Intserv service has been to apply to packets for which a certain Intserv service has been
requested. An example of how this can be achieved is described in requested. An example of how this can be achieved is described in
[14]. [14].
3.3.2 Router Marking 2.3.2 Router Marking
In the case of router marking, MF classification criteria must be In the case of router marking, MF classification criteria must be
configured in the router. This may be done dynamically, by request configured in the router in some way. This may be done dynamically
from the host operating system, or statically via manual (e.g., using COPS provisioning), by request from the host operating
configuration or via automated scripts. system, or statically via manual configuration or via automated
scripts.
Bernet, ed. et al. 7
Integrated Services Operation Over Diffserv Networks March, 2000
There are significant difficulties in doing so statically. There are significant difficulties in doing so statically. In many
Typically, it is desirable to allot service to traffic based on the cases, it is desirable to allot service to traffic based on the
application and/or user originating the traffic. At times it is application and/or user originating the traffic. At times it is
possible to identify packets associated with a specific application possible to identify packets associated with a specific application
by the IP port numbers in the headers. It may also be possible to by the IP port numbers in the headers. It may also be possible to
identify packets originating from a specific user by the source IP identify packets originating from a specific user by the source IP
address. However, such classification criteria may change address. However, such classification criteria may change
frequently. Users may be assigned different IP addresses by DHCP. frequently. Users may be assigned different IP addresses by DHCP.
Applications may use transient ports. To further complicate matters, Applications may use transient ports. To further complicate matters,
multiple users may share an IP address. These factors make it very multiple users may share an IP address. These factors make it very
difficult to manage static configuration of the classification difficult to manage static configuration of the classification
information required to mark traffic in routers. information required to mark traffic in routers.
An attractive alternative to static configuration is to allow host An attractive alternative to static configuration is to allow host
operating systems to signal classification criteria to the router on operating systems to signal classification criteria to the router on
behalf of users and applications. As we will show later in this behalf of users and applications. As we will show later in this
document, RSVP signaling is ideally suited for this task. In document, RSVP signaling is ideally suited for this task. In
addition to enabling dynamic and accurate updating of MF addition to enabling dynamic and accurate updating of MF
classification criteria, RSVP signaling enables classification of classification criteria, RSVP signaling enables classification of
IPSEC [13] packets (by use of the SPI) which would otherwise be IPSEC [13] packets (by use of the SPI) which would otherwise be
unrecognizable. unrecognizable.
3.4 Traffic Conditioning 2.4 Traffic Conditioning
Intserv-capable network elements are able to condition traffic at a Intserv-capable network elements are able to condition traffic at a
per-flow granularity, by some combination of shaping and/or per-flow granularity, by some combination of shaping and/or policing.
policing. Pre-conditioning traffic in this manner before it is Pre-conditioning traffic in this manner before it is submitted to the
submitted to the Diffserv region of the network is beneficial. In Diffserv region of the network is beneficial. In particular, it
particular, it enhances the ability of the Diffserv region of the enhances the ability of the Diffserv region of the network to provide
network to provide quantitative services using aggregate traffic quantitative services using aggregate traffic control.
control.
4. The Framework 3. The Framework
In the general framework we envision an Internet in which the In the general framework we envision an Internet in which the
Integrated Services architecture is used to deliver end-to-end QOS Integrated Services architecture is used to deliver end-to-end QOS to
to applications. The network includes some combination of Intserv applications. The network includes some combination of Intserv
capable nodes (in which MF classification and per-flow traffic capable nodes (in which MF classification and per-flow traffic
control is applied) and Diffserv regions (in which aggregate traffic control is applied) and Diffserv regions (in which aggregate traffic
control is applied). Individual routers may or may not participate control is applied). Individual routers may or may not participate
in RSVP signaling regardless of where in the network they reside. in RSVP signaling regardless of where in the network they reside.
We will consider two specific realizations of the framework. In the We will consider two specific realizations of the framework. In the
first, resources within the Diffserv regions of the network are first, resources within the Diffserv regions of the network are
statically provisioned and these regions include no RSVP aware statically provisioned and these regions include no RSVP aware
devices. In the second, resources within the Diffserv region of the devices. In the second, resources within the Diffserv region of the
network are dynamically provisioned and select devices within the network are dynamically provisioned and select devices within the
Diffserv network regions participate in RSVP signaling. Diffserv network regions participate in RSVP signaling.
4.1 Reference Network 3.1 Reference Network
Bernet, ed. et al. 8
Integrated Services Operation Over Diffserv Networks March, 2000
The two realizations of the framework will be discussed in the The two realizations of the framework will be discussed in the
context of the following reference network: context of the following reference network:
________ ______________ ________ ________ ______________ ________
/ \ / \ / \ / \ / \ / \
/ \ / \ / \ / \ / \ / \
|---| | |---| |---| |---| |---| | |---| |---| | |---| |---| |---| |---| | |---|
|Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx | |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx |
|---| | |-- | |---| |---| |---| | |---| |---| | |-- | |---| |---| |---| | |---|
\ / \ / \ / \ / \ / \ /
\________/ \______________/ \________/ \________/ \______________/ \________/
Non-Diffserv region Diffserv region Non-Diffserv region Non-Diffserv region Diffserv region Non-Diffserv region
Figure 1: Sample Network Configuration Figure 1: Sample Network Configuration
The reference network includes a Diffserv region in the middle of a The reference network includes a Diffserv region in the middle of a
larger network supporting Intserv end-to-end. The Diffserv region larger network supporting Intserv end-to-end. The Diffserv region
contains a mesh of routers, at least some of which provide aggregate contains a mesh of routers, at least some of which provide aggregate
traffic control. The regions outside the Diffserv region (non- traffic control. The regions outside the Diffserv region (non-
Diffserv regions) contain meshes of routers and attached hosts, at Diffserv regions) contain meshes of routers and attached hosts, at
least some of which support the Integrated Services architecture. least some of which support the Integrated Services architecture.
In the interest of simplicity we consider a single QoS sender, Tx In the interest of simplicity we consider a single QoS sender, Tx
communicating across this network with a single QoS receiver, Rx. communicating across this network with a single QoS receiver, Rx.
The edge routers (ER1, ER2) which are adjacent to the Diffserv The edge routers (ER1, ER2) which are adjacent to the Diffserv region
region interface to the border routers (BR1, BR2) within the interface to the border routers (BR1, BR2) within the Diffserv
Diffserv region. region.
From an economic viewpoint, we may consider that the Diffserv region From an economic viewpoint, we may consider that the Diffserv region
sells service to the network outside the Diffserv region, which in sells service to the network outside the Diffserv region, which in
turn provides service to hosts. Thus, we may think of the non- turn provides service to hosts. Thus, we may think of the non-
Diffserv regions as clients or customers of the Diffserv region. In Diffserv regions as clients or customers of the Diffserv region. In
the following, we use the term "customer" for the non-Diffserv the following, we use the term "customer" for the non-Diffserv
regions. Note that the boundaries of the regions may or may not regions. Note that the boundaries of the regions may or may not
align with administrative domain boundaries, and that a single align with administrative domain boundaries, and that a single region
region might contain multiple administrative domains. might contain multiple administrative domains.
We now define the major components of the reference network. We now define the major components of the reference network.
4.1.1 Hosts 3.1.1 Hosts
We assume that both sending and receiving hosts use RSVP to We assume that both sending and receiving hosts use RSVP to
communicate the quantitative QoS requirements of QoS-aware communicate the quantitative QoS requirements of QoS-aware
applications running on the host. In principle, other mechanisms may applications running on the host. In principle, other mechanisms may
be used to establish resource reservations in Intserv-capable nodes, be used to establish resource reservations in Intserv-capable nodes,
but RSVP is clearly the prevalent mechanism for this purpose. but RSVP is clearly the prevalent mechanism for this purpose.
Typically, a QoS process within the host operating system generates Typically, a QoS process within the host operating system generates
RSVP signaling on behalf of applications. This process may also RSVP signaling on behalf of applications. This process may also
invoke local traffic control. invoke local traffic control.
Bernet, ed. et al. 9
Integrated Services Operation Over Diffserv Networks March, 2000
As discussed above, traffic control in the host may mark the DSCP in As discussed above, traffic control in the host may mark the DSCP in
transmitted packets, and shape transmitted traffic to the transmitted packets, and shape transmitted traffic to the
requirements of the Intserv service in use. Alternatively, the first requirements of the Intserv service in use. Alternatively, the first
Intserv-capable router downstream from the host may provide these Intserv-capable router downstream from the host may provide these
traffic control functions. traffic control functions.
4.1.2 End-to-End RSVP Signaling 3.1.2 End-to-End RSVP Signaling
We assume that RSVP signaling messages travel end-to-end between We assume that RSVP signaling messages travel end-to-end between
hosts Tx and Rx to support RSVP/Intserv reservations outside the hosts Tx and Rx to support RSVP/Intserv reservations outside the
Diffserv network region. We require that these end-to-end RSVP Diffserv network region. We require that these end-to-end RSVP
messages are at least carried across the Diffserv region. Depending messages are at least carried across the Diffserv region. Depending
on the specific realization of the framework, these messages may be on the specific realization of the framework, these messages may be
processed by none, some or all of the routers in the Diffserv processed by none, some or all of the routers in the Diffserv region.
region.
4.1.3 Edge Routers 3.1.3 Edge Routers
ER1 and ER2 are edge routers, residing adjacent to the Diffserv ER1 and ER2 are edge routers, residing adjacent to the Diffserv
network regions. The functionality of the edge routers varies network regions. The functionality of the edge routers varies
depending on the specific realization of the framework. In the case depending on the specific realization of the framework. In the case
in which the Diffserv network region is RSVP unaware, edge routers in which the Diffserv network region is RSVP unaware, edge routers
act as admission control agents to the Diffserv network. They act as admission control agents to the Diffserv network. They
process signaling messages from both Tx and Rx, and apply admission process signaling messages from both Tx and Rx, and apply admission
control based on resource availability within the Diffserv network control based on resource availability within the Diffserv network
region and on customer defined policy. In the case in which the region and on customer defined policy. In the case in which the
Diffserv network region is RSVP aware, the edge routers apply Diffserv network region is RSVP aware, the edge routers apply
admission control based on local resource availability and on admission control based on local resource availability and on
customer defined policy. In this case, the border routers act as the customer defined policy. In this case, the border routers act as the
admission control agent to the Diffserv network region. admission control agent to the Diffserv network region.
We will later describe the functionality of the edge routers in We will later describe the functionality of the edge routers in
greater depth for each of the two realizations of the framework. greater depth for each of the two realizations of the framework.
4.1.4 Border Routers 3.1.4 Border Routers
BR1 and BR2 are border routers, residing in the Diffserv network BR1 and BR2 are border routers, residing in the Diffserv network
region. The functionality of the border routers varies depending on region. The functionality of the border routers varies depending on
the specific realization of the framework. In the case in which the the specific realization of the framework. In the case in which the
Diffserv network region is RSVP-unaware, these routers act as pure Diffserv network region is RSVP-unaware, these routers act as pure
Diffserv routers. As such, their sole responsibility is to police Diffserv routers. As such, their sole responsibility is to police
submitted traffic based on the service level specified in the DSCP submitted traffic based on the service level specified in the DSCP
and the agreement negotiated with the customer (aggregate traffic and the agreement negotiated with the customer (aggregate
control). In the case in which the Diffserv network region is RSVP- trafficcontrol). In the case in which the Diffserv network region is
aware, the border routers participate in RSVP signaling and act as RSVP-aware, the border routers participate in RSVP signaling and act
admission control agents for the Diffserv network region. as admission control agents for the Diffserv network region.
We will later describe the functionality of the border routers in We will later describe the functionality of the border routers in
greater depth for each of the two realizations of the framework. greater depth for each of the two realizations of the framework.
Bernet, ed. et al. 10 3.1.5 Diffserv Network Region
Integrated Services Operation Over Diffserv Networks March, 2000
4.1.5 Diffserv Network Region
The Diffserv network region supports aggregate traffic control and The Diffserv network region supports aggregate traffic control and is
is assumed not to be capable of MF classification. Depending on the assumed not to be capable of MF classification. Depending on the
specific realization of the framework, some number of routers within specific realization of the framework, some number of routers within
the Diffserv region may be RSVP aware and therefore capable of per- the Diffserv region may be RSVP aware and therefore capable of per-
flow signaling and admission control. If devices in the Diffserv flow signaling and admission control. If devices in the Diffserv
region are not RSVP aware, they will pass RSVP messages region are not RSVP aware, they will pass RSVP messages transparently
transparently with negligible performance impact (see [6]). with negligible performance impact (see [6]).
The Diffserv network region provides two or more levels of service The Diffserv network region provides two or more levels of service
based on the DSCP in packet headers. It may be a single based on the DSCP in packet headers. It may be a single
administrative domain or may span multiple domains. administrative domain or may span multiple domains.
4.1.5 Non-Diffserv Network Regions 3.1.6 Non-Diffserv Network Regions
The network outside of the Diffserv region consists of Intserv The network outside of the Diffserv region consists of Intserv
capable hosts and other network elements. Other elements may include capable hosts and other network elements. Other elements may include
routers and perhaps various types of network (e.g. 802, ATM, etc.). routers and perhaps various types of network (e.g., 802, ATM, etc.).
These network elements may reasonably be assumed to support Intserv, These network elements may reasonably be assumed to support Intserv,
although this might not be required in the case of over- although this might not be required in the case of over-provisioning.
provisioning. Even if these elements are not Intserv capable, we Even if these elements are not Intserv capable, we assume that they
assume that they will pass RSVP messages unhindered. Routers outside will pass RSVP messages unhindered. Routers outside of the Diffserv
of the Diffserv network region are not precluded from providing network region are not precluded from providing aggregate traffic
aggregate traffic control to some subset of the traffic passing control to some subset of the traffic passing through them.
through them.
4.2 Service Mapping 3.2 Service Mapping
Intserv service requests specify an Intserv service type and a set Intserv service requests specify an Intserv service type and a set of
of quantitative parameters known as a "flowspec". At each hop in an quantitative parameters known as a "flowspec". At each hop in an
Intserv network, the Intserv service requests are interpreted in a Intserv network, the Intserv service requests are interpreted in a
form meaningful to the specific link layer medium. For example at form meaningful to the specific link layer medium. For example at an
an 802.1 hop, the Intserv parameters are mapped to an appropriate 802.1 hop, the Intserv parameters are mapped to an appropriate 802.1p
802.1p priority level [5]. priority level [5].
In our framework, Diffserv regions of the network are analogous to In our framework, Diffserv regions of the network are analogous to
the 802.1p capable switched segments described in [5]. Requests for the 802.1p capable switched segments described in [5]. Requests for
Intserv services must be mapped onto the underlying capabilities of Intserv services must be mapped onto the underlying capabilities of
the Diffserv network region. Aspects of the mapping include: the Diffserv network region. Aspects of the mapping include:
- selecting an appropriate PHB, or set of PHBs, for the requested - selecting an appropriate PHB, or set of PHBs, for the requested
service; service;
- performing appropriate policing (including, perhaps, shaping or - performing appropriate policing (including, perhaps, shaping or
remarking) at the edges of the Diffserv region; remarking) at the edges of the Diffserv region;
- exporting Intserv parameters from the Diffserv region (e.g. for - exporting Intserv parameters from the Diffserv region (e.g., for
the updating of ADSPECs); the updating of ADSPECs);
- performing admission control on the Intserv requests that takes - performing admission control on the Intserv requests that takes
into account the resource availability in the Diffserv region. into account the resource availability in the Diffserv region.
Bernet, ed. et al. 11
Integrated Services Operation Over Diffserv Networks March, 2000
Exactly how these functions are performed will be a function of the Exactly how these functions are performed will be a function of the
way bandwidth is managed inside the Diffserv network region, which way bandwidth is managed inside the Diffserv network region, which is
is a topic we discuss in Section 4.3. a topic we discuss in Section 4.3.
When the PHB (or set of PHBs) has been selected for a particular When the PHB (or set of PHBs) has been selected for a particular
Intserv flow, it may be necessary to communicate the choice of DSCP Intserv flow, it may be necessary to communicate the choice of DSCP
for the flow to other network elements. Two schemes may be used to for the flow to other network elements. Two schemes may be used to
achieve this end, as discussed below. achieve this end, as discussed below.
4.2.1 Default Mapping 3.2.1 Default Mapping
In this scheme, there is some standard, well-known mapping from In this scheme, there is some standard, well-known mapping from
Intserv service type to a DSCP that will invoke the appropriate Intserv service type to a DSCP that will invoke the appropriate
behavior in the Diffserv network. behavior in the Diffserv network.
4.2.2 Network Driven Mapping 3.2.2 Network Driven Mapping
In this scheme, RSVP conversant routers in the Diffserv network In this scheme, RSVP conversant routers in the Diffserv network
region (perhaps at its edge) may override the well-known mapping region (perhaps at its edge) may override the well-known mapping
described in 4.2.1. In the case that DSCPs are marked at the ingress described in 4.2.1. In the case that DSCPs are marked at the ingress
to the Diffserv region, the DSCPs can simply be remarked at the to the Diffserv region, the DSCPs can simply be remarked at the
boundary routers. However, in the case that DSCP marking occurs boundary routers. However, in the case that DSCP marking occurs
upstream of the Diffserv region, either in a host or a router, then upstream of the Diffserv region, either in a host or a router, then
the appropriate mapping needs to be communicated upstream, to the the appropriate mapping needs to be communicated upstream, to the
marking device. This may be accomplished using RSVP, as described marking device. This may be accomplished using RSVP, as described in
in [14]. [14].
The decision regarding where to mark DSCP and whether to override The decision regarding where to mark DSCP and whether to override the
the well-known service mapping is a mater of policy to be decided by well-known service mapping is a mater of policy to be decided by the
the administrator of the Diffserv network region in cooperation with administrator of the Diffserv network region in cooperation with the
the administrator of the network adjacent to the Diffserv region. administrator of the network adjacent to the Diffserv region.
4.2.3 Microflow Separation 3.2.3 Microflow Separation
Boundary routers residing at the edge of the Diffserv region will Boundary routers residing at the edge of the Diffserv region will
typically police traffic submitted from the outside the Diffserv typically police traffic submitted from the outside the Diffserv
region in order to protect resources within the Diffserv region. region in order to protect resources within the Diffserv region.
This policing will be applied on an aggregate basis, with no regard This policing will be applied on an aggregate basis, with no regard
for the individual microflows making up each aggregate. As a result, for the individual microflows making up each aggregate. As a result,
it is possible for a misbehaving microflow to claim more than its it is possible for a misbehaving microflow to claim more than its
fair share of resources within the aggregate, thereby degrading the fair share of resources within the aggregate, thereby degrading the
service provided to other microflows. This problem may be addressed service provided to other microflows. This problem may be addressed
by: by:
1. Providing per microflow policing at the edge routers - this is 1. Providing per microflow policing at the edge routers - this is
generally the most appropriate location for microflow policing, generally the most appropriate location for microflow policing, since
since it pushes per-flow work to the edges of the network, where it it pushes per-flow work to the edges of the network, where it scales
scales better. In addition, since Intserv-capable routers outside better. In addition, since Intserv-capable routers outside the
the Diffserv region are responsible for providing microflow service Diffserv region are responsible for providing microflow service to
to their customers and the Diffserv region is responsible for their customers and the Diffserv region is responsible for providing
providing aggregate service to its customers, this distribution of aggregate service to its customers, this distribution of
functionality mirrors the distribution of responsibility. functionality mirrors the distribution of responsibility.
Bernet, ed. et al. 12
Integrated Services Operation Over Diffserv Networks March, 2000
2. Providing per microflow policing at the border routers - this 2. Providing per microflow policing at the border routers - this
approach tends to be less scalable than the previous approach. It approach tends to be less scalable than the previous approach. It
also imposes a management burden on the Diffserv region of the also imposes a management burden on the Diffserv region of the
network. However, it may be appropriate in certain cases, for the network. However, it may be appropriate in certain cases, for the
Diffserv boundary routers to offer per microflow policing as a Diffserv boundary routers to offer per microflow policing as a
value-add to its Intserv customers. value-add to its Intserv customers.
3. Relying on upstream shaping and policing - in certain cases, the 3. Relying on upstream shaping and policing - in certain cases, the
customer may trust the shaping of certain groups of hosts customer may trust the shaping of certain groups of hosts
sufficiently to not warrant reshaping or policing at the boundary of sufficiently to not warrant reshaping or policing at the boundary of
the Diffserv region. Note that, even if the hosts are shaping the Diffserv region. Note that, even if the hosts are shaping
microflows properly, these shaped flows may become distorted as they microflows properly, these shaped flows may become distorted as they
transit through the non-Diffserv region of the network. Depending on transit through the non-Diffserv region of the network. Depending on
the degree of distortion, it may be necessary to somewhat over- the degree of distortion, it may be necessary to somewhat over-
provision the aggregate capacities in the Diffserv region, or to re- provision the aggregate capacities in the Diffserv region, or to re-
police using either 1 or 2 above. police using either 1 or 2 above. The choice of one mechanism or
The choice of one mechanism or another is a matter of policy to be another is a matter of policy to be decided by the administrator of
decided by the administrator of the network outside the Diffserv the network outside the Diffserv region.
region.
4.3 Resource Management in Diffserv Regions 3.3 Resource Management in Diffserv Regions
A variety of options exist for management of resources (e.g., A variety of options exist for management of resources (e.g.,
bandwidth) in the Diffserv network regions to meet the needs of end- bandwidth) in the Diffserv network regions to meet the needs of end-
to-end Intserv flows. These options include: to-end Intserv flows. These options include:
- statically provisioned resources; - statically provisioned resources;
- resources dynamically provisioned by RSVP; - resources dynamically provisioned by RSVP;
- resources dynamically provisioned by other means (e.g., a form of - resources dynamically provisioned by other means (e.g., a form of
Bandwidth Broker). Bandwidth Broker).
Some of the details of using each of these different approaches are Some of the details of using each of these different approaches are
discussed in the following section. discussed in the following section.
5. Detailed Examples of the Operation of Intserv over Diffserv Regions 4. Detailed Examples of the Operation of Intserv over Diffserv Regions
In this section we provide detailed examples of our framework in In this section we provide detailed examples of our framework in
action. We discuss two examples, one in which the Diffserv network action. We discuss two examples, one in which the Diffserv network
region is RSVP unaware, the other in which the Diffserv network region is RSVP unaware, the other in which the Diffserv network
region is RSVP aware. region is RSVP aware.
5.1 Statically Provisioned Diffserv Network Region 4.1 Statically Provisioned Diffserv Network Region
In this example, no devices in the Diffserv network region are RSVP In this example, no devices in the Diffserv network region are RSVP
aware. The Diffserv network region is statically provisioned. The aware. The Diffserv network region is statically provisioned. The
customer(s) of the Diffserv network regions and the owner of the customer(s) of the Diffserv network regions and the owner of the
Diffserv network region have negotiated a static contract (service Diffserv network region have negotiated a static contract (service
level specification, or SLS) for the transmit capacity to be level specification, or SLS) for the transmit capacity to be provided
provided to the customer at each of a number of standard Diffserv to the customer at each of a number of standard Diffserv service
service levels. The "transmit capacity" may be simply an amount of levels. The "transmit capacity" may be simply an amount of bandwidth
or it could be a more complex "profile" involving a number of factors
Bernet, ed. et al. 13 such as burst size, peak rate, time of day etc.
Integrated Services Operation Over Diffserv Networks March, 2000
bandwidth or it could be a more complex "profile" involving a number
of factors such as burst size, peak rate, time of day etc.
It is helpful to consider each edge router in the customer network It is helpful to consider each edge router in the customer network as
as consisting of two halves, a standard Intserv half, which consisting of two halves, a standard Intserv half, which interfaces
interfaces to the customer's network regions and a Diffserv half to the customer's network regions and a Diffserv half which
which interfaces to the Diffserv network region. The Intserv half is interfaces to the Diffserv network region. The Intserv half is able
able to identify and process traffic on per-flow granularity. to identify and process traffic on per-flow granularity.
The Diffserv half of the router can be considered to consist of a The Diffserv half of the router can be considered to consist of a
number of virtual transmit interfaces, one for each Diffserv service number of virtual transmit interfaces, one for each Diffserv service
level negotiated in the SLS. The router contains a table that level negotiated in the SLS. The router contains a table that
indicates the transmit capacity provisioned, per the SLS at each indicates the transmit capacity provisioned, per the SLS at each
Diffserv service level. This table, in conjunction with the default Diffserv service level. This table, in conjunction with the default
mapping described in 4.2.1, is used to perform admission control mapping described in 4.2.1, is used to perform admission control
decisions on Intserv flows which cross the Diffserv network region. decisions on Intserv flows which cross the Diffserv network region.
5.1.1 Sequence of Events in Obtaining End-to-end QoS 4.1.1 Sequence of Events in Obtaining End-to-end QoS
The following sequence illustrates the process by which an The following sequence illustrates the process by which an
application obtains end-to-end QoS when RSVP is used by the hosts. application obtains end-to-end QoS when RSVP is used by the hosts.
1. The QoS process on the sending host Tx generates an RSVP PATH 1. The QoS process on the sending host Tx generates an RSVP PATH
message that describes the traffic offered by the sending message that describes the traffic offered by the sending
application. application.
2. The PATH message is carried toward the receiving host, Rx. In the 2. The PATH message is carried toward the receiving host, Rx. In the
network region to which the sender is attached, standard network region to which the sender is attached, standard RSVP/Intserv
RSVP/Intserv processing is applied at capable network elements. processing is applied at capable network elements.
3. At the edge router ER1, the PATH message is subjected to standard 3. At the edge router ER1, the PATH message is subjected to standard
RSVP processing and PATH state is installed in the router. The PATH RSVP processing and PATH state is installed in the router. The PATH
message is sent onward to the Diffserv network region. message is sent onward to the Diffserv network region.
4. The PATH message is ignored by routers in the Diffserv network 4. The PATH message is ignored by routers in the Diffserv network
region and then processed at ER2 according to standard RSVP region and then processed at ER2 according to standard RSVP
processing rules. processing rules.
5. When the PATH message reaches the receiving host Rx, the 5. When the PATH message reaches the receiving host Rx, the operating
operating system generates an RSVP RESV message, indicating interest system generates an RSVP RESV message, indicating interest in offered
in offered traffic of a certain Intserv service type. traffic of a certain Intserv service type.
6. The RESV message is carried back towards the Diffserv network 6. The RESV message is carried back towards the Diffserv network
region and the sending host. Consistent with standard RSVP/Intserv region and the sending host. Consistent with standard RSVP/Intserv
processing, it may be rejected at any RSVP-capable node in the path processing, it may be rejected at any RSVP-capable node in the path
if resources are deemed insufficient to carry the traffic requested. if resources are deemed insufficient to carry the traffic requested.
7. At ER2, the RESV message is subjected to standard RSVP/Intserv 7. At ER2, the RESV message is subjected to standard RSVP/Intserv
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 Diffserv network region, arriving at ER1. through the Diffserv network region, arriving at ER1.
Bernet, ed. et al. 14
Integrated Services Operation Over Diffserv Networks March, 2000
8. In ER1, the RESV message triggers admission control processing. 8. In ER1, the RESV message triggers admission control processing.
ER1 compares the resources requested in the RSVP/Intserv request to ER1 compares the resources requested in the RSVP/Intserv request to
the resources available in the Diffserv network region at the the resources available in the Diffserv network region at the
corresponding Diffserv service level. The corresponding service corresponding Diffserv service level. The corresponding service
level is determined by the Intserv to Diffserv mapping discussed level is determined by the Intserv to Diffserv mapping discussed
previously. The availability of resources is determined by the previously. The availability of resources is determined by the
capacity provisioned in the SLS. ER1 may also apply a policy capacity provisioned in the SLS. ER1 may also apply a policy
decision such that the resource request may be rejected based on the decision such that the resource request may be rejected based on the
customer's specific policy criteria, even though the aggregate customer's specific policy criteria, even though the aggregate
resources are determined to be available per the SLS. resources are determined to be available per the SLS.
9. If ER1 approves the request, the RESV message is admitted and is 9. If ER1 approves the request, the RESV message is admitted and is
allowed to continue upstream towards the sender. If it rejects the allowed to continue upstream towards the sender. If it rejects the
request, the RESV is not forwarded and the appropriate RSVP error request, the RESV is not forwarded and the appropriate RSVP error
messages are sent. If the request is approved, ER1 updates its messages are sent. If the request is approved, ER1 updates its
internal tables to indicate the reduced capacity available at the internal tables to indicate the reduced capacity available at the
admitted service level on its transmit interface. admitted service level on its transmit interface.
10. The RESV message proceeds through the network region to which 10. The RESV message proceeds through the network region to which the
the sender is attached. Any RSVP node in this region may reject the sender is attached. Any RSVP node in this region may reject the
reservation request due to inadequate resources or policy. If the reservation request due to inadequate resources or policy. If the
request is not rejected, the RESV message will arrive at the sending request is not rejected, the RESV message will arrive at the sending
host, Tx. host, Tx.
11. At Tx, the QoS process receives the RESV message. It interprets 11. At Tx, the QoS process receives the RESV message. It interprets
receipt of the message as indication that the specified traffic flow receipt of the message as indication that the specified traffic flow
has been admitted for the specified Intserv service type (in the has been admitted for the specified Intserv service type (in the
Intserv-capable nodes). It may also learn the appropriate DSCP Intserv-capable nodes). It may also learn the appropriate DSCP
marking to apply to packets for this flow from information provided marking to apply to packets for this flow from information provided
in the RESV. in the RESV.
12. Tx may mark the DSCP in the headers of packets that are 12. Tx may mark the DSCP in the headers of packets that are
transmitted on the admitted traffic flow. The DSCP may be the transmitted on the admitted traffic flow. The DSCP may be the
default value which maps to the Intserv service type specified in default value which maps to the Intserv service type specified in the
the admitted RESV message, or it may be a value explicitly provided admitted RESV message, or it may be a value explicitly provided in
in the RESV. the RESV.
In this manner, we obtain end-to-end QoS through a combination of In this manner, we obtain end-to-end QoS through a combination of
networks that support RSVP/Intserv and networks that support networks that support RSVP/Intserv and networks that support
Diffserv. Diffserv.
5.2 RSVP-Aware Diffserv Network Region 4.2 RSVP-Aware Diffserv Network Region
In this example, the customer's edge routers are standard RSVP In this example, the customer's edge routers are standard RSVP
routers. The border router, BR1 is RSVP aware. In addition, there routers. The border router, BR1 is RSVP aware. In addition, there
may be other routers within the Diffserv network region which are may be other routers within the Diffserv network region which are
RSVP aware. Note that although these routers are able to participate RSVP aware. Note that although these routers are able to participate
in some form of RSVP signaling, they classify and schedule traffic in some form of RSVP signaling, they classify and schedule traffic in
in aggregate, based on DSCP, not on the per-flow classification aggregate, based on DSCP, not on the per-flow classification criteria
criteria used by standard RSVP/Intserv routers. It can be said that used by standard RSVP/Intserv routers. It can be said that their
their control-plane is RSVP while their data-plane is Diffserv. This control-plane is RSVP while their data-plane is Diffserv. This
Bernet, ed. et al. 15
Integrated Services Operation Over Diffserv Networks March, 2000
approach exploits the benefits of RSVP signaling while maintaining approach exploits the benefits of RSVP signaling while maintaining
much of the scalability associated with Diffserv. much of the scalability associated with Diffserv.
In the preceding example, there is no signaling between the Diffserv In the preceding example, there is no signaling between the Diffserv
network region and network elements outside it. The negotiation of network region and network elements outside it. The negotiation of
an SLS is the only explicit exchange of resource availability an SLS is the only explicit exchange of resource availability
information between the two network regions. ER1 is configured with information between the two network regions. ER1 is configured with
the information represented by the SLS and as such, is able to act the information represented by the SLS and as such, is able to act as
as an admission control agent for the Diffserv network region. Such an admission control agent for the Diffserv network region. Such
configuration does not readily support dynamically changing SLSs, configuration does not readily support dynamically changing SLSs,
since ER1 requires reconfiguration each time the SLS changes. It is since ER1 requires reconfiguration each time the SLS changes. It is
also difficult to make efficient use of the resources in the also difficult to make efficient use of the resources in the Diffserv
Diffserv network region. This is because admission control does not network region. This is because admission control does not consider
consider the availability of resources in the Diffserv network the availability of resources in the Diffserv network region along
region along the specific path that would be impacted. the specific path that would be impacted.
By contrast, when the Diffserv network region is RSVP aware, the By contrast, when the Diffserv network region is RSVP aware, the
admission control agent is part of the Diffserv network. As a admission control agent is part of the Diffserv network. As a
result, changes in the capacity available in the Diffserv network result, changes in the capacity available in the Diffserv network
region can be indicated to the Intserv-capable nodes outside the region can be indicated to the Intserv-capable nodes outside the
Diffserv region via RSVP. By including routers interior to the Diffserv region via RSVP. By including routers interior to the
Diffserv network region in RSVP signaling, it is possible to Diffserv network region in RSVP signaling, it is possible to
simultaneously improve the efficiency of resource usage within the simultaneously improve the efficiency of resource usage within the
Diffserv region and to improve the level of confidence that the Diffserv region and to improve the level of confidence that the
resources requested at admission control are indeed available at resources requested at admission control are indeed available at this
this particular point in time. This is because admission control can particular point in time. This is because admission control can be
be linked to the availability of resources along the specific path linked to the availability of resources along the specific path that
that would be impacted. We refer to this benefit of RSVP signaling would be impacted. We refer to this benefit of RSVP signaling as
as "topology aware admission control". A further benefit of "topology aware admission control". A further benefit of supporting
supporting RSVP signaling within the Diffserv network region is that RSVP signaling within the Diffserv network region is that it is
it is possible to effect changes in the provisioning of the Diffserv possible to effect changes in the provisioning of the Diffserv
network region (e.g., allocating more or less bandwidth to the EF network region (e.g., allocating more or less bandwidth to the EF
queue in a router) in response to resource requests from outside of queue in a router) in response to resource requests from outside of
the Diffserv region. the Diffserv region.
Various mechanisms may be used within the Diffserv network region to Various mechanisms may be used within the Diffserv network region to
support dynamic provisioning and topology aware admission control. support dynamic provisioning and topology aware admission control.
These include aggregated RSVP, per-flow RSVP and bandwidth brokers, These include aggregated RSVP, per-flow RSVP and bandwidth brokers,
as described in the following paragraphs. as described in the following paragraphs.
5.2.1 Aggregated or Tunneled RSVP 4.2.1 Aggregated or Tunneled RSVP
A number of drafts [3,6,15, 16] propose mechanisms for extending A number of documents [3,6,15,16] propose mechanisms for extending
RSVP to reserve resources for an aggregation of flows between edges RSVP to reserve resources for an aggregation of flows between edges
of a network. Border routers may interact with core routers and of a network. Border routers may interact with core routers and
other border routers using aggregated RSVP to reserve resources other border routers using aggregated RSVP to reserve resources
between edges of the Diffserv network region. Initial reservation between edges of the Diffserv network region. Initial reservation
levels for each service level may be established between major levels for each service level may be established between major border
border routers, based on anticipated traffic patterns. Border routers, based on anticipated traffic patterns. Border routers could
routers could trigger changes in reservation levels as a result of trigger changes in reservation levels as a result of the cumulative
the cumulative per-flow RSVP requests from the non-Diffserv regions per-flow RSVP requests from the non-Diffserv regions reaching high or
reaching high or low-water marks. low-water marks.
Bernet, ed. et al. 16
Integrated Services Operation Over Diffserv Networks March, 2000
In this approach, admission of per-flow RSVP requests from nodes In this approach, admission of per-flow RSVP requests from nodes
outside the Diffserv region would be counted against the appropriate outside the Diffserv region would be counted against the appropriate
aggregate reservations for the corresponding service level. The size aggregate reservations for the corresponding service level. The size
of the aggregate reservations may or may not be dynamically adjusted of the aggregate reservations may or may not be dynamically adjusted
to deal with the changes in per-flow reservations. to deal with the changes in per-flow reservations.
The advantage of this approach is that it offers dynamic, topology The advantage of this approach is that it offers dynamic, topology
aware admission control to the Diffserv network region without aware admission control to the Diffserv network region without
requiring the level of RSVP signaling processing that would be requiring the level of RSVP signaling processing that would be
required to support per-flow RSVP. required to support per-flow RSVP.
We note that resource management of a Diffserv region using We note that resource management of a Diffserv region using
aggregated RSVP is most likely to be feasible only within a single aggregated RSVP is most likely to be feasible only within a single
administrative domain, as each domain will probably choose its own administrative domain, as each domain will probably choose its own
mechanism to manage its resources. mechanism to manage its resources.
5.2.3 Per-flow RSVP 4.2.3 Per-flow RSVP
In this approach, described in [3], routers in the Diffserv network In this approach, described in [3], routers in the Diffserv network
region respond to the standard per-flow RSVP signaling originating region respond to the standard per-flow RSVP signaling originating
from the Intserv-capable nodes outside the Diffserv region. This from the Intserv-capable nodes outside the Diffserv region. This
approach provides the benefits of the previous approach (dynamic, approach provides the benefits of the previous approach (dynamic,
topology aware admission control) without requiring aggregated RSVP topology aware admission control) without requiring aggregated RSVP
support. Resources are also used more efficiently as a result of the support. Resources are also used more efficiently as a result of the
per-flow admission control. However, the demands on RSVP signaling per-flow admission control. However, the demands on RSVP signaling
resources within the Diffserv network region may be significantly resources within the Diffserv network region may be significantly
higher than in an aggregated RSVP approach. higher than in an aggregated RSVP approach.
Note that per-flow RSVP and aggregated RSVP are not mutually Note that per-flow RSVP and aggregated RSVP are not mutually
exclusive in a single Diffserv region. It is possible to use per- exclusive in a single Diffserv region. It is possible to use per-flow
flow RSVP at the edges of the Diffserv region and aggregation only RSVP at the edges of the Diffserv region and aggregation only in some
in some "core" region within the Diffserv region. "core" region within the Diffserv region.
5.2.4 Granularity of Deployment of RSVP Aware Routers 4.2.4 Granularity of Deployment of RSVP Aware Routers
In 5.2.2 and 5.2.3 some subset of the routers within the Diffserv In 4.2.2 and 4.2.3 some subset of the routers within the Diffserv
network is RSVP signaling aware (though traffic control is network is RSVP signaling aware (though traffic control is aggregated
aggregated as opposed to per-flow). The relative number of routers as opposed to per-flow). The relative number of routers in the core
in the core that participate in RSVP signaling is a provisioning that participate in RSVP signaling is a provisioning decision that
decision that must be made by the network administrator. must be made by the network administrator.
In one extreme case, only the border routers participate in RSVP In one extreme case, only the border routers participate in RSVP
signaling. In this case, either the Diffserv network region must be signaling. In this case, either the Diffserv network region must be
extremely over-provisioned and therefore, inefficiently used, or extremely over-provisioned and therefore, inefficiently used, or else
else it must be carefully and statically provisioned for limited it must be carefully and statically provisioned for limited traffic
traffic patterns. The border routers must enforce these patterns. patterns. The border routers must enforce these patterns.
In the other extreme case, each router in the Diffserv network
region might participate in RSVP signaling. In this case, resources
can be used with optimal efficiency, but signaling processing
requirements and associated overhead increase. As noted above, RSVP
Bernet, ed. et al. 17
Integrated Services Operation Over Diffserv Networks March, 2000
aggregation is one way to limit the signaling overhead at the cost In the other extreme case, each router in the Diffserv network region
of some loss of optimality in resource utilization. might participate in RSVP signaling. In this case, resources can be
used with optimal efficiency, but signaling processing requirements
and associated overhead increase. As noted above, RSVP aggregation
is one way to limit the signaling overhead at the cost of some loss
of optimality in resource utilization.
It is likely that some network administrators will compromise by It is likely that some network administrators will compromise by
enabling RSVP signaling on some subset of routers in the Diffserv enabling RSVP signaling on some subset of routers in the Diffserv
network region. These routers will likely represent major traffic network region. These routers will likely represent major traffic
switching points with over-provisioned or statically provisioned switching points with over-provisioned or statically provisioned
regions of RSVP unaware routers between them. regions of RSVP unaware routers between them.
5.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region 4.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region
Border routers might not use any form of RSVP signaling within the Border routers might not use any form of RSVP signaling within the
Diffserv network region but might instead use custom protocols to Diffserv network region but might instead use custom protocols to
interact with an "oracle". The oracle is a hypothetical agent that interact with an "oracle". The oracle is an agent that has
has sufficient knowledge of resource availability and network sufficient knowledge of resource availability and network topology to
topology to make admission control decisions. The set of RSVP aware make admission control decisions. The set of RSVP aware routers in
routers in the previous two examples can be considered collectively the previous two examples can be considered collectively as a form of
as a form of distributed oracle. In various definitions of the distributed oracle. In various definitions of the "bandwidth broker"
"bandwidth broker" [4], it is able to act as a centralized oracle. [4], it is able to act as a centralized oracle.
6. Implications of the Framework for Diffserv Network Regions 5. Implications of the Framework for Diffserv Network Regions
We have described a framework in which RSVP/Intserv style QoS can be We have described a framework in which RSVP/Intserv style QoS can be
provided across end-to-end paths that include Diffserv network provided across end-to-end paths that include Diffserv network
regions. This section discusses some of the implications of this regions. This section discusses some of the implications of this
framework for the Diffserv network region. framework for the Diffserv network region.
6.1 Requirements from Diffserv Network Regions 5.1 Requirements from Diffserv Network Regions
A Diffserv network region must meet the following requirements in A Diffserv network region must meet the following requirements in
order for it to support the framework described in this document. order for it to support the framework described in this document.
1. A Diffserv network region must be able to provide support for the 1. A Diffserv network region must be able to provide support for the
standard Intserv QoS services between its border routers. It must be standard Intserv QoS services between its border routers. It must be
possible to invoke these services by use of standard PHBs within the possible to invoke these services by use of standard PHBs within the
Diffserv region and appropriate behavior at the edge of the Diffserv Diffserv region and appropriate behavior at the edge of the Diffserv
region. region.
2. Diffserv network regions must provide admission control 2. Diffserv network regions must provide admission control
information to their "customer" (non-Diffserv) network regions. information to their "customer" (non-Diffserv) network regions. This
This information can be provided by a dynamic protocol or through information can be provided by a dynamic protocol or through static
static service level agreements enforced at the edges of the service level agreements enforced at the edges of the Diffserv
Diffserv region. region.
3. Diffserv network regions must be able to pass RSVP messages, in 3. Diffserv network regions must be able to pass RSVP messages, in
such a manner that they can be recovered at the egress of the such a manner that they can be recovered at the egress of the
Diffserv network region. The Diffserv network region may, but is not Diffserv network region. The Diffserv network region may, but is not
required to, process these messages. Mechanisms for transparently required to, process these messages. Mechanisms for transparently
carrying RSVP messages across a transit network are described in carrying RSVP messages across a transit network are described in
[3,6,15, 16]. [3,6,15,16].
Bernet, ed. et al. 18
Integrated Services Operation Over Diffserv Networks March, 2000
To meet these requirements, additional work is required in the areas To meet these requirements, additional work is required in the areas
of: of:
1. Mapping Intserv style service specifications to services that can 1. Mapping Intserv style service specifications to services that can
be provided by Diffserv network regions. be provided by Diffserv network regions.
2. Definition of the functionality required in network elements to 2. Definition of the functionality required in network elements to
support RSVP signaling with aggregate traffic control (for network support RSVP signaling with aggregate traffic control (for network
elements residing in the Diffserv network region). elements residing in the Diffserv network region).
3. Definition of mechanisms to efficiently and dynamically provision 3. Definition of mechanisms to efficiently and dynamically provision
resources in a Diffserv network region (e.g. aggregated RSVP, resources in a Diffserv network region (e.g., aggregated RSVP,
tunneling, MPLS, etc.). This might include protocols by which an tunneling, MPLS, etc.). This might include protocols by which an
"oracle" (e.g., a centralized server) conveys information about "oracle" conveys information about resource availability within a
resource availability within a Diffserv region to border routers. Diffserv region to border routers. One example of such a mechanism
One example of such a mechanism is the so-called "bandwidth broker" is the so-called "bandwidth broker" proposed in [19,20,21].
proposed in [19, 20, 21].
6.2 Protection of Intserv Traffic from Other Traffic 5.2 Protection of Intserv Traffic from Other Traffic
Network administrators must be able to share resources in the Network administrators must be able to share resources in the
Diffserv network region between three types of traffic: Diffserv network region between three types of traffic:
a. End-to-end Intserv traffic - this is typically traffic a. End-to-end Intserv traffic. This is typically traffic associated
associated with quantitative QoS applications. It requires a with quantitative QoS applications. It requires a specific quantity
specific quantity of resources with a high degree of assurance. of resources with a high degree of assurance.
b. Non-Intserv traffic. The Diffserv region may allocate resources b. Non-Intserv traffic. The Diffserv region may allocate resources
to traffic that does not make use of Intserv techniques to quantify to traffic that does not make use of Intserv techniques to quantify
its requirements, e.g. through the use of static provisioning and its requirements, e.g., through the use of static provisioning and
SLSs enforced at the edges of the region. Such traffic might be SLSs enforced at the edges of the region. Such traffic might be
associated with applications whose QoS requirements are not readily associated with applications whose QoS requirements are not readily
quantifiable but which require a "better than best-effort" level of quantifiable but which require a "better than best-effort" level of
service. service.
c. All other (best-effort) traffic c. All other (best-effort) traffic. These three classes of traffic
must be isolated from each other by the appropriate configuration of
policers and classifiers at ingress points to the Diffserv network
region, and by appropriate provisioning within the Diffserv network
region. To provide protection for Intserv traffic in Diffserv
regions of the network, we suggest that the DSCPs assigned to such
traffic not overlap with the DSCPs assigned to other traffic.
These three classes of traffic must be isolated from each other by 6. Multicast
the appropriate configuration of policers and classifiers at ingress
points to the Diffserv network region, and by appropriate
provisioning within the Diffserv network region. To provide
protection for Intserv traffic in Diffserv regions of the network,
we suggest that the DSCPs assigned to such traffic not overlap with
the DSCPs assigned to other traffic.
7. Multicast
The use of integrated services over Diffserv networks is The use of integrated services over Diffserv networks is
significantly more complex for multicast sessions than for unicast significantly more complex for multicast sessions than for unicast
sessions. With respect to a multicast connection, each participating sessions. With respect to a multicast connection, each participating
region has a single ingress router and zero, one or several egress region has a single ingress router and zero, one or several egress
routers. The difficulties of multicast are associated with Diffserv routers. The difficulties of multicast are associated with Diffserv
regions that contain several egress routers. (Support of multicast regions that contain several egress routers. (Support of multicast
functionality outside the Diffserv region is relatively functionality outside the Diffserv region is relatively
Bernet, ed. et al. 19
Integrated Services Operation Over Diffserv Networks March, 2000
straightforward since every Intserv-capable router along the straightforward since every Intserv-capable router along the
multicast tree stores state for each flow.) multicast tree stores state for each flow.)
Consider the following reference network: Consider the following reference network:
Non-Diffserv region 2 Non-Diffserv region 2
________ ________
/ \ / \
| | |---| | | |---|
________ _____________ | |-|Rx1| ________ _____________ | |-|Rx1|
/ \ / |--\ |---| | |---| / \ / |--\ |---| | |---|
/ \ / /|BR2\-----\ER2| / / \ / /|BR2\-----\ER2| /
|---| | |---| |---| |--|/ |---| \--|____/ |---| | |---| |---| |--|/ |---| \--|____/
|Tx |-| |ER1|---|BR1|--|RR| | ________ |Tx |-| |ER1|---|BR1|--|RR| | ________
|---| | |-- | |---| |--|\ |---| /--| \ |---| | |-- | |---| |--|\ |---| /--| \
\ / \ \|BR3/-----|ER3| | |---| \ / \ \|BR3/-----|ER3| | |---|
\________/ \__________|--/ |---| |-|Rx2| \________/ \__________|--/ |---| |-|Rx2|
| | |---| | | |---|
Non-Diffserv region 1 Diffserv region \ / Non-Diffserv region 1 Diffserv region \ /
\______/ \______/
Non-Diffserv region 3 Non-Diffserv region 3
Figure 2: Sample Multicast Network Configuration Figure 2: Sample Multicast Network Configuration
The reference network is similar to that of Figure 1. However, in The reference network is similar to that of Figure 1. However, in
Figure 2, copies of the packets sent by Tx are delivered to several Figure 2, copies of the packets sent by Tx are delivered to several
receivers outside of the Diffserv region, namely to Rx1 and Rx2. receivers outside of the Diffserv region, namely to Rx1 and Rx2.
Moreover, packets are copied within the Diffserv region in a "branch Moreover, packets are copied within the Diffserv region in a "branch
point" router RR. In the reference network BR1 is the ingress router point" router RR. In the reference network BR1 is the ingress router
to the Diffserv region whereas BR2 and BR3 are the egress routers. to the Diffserv region whereas BR2 and BR3 are the egress routers.
In the simplest case the receivers, Rx1 and Rx2 in the reference In the simplest case the receivers, Rx1 and Rx2 in the reference
network, require identical reservations. The Diffserv framework [18] network, require identical reservations. The Diffserv framework [18]
supports service level specifications (SLS) from an ingress router supports service level specifications (SLS) from an ingress router to
to one, some or all of the egress routers. This calls for a "one to one, some or all of the egress routers. This calls for a "one to
many" SLS within the Diffserv region, from BR1 to BR2 and BR3. Given many" SLS within the Diffserv region, from BR1 to BR2 and BR3. Given
that the SLS is granted by the Diffserv region, the ingress router that the SLS is granted by the Diffserv region, the ingress router
BR1, or perhaps an upstream node such as ER1, marks packets entering BR1, or perhaps an upstream node such as ER1, marks packets entering
the Diffserv region with the appropriate DSCP. The packets are the Diffserv region with the appropriate DSCP. The packets are
routed to the egresses of the Diffserv domain using the original routed to the egresses of the Diffserv domain using the original
multicast address. multicast address.
The two major problems, explained in the following, are associated The two major problems, explained in the following, are associated
with heterogeneous multicast trees containing branch points within with heterogeneous multicast trees containing branch points within
the Diffserv region, i.e. multicast trees where the level of the Diffserv region, i.e., multicast trees where the level of
resource requirement is not uniform among all receivers. An example resource requirement is not uniform among all receivers. An example
of such a scenario in the network of Figure 2 is the case where both of such a scenario in the network of Figure 2 is the case where both
Rx1 and Rx2 need to receive multicast data from Tx1 but only one of Rx1 and Rx2 need to receive multicast data from Tx1 but only one of
the receivers has requested a level of service above best effort. We
Bernet, ed. et al. 20
Integrated Services Operation Over Diffserv Networks March, 2000
the receivers has requested a level of service above best effort. We
consider such scenarios in the following paragraphs. consider such scenarios in the following paragraphs.
7.1 Remarking of packets in branch point routers 6.1 Remarking of packets in branch point routers
In the above scenario, the packets that arrive at BR1 are marked In the above scenario, the packets that arrive at BR1 are marked with
with an appropriate DSCP for the requested Intserv service and are an appropriate DSCP for the requested Intserv service and are sent to
sent to RR. Packets arriving at the branch point must be sent RR. Packets arriving at the branch point must be sent towards BR2
towards BR2 with the same DSCP otherwise the service to Rx1 is with the same DSCP otherwise the service to Rx1 is degraded.
degraded. However, the packets going from RR towards BR3 need not However, the packets going from RR towards BR3 need not maintain the
maintain the high assurance level anymore. They may be demoted to high assurance level anymore. They may be demoted to best effort so
best effort so that the QoS provided to other packets along this that the QoS provided to other packets along this branch of the tree
branch of the tree is not disrupted. Several problems can be is not disrupted. Several problems can be observed in the given
observed in the given scenario: scenario:
- In the Diffserv region, DSCP marking is done at edge routers - In the Diffserv region, DSCP marking is done at edge routers
(ingress), whereas a branch point router might be a core (ingress), whereas a branch point router might be a core
router, which does not mark packets. router, which does not mark packets.
- Being a core Diffserv router, RR classifies based on - Being a core Diffserv router, RR classifies based on
aggregate traffic streams (BA), as opposed to per flow (MF) aggregate traffic streams (BA), as opposed to per flow (MF)
classification. Hence, it does not necessarily have the classification. Hence, it does not necessarily have the
capability to distinguish those packets which belong to a capability to distinguish those packets which belong to a
specific multicast tree and require demotion from the other specific multicast tree and require demotion from the other
packets in the behavior aggregate, which carry the same DSCP. packets in the behavior aggregate, which carry the same DSCP.
- Since RR may be RSVP-unaware, it may not participate in the - Since RR may be RSVP-unaware, it may not participate in the
admission control process, and would thus not store any per- admission control process, and would thus not store any per-
flow state about the reservations for the multicast tree. flow state about the reservations for the multicast tree.
Hence, even if RR were able to perform MF classification and Hence, even if RR were able to perform MF classification and
DSCP remarking, it would not know enough about downstream DSCP remarking, it would not know enough about downstream
reservations to remark the DSCP intelligently. reservations to remark the DSCP intelligently.
These problems can be tackled by the following mechanisms: These problems could be addressed by a variety of mechanisms. We
list some below, while noting that none is ideal in all cases and
that further mechanisms may be developed in the future:
1. If some Intserv-capable routers are placed within the Diffserv 1. If some Intserv-capable routers are placed within the Diffserv
region, it might be possible to administer the network topology and region, it might be possible to administer the network topology and
routing parameters so as to ensure that branch points occur only routing parameters so as to ensure that branch points occur only
within such routers. These routers would support MF classification within such routers. These routers would support MF classification
and remarking and hold per-flow state for the heterogeneous and remarking and hold per-flow state for the heterogeneous
reservations for which they are the branch point. Note that in this reservations for which they are the branch point. Note that in this
case, branch point routers would have essentially the same case, branch point routers would have essentially the same
functionality as ingress routers of an RSVP-aware Diffserv domain. functionality as ingress routers of an RSVP-aware Diffserv domain.
2. Packets sent on the "non-reserved" branch (from RR towards BR3) 2. Packets sent on the "non-reserved" branch (from RR towards BR3)
are marked with the "wrong" DSCP; that is, they are not demoted to are marked with the "wrong" DSCP; that is, they are not demoted to
best effort but retain their DSCP. This in turn requires over best effort but retain their DSCP. This in turn requires over
reservation of resources along that link or runs the risk of reservation of resources along that link or runs the risk of
degrading service to packets that legitimately bear the same DSCP degrading service to packets that legitimately bear the same DSCP
along this path. However, it allows the Diffserv routers to remain along this path. However, it allows the Diffserv routers to remain
free of per-flow state. free of per-flow state.
Bernet, ed. et al. 21 3. A combination of mechanism 1 and 2 may be an effective compromise.
In this case, there are some Intserv-capable routers in the core of
Integrated Services Operation Over Diffserv Networks March, 2000 the network, but the network cannot be administered so that ALL
branch points fall at such routers.
3. A combination of mechanism 1 and 2 may be an effective
compromise. In this case, there are some Intserv-capable routers in
the core of the network, but the network cannot be administered so
that ALL branch points fall at such routers.
4. Administrators of Diffserv regions may decide not to enable 4. Administrators of Diffserv regions may decide not to enable
heterogeneous sub-trees in their domains. In the case of different heterogeneous sub-trees in their domains. In the case of different
downstream reservations, a ResvErr message would be sent according downstream reservations, a ResvErr message would be sent according to
to the RSVP rules. This is similar to the approach taken for Intserv the RSVP rules. This is similar to the approach taken for Intserv
over IEEE 802 Networks [2,5]. over IEEE 802 Networks [2,5].
5. In [3], a scheme was introduced whereby branch point routers in 5. In [3], a scheme was introduced whereby branch point routers in
the interior of the aggregation region (i.e. the Diffserv region) the interior of the aggregation region (i.e., the Diffserv region)
keep reduced state information regarding the reservations by using keep reduced state information regarding the reservations by using
measurement based admission control. Under this scheme, packets are measurement based admission control. Under this scheme, packets are
tagged by the more knowledgeable Intserv edges routers with tagged by the more knowledgeable Intserv edges routers with
scheduling information that is used in place of the detailed Intserv scheduling information that is used in place of the detailed Intserv
state. If the Diffserv region and branch point routers are designed state. If the Diffserv region and branch point routers are designed
following that framework, demotion of packets becomes possible. following that framework, demotion of packets becomes possible.
7.2 Multicast SLSs and Heterogeneous Trees 6.2 Multicast SLSs and Heterogeneous Trees
Multicast flows with heterogeneous reservations present some Multicast flows with heterogeneous reservations present some
challenges in the area of SLSs. For example, a common example of an challenges in the area of SLSs. For example, a common example of an
SLS is one where a certain amount of traffic is allowed to enter a SLS is one where a certain amount of traffic is allowed to enter a
Diffserv region marked with a certain DSCP, and such traffic may be Diffserv region marked with a certain DSCP, and such traffic may be
destined to any egress router of that region. We call such an SLS a destined to any egress router of that region. We call such an SLS a
homogeneous, or uniform, SLS. However, in a multicast environment, a homogeneous, or uniform, SLS. However, in a multicast environment, a
single packet that is admitted to the Diffserv region may consume single packet that is admitted to the Diffserv region may consume
resources along many paths in the region as it is replicated and resources along many paths in the region as it is replicated and
forwarded towards many egress routers; alternatively, it may flow forwarded towards many egress routers; alternatively, it may flow
along a single path. This situation is further complicated by the along a single path. This situation is further complicated by the
possibility described above and depicted in Figure 2, in which a possibility described above and depicted in Figure 2, in which a
multicast packet might be treated as best effort along some branches multicast packet might be treated as best effort along some branches
while receiving some higher QOS treatment along others. We simply while receiving some higher QOS treatment along others. We simply
note here that the specification of meaningful SLSs which meet the note here that the specification of meaningful SLSs which meet the
needs of heterogeneous flows and which can be met be providers is needs of heterogeneous flows and which can be met be providers is
likely to be challenging. likely to be challenging.
Dynamic SLSs may help to address these issues. For example, by using Dynamic SLSs may help to address these issues. For example, by using
RSVP to signal the resources that are required along different RSVP to signal the resources that are required along different
branches of a multicast tree, it may be possible to more closely branches of a multicast tree, it may be possible to more closely
approach the goal of allocating appropriate resources only where approach the goal of allocating appropriate resources only where they
they are needed rather than overprovisioning or underprovisioning are needed rather than overprovisioning or underprovisioning along
along certain branches of a tree. This is essentially the approach certain branches of a tree. This is essentially the approach
described in [15]. described in [15].
8. Security Considerations 7. Security Considerations
8.1 General RSVP Security
Bernet, ed. et al. 22
Integrated Services Operation Over Diffserv Networks March, 2000 7.1 General RSVP Security
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 Diffserv and non-Diffserv regions of a network. Therefore, all both Diffserv and non-Diffserv regions of a network. Therefore, all
RSVP security considerations apply [9]. In addition, network RSVP security considerations apply [9]. In addition, network
administrators are expected to protect network resources by administrators are expected to protect network resources by
configuring secure policers at interfaces with untrusted customers. configuring secure policers at interfaces with untrusted customers.
8.2 Host Marking 7.2 Host Marking
Though it does not mandate host marking of the DSCP, our proposal Though it does not mandate host marking of the DSCP, our proposal
does allow it. Allowing hosts to set the DSCP directly may alarm does allow it. Allowing hosts to set the DSCP directly may alarm
network administrators. The obvious concern is that hosts may network administrators. The obvious concern is that hosts may
attempt to "steal" resources. In fact, hosts may attempt to exceed attempt to "steal" resources. In fact, hosts may attempt to exceed
negotiated capacity in Diffserv network regions at a particular negotiated capacity in Diffserv network regions at a particular
service level regardless of whether they invoke this service level service level regardless of whether they invoke this service level
directly (by setting the DSCP) or indirectly (by submitting traffic directly (by setting the DSCP) or indirectly (by submitting traffic
that classifies in an intermediate marking router to a particular that classifies in an intermediate marking router to a particular
DSCP). DSCP).
In either case, it will generally be necessary for each Diffserv In either case, it will generally be necessary for each Diffserv
network region to protect its resources by policing to assure that network region to protect its resources by policing to assure that
customers do not use more resources than they are entitled to, at customers do not use more resources than they are entitled to, at
each service level (DSCP). The exception to this rule is when the each service level (DSCP). The exception to this rule is when the
host is known to be trusted, e.g. a server that is under the control host is known to be trusted, e.g., a server that is under the control
of the network administrators. If an untrusted sending host does not of the network administrators. If an untrusted sending host does not
perform DSCP marking, the boundary router (or trusted intermediate perform DSCP marking, the boundary router (or trusted intermediate
routers) must provide MF classification, mark and police. If an routers) must provide MF classification, mark and police. If an
untrusted sending host does perform marking, the boundary router untrusted sending host does perform marking, the boundary router
needs only to provide BA classification and to police to ensure that needs only to provide BA classification and to police to ensure that
the customer is not exceeding the aggregate capacity negotiated for the customer is not exceeding the aggregate capacity negotiated for
the service level. the service level.
In summary, there are no additional security concerns raised by In summary, there are no additional security concerns raised by
marking the DSCP at the edge of the network since Diffserv providers marking the DSCP at the edge of the network since Diffserv providers
will have to police at their boundaries anyway. Furthermore, this will have to police at their boundaries anyway. Furthermore, this
approach reduces the granularity at which border routers must approach reduces the granularity at which border routers must police,
police, thereby pushing finer grain shaping and policing thereby pushing finer grain shaping and policing responsibility to
responsibility to the edges of the network, where it scales better the edges of the network, where it scales better and provides other
and provides other benefits described in Section 3.3.1. The larger benefits described in Section 3.3.1. The larger Diffserv network
Diffserv network regions are thus focused on the task of protecting regions are thus focused on the task of protecting their networks,
their networks, while the Intserv-capable nodes are focused on the while the Intserv-capable nodes are focused on the task of shaping
task of shaping and policing their own traffic to be in compliance and policing their own traffic to be in compliance with their
with their negotiated Intserv parameters. negotiated Intserv parameters.
9. Acknowledgments 8. Acknowledgments
Authors thank the following individuals for their comments that led Authors thank the following individuals for their comments that led
to improvements to the previous version(s) of this document: David to improvements to the previous version(s) of this document: David
Oran, Andy Veitch, Curtis Villamizer, Walter Weiss, Francois le Oran, Andy Veitch, Curtis Villamizer, Walter Weiss, Francois le
Faucheur and Russell White. Faucheur and Russell White.
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 [10]. the original Intserv architecture document [10].
Bernet, ed. et al. 23 9. References
Integrated Services Operation Over Diffserv Networks March, 2000
10. References
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource Reservation Protocol (RSVP) Version 1 Functional "Resource Reservation Protocol (RSVP) Version 1 Functional
Specification", RFC 2205, Proposed Standard, September 1997 Specification", RFC 2205, September 1997.
[2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M., [2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M. Speer,
"SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based
Admission Control Over IEEE 802 Style Networks", Internet Draft, Admission Control Over IEEE 802 Style Networks", RFC 2814, May
draft-ietf-issll-is802-sbm-08.txt, May 1999 2000.
[3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated [3] Berson, S. and R. Vincent, "Aggregation of Internet Integrated
Services State", Internet Draft, draft-berson-rsvp-aggregation- Services State", Work in Progress.
00.txt, August 1998.
[4] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit [4] Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet", RFC Differentiated Services Architecture for the Internet", RFC
2638, July 1999. 2638, July 1999.
[5] Seaman, M., Smith, A., Crawley, E., and Wroclawski, J., [5] Seaman, M., Smith, A., Crawley, E. and J. Wroclawski,
"Integrated Service Mappings on IEEE 802 Networks", Internet "Integrated Service Mappings on IEEE 802 Networks", RFC 2815,
Draft, draft-ietf-issll-is802-svc-mapping-04.txt, June 1999 May 2000.
[6] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based [6] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based
QoS Requests", Internet Draft, draft-guerin-aggreg-rsvp-00.txt, QoS Requests", Work in Progress.
November 1997.
[7] Nichols, Kathleen, et al., "Definition of the Differentiated [7] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC the Differentiated Services Field (DS Field) in the IPv4 and
2474, December 1998. IPv6 Headers", RFC 2474, December 1998.
[8] Blake, S., et al., "An Architecture for Differentiated [8] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Services." RFC 2475, December 1998. Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[9] Baker, F., "RSVP Cryptographic Authentication", Internet Draft, [9] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic
draft-ietf-rsvp-md5-08.txt, February 1999 Authentication", RFC 2747, January 2000.
[10] Braden, R., Clark, D. and Shenker, S., "Integrated Services in [10] Braden, R., Clark, D. and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", Internet RFC 1633, the Internet Architecture: an Overview", RFC 1633, June 1994.
June 1994
[11] Garrett, M. W., and Borden, M., "Interoperation of Controlled- [11] Garrett, M. and M. Borden, "Interoperation of Controlled-Load
Load Service and Guaranteed Service with ATM", RFC2381, August Service and Guaranteed Service with ATM", RFC 2381, August 1998.
1998.
[12] Weiss, Walter, Private communication, November 1998. [12] Weiss, Walter, Private communication, November 1998.
[13] Kent, S., Atkinson, R., "Security Architecture for the Internet [13] Kent, S. and R. Atkinson, "Security Architecture for the
Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
Bernet, ed. et al. 24
Integrated Services Operation Over Diffserv Networks March, 2000
[14] Bernet, Y., "Usage and Format of the DCLASS Object with RSVP [14] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
Signaling", Internet Draft, draft-issll-dclass-00.txt, August November 2000.
1999.
[15] Baker, F., Iturralde, C., le Faucheur, F., and Davie, B. "RSVP [15] Baker, F., Iturralde, C., le Faucheur, F., and Davie, B. "RSVP
Reservation Aggregation", Internet Draft, draft-ietf-issll- Reservation Aggregation", Work in Progress.
aggregation-00.txt, September 1999.
[16] Terzis, A., Krawczyk, J., Wroclawski, J., Zhang, L., "RSVP [16] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP
Operation Over IP Tunnels", Internet Draft, draft-ietf-rsvp- Operation Over IP Tunnels", RFC 2746, January 2000.
tunnel-04.txt, May 1999.
[17] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, D., and [17] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, D. and A.
Sastry, A., "COPS Usage for RSVP", Internet Draft, draft-ietf- Sastry, "COPS Usage for RSVP", RFC 2749, January 2000.
rap-cops-rsvp-05.txt, June 1999.
[18] Bernet, Y., et al., "A Framework for Differentiated Services", [18] Bernet, Y., "A Framework for Differentiated Services", Work in
Internet draft, draft-ietf-diffserv-framework-02.txt, February Progress.
1999.
[19] Jacobson Van, "Differentiated Services Architecture", talk in [19] Jacobson Van, "Differentiated Services Architecture", talk in
the Int-Serv WG at the Munich IETF, August 1997. the Int-Serv WG at the Munich IETF, August 1997.
[20] Jacobson, V., Nichols K., and Zhang, L. "A Two-bit [20] Jacobson, V., Nichols K. and L. Zhang, "A Two-bit Differentiated
Differentiated Services Architecture for the Internet", Services Architecture for the Internet", RFC 2638, June 1999.
RFC 2638, June 1999.
[21] First Internet2 bandwidth broker operability event [21] First Internet2 bandwidth broker operability event
http://www.merit.edu/internet/working.groups/i2-qbone-bb/ http://www.merit.edu/internet/working.groups/i2-qbone-bb/
inter-op/index.htm inter-op/index.htm
11. Author's Addresses: 10. Authors' Addresses
Yoram Bernet Yoram Bernet
Microsoft Microsoft
One Microsoft Way, Redmond, WA 98052 One Microsoft Way
Phone: (425) 936-9568 Redmond, WA 98052
Email: yoramb@microsoft.com
Phone: +1 425-936-9568
EMail: yoramb@microsoft.com
Raj Yavatkar Raj Yavatkar
Intel Corporation Intel Corporation
JF3-448 2111 NE 25th. Avenue, Hillsboro, OR 97124 JF3-206 2111 NE 25th. Avenue
Phone: (503) 264-9077 Hillsboro, OR 97124
Email: raj.yavatkar@intel.com
Phone: +1 503-264-9077
EMail: raj.yavatkar@intel.com
Peter Ford Peter Ford
Microsoft Microsoft
One Microsoft Way, Redmond, WA 98052 One Microsoft Way
Phone: (425) 703-2032 Redmond, WA 98052
Email: peterf@microsoft.com
Fred Baker
Bernet, ed. et al. 25
Integrated Services Operation Over Diffserv Networks March, 2000 Phone: +1 425-703-2032
EMail: peterf@microsoft.com
Fred Baker
Cisco Systems Cisco Systems
519 Lado Drive, Santa Barbara, CA 93111 519 Lado Drive
Phone: (408) 526-4257 Santa Barbara, CA 93111
Email: fred@cisco.com
Phone: +1 408-526-4257
EMail: fred@cisco.com
Lixia Zhang Lixia Zhang
UCLA UCLA
4531G Boelter Hall Los Angeles, CA 90095 4531G Boelter Hall
Phone: (310) 825-2695 Los Angeles, CA 90095
Email: lixia@cs.ucla.edu
Phone: +1 310-825-2695
EMail: lixia@cs.ucla.edu
Michael Speer Michael Speer
Sun Microsystems Sun Microsystems
901 San Antonio Road UMPK15-215 Palo Alto, CA 94303 901 San Antonio Road, UMPK15-215
Phone: (650)786-6368 Palo Alto, CA 94303
Email: speer@Eng.Sun.COM
Phone: +1 650-786-6368
EMail: speer@Eng.Sun.COM
Bob Braden Bob Braden
USC Information Sciences Institute USC/Information Sciences Institute
4676 Admiralty Way Marina del Rey, CA 90292-6695 4676 Admiralty Way
Phone: (310) 822-1511 Marina del Rey, CA 90292-6695
Email: braden@isi.edu
Phone: +1 310-822-1511
EMail: braden@isi.edu
Bruce Davie Bruce Davie
Cisco Systems Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824 250 Apollo Drive
Phone: (978) 244-8000 Chelmsford, MA 01824
Email: bsd@cisco.com
Phone: +1 978-244-8000
EMail: bsd@cisco.com
Eyal Felstaine Eyal Felstaine
Dept. of Computer Science SANRAD Inc.
Technion, IIT 24 Raul Wallenberg st
32000 Haifa, Israel Tel Aviv, Israel
Phone: +972-50-747672 Phone: +972-50-747672
Email: eyalfe@cs.technion.ac.il Email: eyal@sanrad.com
John Wroclawski John Wroclawski
MIT Laboratory for Computer Science MIT Laboratory for Computer Science
545 Technology Sq. 545 Technology Sq.
Cambridge, MA 02139 Cambridge, MA 02139
Phone: (617) 253-7885
E-mail: jtw@lcs.mit.edu
12. Full Copyright Statement Phone: +1 617-253-7885
EMail: jtw@lcs.mit.edu
11. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
Bernet, ed. et al. 26 included on all such copies and derivative works. However, this
Integrated Services Operation Over Diffserv Networks March, 2000
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This draft expires September, 2000 Acknowledgement
Bernet, ed. et al. 27 Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 279 change blocks. 
754 lines changed or deleted 693 lines changed or added

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