draft-ietf-issll-diffserv-rsvp-01.txt   draft-ietf-issll-diffserv-rsvp-02.txt 
Y. Bernet, Microsoft Y. Bernet, Microsoft
R. Yavatkar, Intel R. Yavatkar, Intel
P. Ford, Microsoft P. Ford, Microsoft
F. Baker, Cisco F. Baker, Cisco
L. Zhang, UCLA L. Zhang, UCLA
M. Speer, Sun Microsystems M. Speer, Sun Microsystems
R. Braden, ISI R. Braden, ISI
B. Davie, Cisco
Internet Draft Internet Draft
Expires: September, 1999 Expires: December, 1999
Document: draft-ietf-issll-diffserv-rsvp-01.txt March, 1999 Document: draft-ietf-issll-diffserv-rsvp-02.txt June, 1999
Interoperation of RSVP/Intserv and Diffserv Networks 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 document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are
Working documents of the Internet Engineering Task Force (IETF), its Working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
linebreak http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
1. Abstract 1. Abstract
RSVP/Integrated Services and Differentiated Services provide The Integrated Services architecture provides a means for the
complementary approaches to the problem of providing end-to-end QoS delivery of end-to-end QoS to applications over heterogeneous
in the Internet. These approaches must be able to coexist and networks. To support this end-to-end model, the Intserv architecture
effectively inter-operate. This document describes a framework by must be supported over a wide variety of different types of network
which the two approaches inter-operate to provide end-to-end QoS for elements. In this context, a network that supports Differentiated
quantitative applications (applications for which QoS requirements Services (Diffserv) may be viewed as a network element in the total
are readily quantifiable, and which rely on these QoS requirements end-to-end path. This document describes a framework by which
to function properly). Integrated Services may be supported over Diffserv networks.
2. Introduction 2. 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)[12] and its the Integrated Services architecture (intserv)[10] and its
accompanying signaling protocol, RSVP [1], vs. the Differentiated accompanying signaling protocol, RSVP [1], and the Differentiated
Services architecture (diffserv)[10]. Services architecture (diffserv)[8]. This document describes ways in
2.1 RSVP/Intserv
Bernet, ed. et. al 1 Bernet, ed. et. al 1
Use of RSVP with Diffserv March, 1999
Integrated Services Operation Over Diffserv Networks June, 1999
which a Diffserv network can be used in the context of the Intserv
architecture to support the delivery of end-to-end QOS.
2.1 Integrated Services Architecture
The integrated services architecture defined a set of extensions to
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
key components of the architecture is a set of service definitions;
the current set of services consists of the controlled load and
guaranteed services. The architecture assumes that some explicit
setup mechanism is used to convey information to routers so that
they can provide requested services to flows that require them.
While RSVP is the most widely known example of such a setup
mechanism, the intserv architecture is designed to accommodate other
mechanisms.
Intserv services are implemented by _network elements_. While it is
common for network elements to be individual nodes such as routers
or links, more complex entities, such as ATM _clouds_ or 802.3
networks may also function as network elements. As discussed in more
detail below, a Diffserv network (or _cloud_) may be viewed as a
network element within a larger intserv network.
2.3 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. It is important to emphasize that RSVP and intserv parameters as defined in the appropriate intserv service
intserv are separable; RSVP is a signaling protocol. Intserv is a specification. As noted above, RSVP and intserv are separable. RSVP
set of models for expressing service types, quantifying resource is a signaling protocol which may carry intserv information. Intserv
requirements and for determining the availability of the requested defines the models for expressing service types, quantifying
resources at relevant network elements (admission control). resource requirements and for determining the availability of the
requested resources at relevant network elements (admission
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 service requested in strict isolation from other traffic. To the service requested in strict isolation from other traffic. To
this end, RSVP signaling configures 'MF' [10] packet classifiers in this end, RSVP signaling configures microflow (MF) [8] packet
intserv capable routers along the path of the traffic flow. These classifiers in intserv capable routers along the path of the traffic
classifiers enable per-flow classification of packets based on IP flow. These classifiers enable per-flow classification of packets
addresses and port numbers. based on IP addresses and port numbers.
The following factors have impeded deployment of the RSVP/Intserv The following factors have impeded deployment of RSVP (and the
architecture in the Internet at large: intserv architecture) in the Internet at large:
Bernet, ed. et al. 2
Integrated Services Operation Over Diffserv Networks June, 1999
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 -- are not available. authentication, and accounting _- have only recently become
available [17].
2.2 Diffserv 2.4 Diffserv
The market is pushing for immediate deployment of a QoS solution The market is pushing for immediate deployment of a QoS solution
that addresses the needs of the Internet as well as enterprise that addresses the needs of the Internet as well as enterprise
networks. This push led to the development of diffserv. In contrast networks. This push led to the development of diffserv. In contrast
to the per-flow orientation of RSVP/intserv, diffserv networks to the per-flow orientation of RSVP, diffserv networks classify
classify packets into one of a small number of aggregated flows or packets into one of a small number of aggregated flows or 'classes',
'classes', based on the diffserv codepoint (DSCP) in the packet's IP based on the diffserv codepoint (DSCP) in the packet's IP header.
header. This is known as 'BA' classification [10]. At each diffserv This is known as behavior aggregate (BA) classification [8]. At each
router, packets are subjected to a 'per-hop behaviour' (PHB), which diffserv router, packets are subjected to a 'per-hop behaviour'
is invoked by the DSCP. The primary benefit of diffserv is its (PHB), which is invoked by the DSCP. The primary benefit of diffserv
scalability. Diffserv eliminates the need for per-flow state and is its scalability. Diffserv eliminates the need for per-flow state
per-flow processing and therefore scales well to large networks. and per-flow processing and therefore scales well to large networks.
2.3 Complementary Roles of RSVP/Intserv and Diffserv 2.5 Roles of Intserv, RSVP and Diffserv
We view RSVP/intserv 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-
Bernet, ed. et. al 2
Use of RSVP with Diffserv March, 1999
on-demand, and various non-multimedia mission-critical applications. on-demand, and various non-multimedia mission-critical applications.
RSVP/intserv enables hosts to request per-flow, quantifiable Intserv enables hosts to request per-flow, quantifiable resources,
resources, along end-to-end data paths and to obtain feedback along end-to-end data paths and to obtain feedback regarding
regarding admissibility of these requests. Diffserv enables admissibility of these requests. Diffserv enables scalability across
scalability across large networks. large networks.
2.3 Components of RSVP/intserv and Diffserv 2.6 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 of the QoS technologies described: components of the QoS technologies described:
RSVP signaling - This term refers to the standard RSVP per-flow RSVP signaling - This term refers to the standard RSVP signaling
signaling protocol. RSVP signaling is used by hosts to signal per- protocol. RSVP signaling is used by hosts to signal application
flow resource requirements to the network (and to each other). resource requirements to the network (and to each other). Network
Network elements use RSVP signaling to return an admission control elements use RSVP signaling to return an admission control decision
decision to hosts. RSVP signaling may or may not carry intserv to hosts. RSVP signaling may or may not carry intserv parameters.
parameters. Admission control at a network element may or may not be Admission control at a network element may or may not be based on
based on the intserv model. the intserv model.
RSVP/Intserv - This term is used to refer to the prevailing model of Bernet, ed. et al. 3
RSVP usage which includes RSVP signaling with intserv parameters,
intserv admission control and per-flow traffic control at network Integrated Services Operation Over Diffserv Networks June, 1999
elements.
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 is applied collectively to sets of traffic flows. These sets which is applied collectively to sets of traffic flows. These sets
of traffic flows are recognized based on BA (DSCP) classification. of traffic flows are recognized based on BA (DSCP) classification.
In this draft, we use the terms 'aggregate traffic control' and In this draft, we use the terms 'aggregate traffic control' and
'diffserv' interchangeably. 'diffserv' interchangeably.
We will refer to RSVP/intserv regions of the network and diffserv Aggregate RSVP. While the existing definition of RSVP supports only
regions of the network. RSVP/intserv regions are those regions in per-flow reservations, extensions to RSVP are being developed to
which both RSVP signaling and MF traffic control are supported. enable RSVP reservations to be made for aggregated traffic, i.e.
These regions include hosts and network elements that are sets of flows that may be recognized by BA classification. This use
RSVP/intserv capable. (RSVP/intserv regions are not precluded from of RSVP may be useful in controlling the allocation of bandwidth in
supporting aggregate traffic control as well as MF traffic control). Diffserv networks.
Diffserv regions are those regions in which aggregate traffic
control is supported.
2.4 The Framework Per-flow RSVP. The conventional usage of RSVP to perform resource
reservations for individual microflows.
RSVP/Intserv - This term is used to refer to the prevailing model of
RSVP usage which includes RSVP signaling with intserv parameters,
intserv admission control and per-flow traffic control at network
elements.
Diffserv Region. A set of contiguous routers which support BA
classification and traffic control. While such a region may also
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
only BA classification is performed inside the diffserv region.
Intserv Region. The portions of the network outside the diffserv
region. We assume MF classification and traffic control is available
in such regions. Such a region may also offer BA classification and
traffic control.
Note that, for the purposes of this document, the key distinction
between an Intserv and a Diffserv region is the type of
classification and traffic control that is used for the delivery of
end-to-end QOS for a particular application. Thus, while it may not
be possible to identify a certain region as _purely Diffserv_ or
_purely Intserv_ with respect to all traffic flowing through the
region, it is possible to make these distinctions from the
perspective of the treatment of traffic from a single application.
2.7 The Framework
In the framework we present, end-to-end, quantitative QoS is In the framework we present, end-to-end, quantitative QoS is
provided by coupling RSVP/Intserv regions at the periphery of the provided by coupling Intserv regions at the periphery of the network
network with diffserv regions in the core of the network. The with diffserv regions in the core of the network. The diffserv
diffserv regions may, but are not required to, participate in the regions may, but are not required to, participate in end-to-end RSVP
end-to-end RSVP signaling for the purpose of optimizing resource
allocation and supporting admission control.
From the perspective of RSVP/intserv, diffserv regions of the Bernet, ed. et al. 4
network are treated as virtual links connecting RSVP/Intserv capable
Bernet, ed. et. al 3 Integrated Services Operation Over Diffserv Networks June, 1999
Use of RSVP with Diffserv March, 1999
routers or hosts (much as an 802.1p network region is treated as a signaling for the purpose of optimizing resource allocation and
virtual link in [5]). Within the diffserv regions of the network supporting admission control.
routers implement specific PHBs (aggregate traffic control). We use
RSVP to apply admission control to each PHB in the diffserv region. From the perspective of Intserv, diffserv regions of the network are
As a result we expect that the diffserv regions of the network will treated as virtual links connecting Intserv capable routers or hosts
be able to extend the intserv style services requested from the (much as an 802.1p network region is treated as a virtual link in
periphery. As such, we often refer to the RSVP/intserv network [5]). Within the diffserv regions of the network routers implement
regions as 'customers' of the diffserv network regions. specific PHBs (aggregate traffic control). The total amount of
traffic that is admitted into the diffserv region that will receive
a certain PHB may be limited by policing at the edge. As a result
we expect that the diffserv regions of the network will be able to
support the intserv style services requested from the periphery. As
such, we often refer to the Intserv network regions as 'customers'
of the diffserv network regions.
In our framework, we address the inter-operability between the In our framework, we address the inter-operability between the
RSVP/intserv regions of the network and the diffserv regions of the Intserv regions of the network and the diffserv regions of the
network. Our goal is to enable seamless inter-operation. As a network. Our goal is to enable seamless inter-operation. As a
result, the network administrator is free to choose which regions of result, the network administrator is free to choose which regions of
the network act as RSVP/intserv regions and which act as diffserv the network act as Intserv regions and which act as diffserv
regions. In one extreme the diffserv region is pushed all the way to regions. In one extreme the diffserv region is pushed all the way to
the periphery, with hosts alone comprising the RSVP/intserv regions the periphery, with hosts alone comprising the Intserv regions of
of the network. In the other extreme, RSVP/intserv is pushed all the the network. In the other extreme, Intserv is pushed all the way to
way to the core, with no diffserv region. the core, with no diffserv region.
2.5 Contents 2.8 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
RSVP/intserv together with the aggregate traffic control provided by the aggregate traffic control provided by diffserv network regions
diffserv network regions. In section 4, we present the framework and in the broader context of the Intserv architecture. In section 4, we
the reference network. Section 5 details two realizations of the present the framework and the reference network. Section 5 details
framework. Section 6 discusses the implications of the framework for two possible realizations of the framework. Section 6 discusses the
diffserv. Appendix A contains a list of some important terms used in implications of the framework for diffserv. Appendix A contains a
this document. list of some important terms used in this document.
Though the primary goal of this draft is to describe a framework Though the primary goal of this draft is to describe a framework
for inter-operation of RSVP/intserv network regions and diffserv for inter-operation of Intserv network regions and diffserv network
network regions, the draft currently does not address the issues regions, the draft currently does not address the issues specific to
specific to IP multicast flows. IP multicast flows.
3. Benefits of Using RSVP/intserv with Diffserv 3. 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 RSVP/intserv can bring to a diffserv network interoperation with Intserv can bring to a diffserv network region.
region. Note that this discussion is in the context of servicing Note that this discussion is in the context of servicing
quantitative applications specifically. quantitative QoS applications specifically. By this we mean those
applications that are able to quantify their traffic and QoS
requirements.
3.1 Resource Based Admission Control 3.1 Resource Based Admission Control
In RSVP/Intserv networks, quantitative QoS applications use RSVP to Bernet, ed. et al. 5
request resources from the network. The network may accept or reject
these requests in response. This is 'explicit admission control'.
Explicit admission control helps to assure that network resources
are optimally used. To further understand this issue, consider a
diffserv network region providing only aggregate traffic control
with no signaling. In the diffserv network region, admission control
is applied implicitly by provisioning policing parameters at network
elements. For example, a network element at the ingress to a
Bernet, ed. et. al 4 Integrated Services Operation Over Diffserv Networks June, 1999
Use of RSVP with Diffserv March, 1999
diffserv network region could be provisioned to accept only 50 Kbps In Intserv networks, quantitative QoS applications use an explicit
of traffic for the EF DSCP. setup mechanism (e.g. RSVP) to request resources from the network.
The network may accept or reject these requests in response. This is
'explicit admission control'. Explicit admission control helps to
assure that network resources are optimally used. To further
understand this issue, consider a diffserv network region providing
only aggregate traffic control with no signaling. In the diffserv
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 implicit admission control does protect the network to
some degree, it can be quite ineffective. For example, consider that some degree, it can be quite ineffective. For example, consider that
there may be 10 IP telephony sessions originating outside the 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 EF, with no regard to the microflow from which it originated. marked EF, with no regard to the microflow from which it originated.
skipping to change at line 257 skipping to change at line 314
In the case of explicit admission control, the network will signal In the case of explicit admission control, the network will signal
rejection in response to requests for resources that would exceed rejection in response to requests for resources that would exceed
the 50 Kbps limit. As a result, upstream network elements (including the 50 Kbps limit. As a result, upstream network elements (including
originating hosts) and applications will have the information they originating hosts) and applications will have the information they
require to take corrective action. The application might respond by require to take corrective action. The application might respond by
refraining from transmitting, or by requesting admission for a refraining from transmitting, or by requesting admission for a
lesser traffic profile. The host operating system might respond by lesser traffic profile. The host operating system might respond by
marking the application's traffic for the DSCP that corresponds to marking the application's traffic for the DSCP that corresponds to
best-effort service. Upstream network elements might respond by re- best-effort service. Upstream network elements might respond by re-
marking packets on the rejected flow to a lower service level. In marking packets on the rejected flow to a lower service level. In
some cases, it may be possible to reroute traffic over alternate
paths or even alternate networks (e.g. the PSTN for voice calls). In
any case, the integrity of those flows that were admitted would be any case, the integrity of those flows that were admitted would be
preserved, at the expense of the flows that were not admitted. Thus, preserved, at the expense of the flows that were not admitted. Thus,
by appointing an RSVP conversant admission control agent for the by appointing an Intserv-conversant admission control agent for the
diffserv region of the network it is possible to enhance the service diffserv region of the network it is possible to enhance the service
that the network can provide to quantitative applications. that the network can provide to quantitative QoS applications.
3.2 Policy Based Admission Control 3.2 Policy Based Admission Control
In an RSVP/intserv network region, 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
Bernet, ed. et al. 6
Integrated Services Operation Over Diffserv Networks June, 1999
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.
By comparison, in diffserv network regions without per-flow RSVP By comparison, in diffserv network regions without RSVP signaling,
signaling, policies are typically applied based on the diffserv policies are typically applied based on the diffserv customer
customer network from which traffic originates, not on the network from which traffic originates, not on the originating user
originating user or application within the customer network. or application within the customer network.
Bernet, ed. et. al 5
Use of RSVP with Diffserv March, 1999
3.3 Assistance in Traffic Identification/Classification 3.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 the DSCP marked in each packet's IP header. Thus, in order to on the DSCP marked in each packet's IP header. Thus, in order to
obtain a particular level of service within the diffserv network obtain a particular level of service within the diffserv network
region, it is necessary to effect the marking of the correct DSCP in region, it is necessary to effect the marking of the correct DSCP in
packet headers. There are two mechanisms for doing so, host marking packet headers. There are two mechanisms for doing so, host marking
and router marking. In the case of host marking, the host operating and 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 (based on MF classification) and to mark the DSCP as packets traffic (typically based on MF classification) and to mark the DSCP
transit the router. There are advantages and disadvantages to each as packets transit the router. There are advantages and
scheme. Regardless of the scheme used, RSVP signaling offers disadvantages to each scheme. Regardless of the scheme used,
significant benefits. explicit signaling offers significant benefits.
3.3.1 Host Marking 3.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 in transmitted packets. This approach has the benefit of DSCP in transmitted packets. This approach has the benefit of
shifting per-flow classification and marking to the edge of the shifting per-flow classification and marking to the edge of the
network, where it scales best. It also enables the host to make network, where it scales best. It also enables the host to make
decisions regarding the mark (and hence the relative priority that decisions regarding the mark that is appropriate for each
is requested) that is appropriate for each transmitted packet. The transmitted packet and hence the relative importance attached to
host is generally better equipped to make this decision than the each packet. The host is generally better equipped to make this
network. decision than the network. Furthermore, if IPSEC encryption is used,
the host may be the only device in the network that is able to make
a meaningful determination of the appropriate marking for each
packet.
Host marking requires that the host be aware of the interpretation Host marking requires that the host be aware of the interpretation
of DSCPs by the network. This information can be configured into of DSCPs by the network. This information can be configured into
each host. However, such configuration imposes a management burden. each host. However, such configuration imposes a management burden.
Alternatively, RSVP/intserv hosts can use RSVP signaling to query Alternatively, hosts can use an explicit signaling protocol such as
the network for a mapping from intserv service type to DSCP. This is RSVP to query the network to obtain a suitable DSCP or set of DSCPs
achieved via the RSVP DCLASS object [17] and is explained later in to apply to packets for which a certain intserv service has been
this draft. requested. An example of how this can be achieved is described in
[14].
3.3.2 Router Marking 3.3.2 Router Marking
Bernet, ed. et al. 7
Integrated Services Operation Over Diffserv Networks June, 1999
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. This may be done dynamically, by request
from the host operating system, or statically via manual from the host operating system, or statically via manual
configuration or via automated scripts. configuration or via automated scripts.
There are significant difficulties in doing so statically. There are significant difficulties in doing so statically.
Typically, it is desirable to allot service to traffic based on the Typically, 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.
Bernet, ed. et. al 6
Use of RSVP with Diffserv March, 1999
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
draft, RSVP signaling is ideally suited for this task. In addition draft, RSVP signaling is ideally suited for this task. In addition
to enabling dynamic and accurate updating of MF classification to enabling dynamic and accurate updating of MF classification
criteria, RSVP signaling enables classification of IPSec [16] criteria, RSVP signaling enables classification of IPSEC [13]
packets (by use of the SPI) which would otherwise be unrecognizable. packets (by use of the SPI) which would otherwise be unrecognizable.
3.4 Traffic Conditioning 3.4 Traffic Conditioning
Those network elements that do provide RSVP/intserv support will Intserv-capable network elements are able to condition traffic at a
condition traffic at a per-flow granularity, by some combination of per-flow granularity, by some combination of shaping and/or
shaping and/or policing. Pre-conditioning traffic in this manner policing. Pre-conditioning traffic in this manner before it is
before it is submitted to the diffserv region of the network is submitted to the diffserv region of the network is beneficial. In
beneficial. In particular, it enhances the ability of the diffserv particular, it enhances the ability of the diffserv region of the
region of the network to provide quantitative services using network to provide quantitative services using aggregate traffic
aggregate traffic control. control.
4. The Framework 4. The Framework
In the general framework we envision an Internet in which hosts use In the general framework we envision an Internet in which the
RSVP/intserv to request reservations for specific services from the Integrated Services architecture is used to deliver end-to-end QOS
network. The network includes some combination of RSVP/intserv to applications. The network includes some combination of Intserv
regions (in which MF classification and per-flow traffic control is regions (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 in RSVP applied). Individual routers may or may not participate in RSVP
signaling regardless of the type of network region in which they signaling regardless of the type of network region in which they
reside. 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
Bernet, ed. et al. 8
Integrated Services Operation Over Diffserv Networks June, 1999
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 4.1 Reference Network
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 |
|---| | |-- | |---| |---| |---| | |---| |---| | |-- | |---| |---| |---| | |---|
\ / \ / \ / \ / \ / \ /
\______ / \___ _________ / \__ _____/ \______ / \___ _________ / \__ _____/
RSVP/Intserv region Diffserv region RSVP/Intserv region Intserv region Diffserv region Intserv region
Figure 1: Sample Network Configuration Figure 1: Sample Network Configuration
Bernet, ed. et. al 7
Use of RSVP with Diffserv March, 1999
The reference network includes a diffserv region interconnecting two The reference network includes a diffserv region interconnecting two
RSVP/intserv regions. The diffserv region contains a mesh of Intserv regions. The diffserv region contains a mesh of routers, at
routers, at least some of which provide aggregate traffic control. least some of which provide aggregate traffic control. The Intserv
The RSVP/intserv regions contain meshes of routers and attached regions contain meshes of routers and attached hosts, at least some
hosts, at least some of which are RSVP/intserv capable. of which support the Integrated Services architecture.
In the interest of simplicity we consider a single QoS sender, Tx in In the interest of simplicity we consider a single QoS sender, Tx in
one of the RSVP/intserv network regions and a single QoS receiver, one of the Intserv network regions and a single QoS receiver, Rx in
Rx in the other. The edge routers (ER1, ER2) within the RSVP/intserv the other. The edge routers (ER1, ER2) within the Intserv regions
regions interface to the border routers (BR1, BR1) within the interface to the border routers (BR1, BR1) within the diffserv
diffserv regions. regions.
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 RSVP/intserv regions, which provide service to sells service to the Intserv regions, which provide service to
hosts. Thus, we may think of the RSVP/intserv regions as customers hosts. Thus, we may think of the Intserv regions as customers of
of the diffserv region. In the following, we use the term the diffserv region. In the following, we use the term 'customer'
'customer' for the RSVP/intserv regions. for the Intserv regions. Note that the boundaries of the regions may
or may not align with administrative domain boundaries, and that a
4.1.1 Components of the Reference Network single region 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.1 Hosts 4.1.1 Hosts
Both sending and receiving hosts use RSVP/intserv to communicate the We assume that both sending and receiving hosts use RSVP to
quantitative QoS requirements of QoS-aware applications running on communicate the quantitative QoS requirements of QoS-aware
the host. Typically, a QoS process within the host operating system applications running on the host. In principle, other mechanisms may
generates RSVP signaling on behalf of applications. This process may be used to establish resource reservations in an Intserv region, but
also invoke local traffic control. RSVP is clearly the prevalent mechanism for this purpose.
In this example, traffic control in the host marks the DSCP in Bernet, ed. et al. 9
transmitted packets, and it shapes transmitted traffic to the
requirements of the intserv service in use. In alternate
realizations of the framework, the first-hop router within the
RSVP/intserv network regions may provide these traffic control
functions.
4.1.1.2 End-to-End RSVP Signaling Integrated Services Operation Over Diffserv Networks June, 1999
Typically, a QoS process within the host operating system generates
RSVP signaling on behalf of applications. This process may also
invoke local traffic control.
As discussed above, traffic control in the host may mark the DSCP in
transmitted packets, and shape transmitted traffic to the
requirements of the intserv service in use. Alternatively, the
first-hop router within the Intserv network regions may provide
these traffic control functions.
4.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 in the hosts Tx and Rx to support RSVP/intserv reservations in the Intserv
RSVP/intserv network regions. We require that these end-to-end RSVP network regions. We require that these end-to-end RSVP messages are
messages are carried across the diffserv region. Depending on the carried across the diffserv region. Depending on the specific
specific realization of the framework, these messages may be realization of the framework, these messages may be processed by
processed by none, some or all of the routers in the diffserv none, some or all of the routers in the diffserv region.
region.
4.1.1.3 Edge Routers 4.1.3 Edge Routers
ER1 and ER2 are edge routers, residing in the RSVP/intserv network ER1 and ER2 are edge routers, residing in the Intserv network
regions. The functionality of the edge routers varies depending on regions. The functionality of the edge 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, edge routers act as diffserv network region is RSVP unaware, edge routers act as
admission control agents to the diffserv network. They process admission control agents to the diffserv network. They process
Bernet, ed. et. al 8
Use of RSVP with Diffserv March, 1999
signaling messages from both Tx and Rx, and apply admission control signaling messages from both Tx and Rx, and apply admission control
based on resource availability within the diffserv network region based on resource availability within the diffserv network region
and on customer defined policy. In the case in which the diffserv and on customer defined policy. In the case in which the diffserv
network region is RSVP aware, the edge routers apply admission network region is RSVP aware, the edge routers apply admission
control based on local resource availability and on customer defined control based on local resource availability and on customer defined
policy. In this case, the border routers act as the admission policy. In this case, the border routers act as the admission
control agent to the diffserv network region. 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.1.4 Border Routers 4.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/intserv unaware, these routers act diffserv network region is RSVP-unaware, these routers act as pure
as pure diffserv routers. As such, their sole responsibility is to diffserv routers. As such, their sole responsibility is to police
police submitted traffic based on the service level specified in the submitted traffic based on the service level specified in the DSCP
DSCP and the agreement negotiated with the customer (aggregate and the agreement negotiated with the customer (aggregate traffic
traffic control). In the case in which the diffserv network region control). In the case in which the diffserv network region is RSVP-
is RSVP/intserv aware, the border routers participate in RSVP aware, the border routers participate in RSVP signaling and act as
signaling and act as admission control agents for the diffserv admission control agents for the diffserv network region.
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.
4.1.1.5 RSVP/Intserv Network Regions Bernet, ed. et al. 10
Each RSVP/intserv network region consists of RSVP/intserv capable Integrated Services Operation Over Diffserv Networks June, 1999
hosts and some number of routers. These routers may reasonably be
assumed to be RSVP/intserv capable, although this might not be
required in the case of a small, over-provisioned network region. If
they are not RSVP/intserv capable, we assume that they will pass
RSVP messages unhindered. Routers in the RSVP/intserv network region
are not precluded from providing aggregate traffic control to non-
quantitative traffic passing through them.
4.1.1.6 Diffserv Network Region 4.1.5 Intserv Network Regions
Each Intserv network region consists of Intserv capable hosts and
some number of routers. These routers may reasonably be assumed to
be Intserv capable, although this might not be required in the case
of a small, over-provisioned network region. Even if they are not
Intserv capable, we assume that they will pass RSVP messages
unhindered. Routers in the Intserv network region are not precluded
from providing aggregate traffic control to some subset of the
traffic passing through them.
4.1.6 Diffserv Network Region
The diffserv network region supports aggregate traffic control and The diffserv network region supports aggregate traffic control and
is not capable of MF classification. Depending on the specific is assumed not to be capable of MF classification. Depending on the
realization of the framework, some number of routers within the specific realization of the framework, some number of routers within
diffserv region may be RSVP aware and therefore capable of per-flow the diffserv region may be RSVP aware and therefore capable of per-
signaling and admission control. If devices in the diffserv region flow signaling and admission control. If devices in the diffserv
are not RSVP aware, they will pass RSVP messages transparently with region are not RSVP aware, they will pass RSVP messages
negligible performance impact (see [8]). transparently 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 include sub-regions based on the DSCP in packet headers. It may include sub-regions
managed as different administrative domains. managed as different administrative domains.
4.1.1.7 Service Mapping 4.2 Service Mapping
Bernet, ed. et. al 9
Use of RSVP with Diffserv March, 1999
RSVP/intserv signaling requests specify an intserv service type and Intserv service requests specify an intserv service type and a set
a set of quantitative parameters known as a 'flowspec'. At each hop of quantitative parameters known as a 'flowspec'. At each hop in an
in an intserv network, the RSVP/intserv service requests are intserv network, the Intserv service requests are interpreted in a
interpreted in a form meaningful to the specific link layer medium. form meaningful to the specific link layer medium. For example at
For example at an 802.1 hop, the intserv parameters are mapped to an an 802.1 hop, the intserv parameters are mapped to an appropriate
appropriate 802.1p priority level [5]. 802.1p 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]. Admission the 802.1p capable switched segments described in [5]. Requests for
control agents for diffserv network regions must map intserv service Intserv services must be mapped onto the underlying capabilities of
types to a corresponding diffserv service level (DSCP or PHB) that the Diffserv network region. Aspects of the mapping include:
can reasonably extend the intserv service type requested by the
application. The admission control agent can then approve or reject
resource requests based on the capacity available in the diffserv
network region at the mapped service level.
One of two schemes may be used to map intserv service types to - selecting an appropriate PHB, or set of PHBs, for the requested
diffserv service levels. service;
- performing appropriate policing (including, perhaps, shaping or
remarking) at the edges of the Diffserv region;
- exporting Intserv parameters from the Diffserv region (e.g. for
the updating of ADSPECs);
- performing admission control on the Intserv requests that takes
into account the resource availability in the Diffserv region.
4.1.1.7.1 Default Mapping Exactly how these functions are performed will be a function of the
way bandwidth is managed inside the Diffserv network region, which
is a topic we discuss in Section 4.3.
Bernet, ed. et al. 11
Integrated Services Operation Over Diffserv Networks June, 1999
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
for the flow to other network elements. Two schemes may be used to
achieve this end, as discussed below.
4.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.1.1.7.2 Network Driven Mapping 4.2.2 Network Driven Mapping
In this scheme, RSVP aware routers in the diffserv network region In this scheme, RSVP conversant routers in the diffserv network
may override the well-known mapping described in 4.1.1.7.1. RSVP region (perhaps at its edge) may override the well-known mapping
RESV messages originating from receivers will carry the usual described in 4.2.1. In the case that DSCPs are marked at the ingress
intserv service type. RSVP aware routers within the diffserv network to the Diffserv region, the DSCPs can simple be remarked at the
region may append a DCLASS [17] object to RESV messages as they are boundary routers. However, in the case that DSCP marking occurs
forwarded upstream. When a RESV message carrying a DCLASS object upstream of the Diffserv region, either in a host or a router, then
arrives at a sending host (or in the case of router marking, at an the appropriate mapping needs to be communicated Upstream, to the
intermediate router), the sender starts marking transmitted packets marking device. This may be accomplished using RSVP, as described
with the DSCP indicated. in [14].
A decision to override the well-known service mapping may be based The decision regarding where to mark DSCP and whether to override
on configuration and/or a policy decision. the well-known service mapping is a mater of policy to be decided by
the administrator of the diffserv network region in cooperation with
the administrator of the intserv network region.
5. Detailed Examples of the Interoperation of RSVP/Intserv and Diffserv 4.2.3 Microflow Separation
Boundary routers residing at the edge of the Diffserv region will
typically police traffic submitted from the Intserv region in order
to protect resources within the Diffserv region. This policing will
be applied on an aggregate basis, with no regard for the individual
microflows making up each aggregate. As a result, it is possible for
a misbehaving microflow to claim more than its fair share of
resources within the aggregate, thereby degrading the service
provided to other microflows. This problem may be addressed by:
1. Providing per microflow policing at the edge routers - this is
generally the most appropriate location for microflow policing,
since it pushes per-flow work to the edges of the network, where it
scales better. In addition, since the intserv region is responsible
for providing microflow service to its customers and the diffserv
region is responsible for providing aggregate service to its
customers, this distribution of functionality mirrors the
distribution of responsibility.
2. Providing per microflow policing at the border routers - this
approach tends to be less scalable than the previous approach. It
also imposes a management burden on the diffserv region of the
Bernet, ed. et al. 12
Integrated Services Operation Over Diffserv Networks June, 1999
network. However, it may be appropriate in certain cases, for the
diffserv boundary routers to offer per microflow policing as a
value-add to its intserv customers.
3. Relying on upstream shaping and policing - in certain cases, the
customer may trust the shaping of certain groups of hosts
sufficiently to not warrant reshaping or policing at the boundary
between the intserv and diffserv regions. Note that, even if the
hosts are shaping microflows properly, these shaped flows may become
distorted as they transit through the intserv region of the network.
Depending on the degree of distortion, it may be necessary to
somewhat over-provision the aggregate capacities in the diffserv
region, or to re-police using either 1 or 2 above.
The choice of one mechanism or another is a matter of policy to be
decided by the administrator of the intserv network region.
4.3 Resource Management in Diffserv Regions
A variety of options exist for management of resources (e.g.,
bandwidth) in the Diffserv network regions to meet the needs of end-
to-end Intserv flows. These options include:
- statically provisioned resources;
- resources dynamically provisioned by RSVP;
- resources dynamically provisioned by other means (e.g., a form of
Bandwidth Broker).
Some of the details of using each of these different approaches are
discussed in the following section.
5. 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 RSVP Unaware Diffserv Network Region 5.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
owner(s) of the RSVP/intserv network regions and the owner of the owner(s) of the Intserv 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
provided to the customer at each of a number of standard diffserv
service levels. The _transmit capacity_ may be simply an amount of
bandwidth or it could be a more complex _profile_ involving a number
of factors such as burst size, peak rate, time of day etc.
Bernet, ed. et. al 10 It is helpful to consider each edge router in the customer network
Use of RSVP with Diffserv March, 1999 as consisting of two halves, a standard Intserv half, which
level agreement, or SLA) for the transmit capacity to be provided to Bernet, ed. et al. 13
the customer at each of a number of standard diffserv service
levels.
It is helpful to consider the edge routers in the customer network, Integrated Services Operation Over Diffserv Networks June, 1999
to consist of two halves, a standard RSVP/intserv half, which
interfaces to the customer's RSVP/intserv network regions and a interfaces to the customer's Intserv network regions and a diffserv
diffserv half which interfaces to the diffserv network region. The half which interfaces to the diffserv network region. The Intserv
RSVP/intserv half has full RSVP capability. It is able to half is able to identify and process traffic on per-flow
participate in RSVP signaling and it is able to identify and process granularity.
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 SLA. The router contains a table that level negotiated in the SLS. The router contains a table that
indicates the transmit capacity provisioned, per the SLA 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.1.1.7.1, is used to apply admission control mapping described in 4.2.1, is used to perform admission control
decisions to 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 5.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. application obtains end-to-end QoS when RSVP is used within the
Intserv region.
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
RSVP/intserv network region to which the sender is attached, Intserv network region to which the sender is attached, standard
standard RSVP/intserv processing is applied at capable network RSVP/intserv processing is applied at capable network elements.
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 carried transparently through the diffserv 4. The PATH message is ignored by routers in the diffserv network
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 system generates an RSVP RESV message, indicating interest operating system generates an RSVP RESV message, indicating interest
in offered traffic of a certain intserv service type. in offered 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 node in the RSVP/intserv processing, it may be rejected at any RSVP node in the Intserv
network region if resources are deemed insufficient to carry the network region if resources are deemed insufficient to carry the
traffic requested. 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
Bernet, ed. et. al 11
Use of RSVP with Diffserv March, 1999
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 June, 1999
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 SLA. 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 SLA. 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 RSVP/intserv network 10. The RESV message proceeds through the Intserv network region to
region to which the sender is attached. Any RSVP node in this region which the sender is attached. Any RSVP node in this region may
may reject the reservation request due to inadequate resources or reject the reservation request due to inadequate resources or
policy. If the request is not rejected, the RESV message will arrive policy. If the request is not rejected, the RESV message will arrive
at the sending host, Tx. at the sending 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
RSVP/intserv network regions) and for the corresponding diffserv Intserv network regions) and for the corresponding diffserv service
service level (in the diffserv network regions). level (in the diffserv network regions). It may also learn the
appropriate DSCP marking to apply to packets for this flow from
information provided in the RESV.
12. Tx begins to 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 is the value transmitted on the admitted traffic flow. The DSCP may be the
which maps to the intserv service type specified in the admitted default value which maps to the intserv service type specified in
RESV message. the admitted RESV message, or it may be a value explicitly provided
in 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 5.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 RSVP signaling, they process traffic in aggregate, based on DSCP, in some form of RSVP signaling, they classify and schedule traffic
not on the per-flow classification criteria used by standard in aggregate, based on DSCP, not on the per-flow classification
RSVP/Intserv routers. It can be said that their control-plane is criteria used by standard RSVP/Intserv routers. It can be said that
RSVP while their data-plane is diffserv. This approach exploits the their control-plane is RSVP while their data-plane is diffserv. This
Bernet, ed. et. al 12 Bernet, ed. et al. 15
Use of RSVP with Diffserv March, 1999
benefits of RSVP signaling while maintaining much of the scalability Integrated Services Operation Over Diffserv Networks June, 1999
associated with diffserv.
In the former example, there is no RSVP signaling between the approach exploits the benefits of RSVP signaling while maintaining
RSVP/intserv network regions and the diffserv network region. The much of the scalability associated with diffserv.
negotiation of an SLA is the only explicit exchange of resource
availability information between the two network regions. ER1 is In the preceding example, there is no signaling between the Intserv
configured with the information represented by the SLA and as such, network regions and the diffserv network region. The negotiation of
is able to act as an admission control agent for the diffserv an SLS is the only explicit exchange of resource availability
network region. Such configuration does not readily support information between the two network regions. ER1 is configured with
dynamically changing SLAs, since ER1 requires reconfiguration each the information represented by the SLS and as such, is able to act
time the SLA changes. It is also difficult to make efficient use of as an admission control agent for the diffserv network region. Such
the resources in the diffserv network region. This is because configuration does not readily support dynamically changing SLSs,
admission control does not consider the availability of resources in since ER1 requires reconfiguration each time the SLS changes. It is
the diffserv network region along the specific path that would be also difficult to make efficient use of the resources in the
impacted. diffserv network region. This is because admission control does not
consider the availability of resources in the diffserv network
region along 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 RSVP/intserv network regions via region can be indicated to the Intserv network regions via RSVP. By
traditional RSVP. By including routers interior to the diffserv including routers interior to the diffserv network region in RSVP
network region in RSVP signaling, it is possible to improve the signaling, it is possible to simultaneously improve the efficiency
efficiency of resource usage. This is because admission control can of resource usage within the diffserv region and to improve the
be linked to the availability of resources along the specific path level of confidence that the resources requested at admission
that would be impacted. We refer to this benefit of RSVP signaling control are indeed available at this particular point in time. This
as 'topology aware admission control'. A further benefit of is because admission control can be linked to the availability of
supporting RSVP signaling within the diffserv network region is that resources along the specific path that would be impacted. We refer
it is possible to effect changes in the provisioning of the diffserv to this benefit of RSVP signaling as 'topology aware admission
network region response to resource requests from the RSVP/intserv control'. A further benefit of supporting RSVP signaling within the
network regions. diffserv network region is that it is possible to effect changes in
the provisioning of the diffserv network region (e.g., allocating
more or less bandwidth to the EF queue in a router) in response to
resource requests from the RSVP/intserv network regions.
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 5.2.1 Aggregated or Tunneled RSVP
A number of drafts [8,10,18, 19] propose mechanisms for extending A number of drafts [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 routers, based on anticipated traffic patterns. Border border routers, based on anticipated traffic patterns. Border
routers could trigger changes in reservation levels as a result of routers could trigger changes in reservation levels as a result of
the cumulative per-flow RSVP requests from peripheral RSVP/intserv the cumulative per-flow RSVP requests from peripheral RSVP/intserv
network regions reaching high or low-water marks. network regions reaching high or low-water marks.
Bernet, ed. et al. 16
Integrated Services Operation Over Diffserv Networks June, 1999
In this approach, admission of per-flow RSVP requests from In this approach, admission of per-flow RSVP requests from
RSVP/intserv networks would be counted against the appropriate RSVP/intserv networks would be counted against the appropriate
aggregate reservations for the corresponding service level. aggregate reservations for the corresponding service level. The size
of the aggregate reservations may or may not be dynamically adjusted
Bernet, ed. et. al 13 to deal with the changes in per-flow reservations.
Use of RSVP with Diffserv March, 1999
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.
5.2.3 Per-flow RSVP 5.2.3 Per-flow RSVP
In this approach, routers in the diffserv network region respond to In this approach, described in [3], routers in the diffserv network
the standard per-flow RSVP signaling originating from the region respond to the standard per-flow RSVP signaling originating
RSVP/intserv network regions. This approach provides the benefits of from the Intserv network regions. This approach provides the
the previous approach (dynamic, topology aware admission control) benefits of the previous approach (dynamic, topology aware admission
without requiring aggregated RSVP support. Resources are also used control) without requiring aggregated RSVP support. Resources are
more efficiently as a result of the per-flow admission control. also used more efficiently as a result of the per-flow admission
However, the demands on RSVP signaling resources within the diffserv control. However, the demands on RSVP signaling resources within the
network region may be significantly higher. diffserv network region may be significantly higher than in an
aggregated RSVP approach.
5.2.4 Oracle
Border routers might not use any form of RSVP signaling within the Note that per-flow RSVP and aggregated RSVP are not mutually
diffserv network region but might instead use custom protocols to exclusive in a single diffserv region. It is possible to use per-
interact with an 'oracle'. The oracle is a hypothetical agent that flow RSVP at the edges of the diffserv region and aggregation only
has sufficient topology awareness to make admission control in some _core_ region within the diffserv region.
decisions. The set of RSVP aware routers in the previous two
examples can be considered collectively as a distributed oracle. In
various definitions of the 'bandwidth broker' [4], it is able to act
as a centralized oracle.
5.2.5 Granularity of Deployment of RSVP Aware Routers 5.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 5.2.2 and 5.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 as opposed to per-flow). The relative number of routers aggregated as opposed to per-flow). The relative number of routers
in the core that participate in RSVP signaling is a provisioning in the core that participate in RSVP signaling is a provisioning
decision that must be made by the network administrator. decision that 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 it must be carefully and statically provisioned for limited else it must be carefully and statically provisioned for limited
traffic patterns. The border routers must enforce these patterns. traffic patterns. The border routers must enforce these patterns.
In the other extreme case, each router in the diffserv network In the other extreme case, each router in the diffserv network
region might participate in RSVP signaling. In this case, resources region might participate in RSVP signaling. In this case, resources
can be used with optimal efficiency, but signaling processing can be used with optimal efficiency, but signaling processing
requirements and associated overhead increase. 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 network administrators will compromise by enabling It is likely that some network administrators will compromise by
RSVP signaling on some subset of routers in the diffserv network enabling RSVP signaling on some subset of routers in the diffserv
region. These routers will likely represent major traffic switching network region. These routers will likely represent major traffic
points with over-provisioned or statically provisioned regions of
RSVP unaware routers between them.
6. Implications of the Framework for DiffServ Network Regions Bernet, ed. et al. 17
Bernet, ed. et. al 14 Integrated Services Operation Over Diffserv Networks June, 1999
Use of RSVP with Diffserv March, 1999
switching points with over-provisioned or statically provisioned
regions of RSVP unaware routers between them.
5.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region
Border routers might not use any form of RSVP signaling within the
diffserv network region but might instead use custom protocols to
interact with an 'oracle'. The oracle is a hypothetical agent that
has sufficient knowledge of resource availability and network
topology to make admission control decisions. The set of RSVP aware
routers in the previous two examples can be considered collectively
as a form of distributed oracle. In various definitions of the
'bandwidth broker' [4], it is able to act as a centralized oracle.
6. 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 6.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 draft. order for it to support the framework described in this draft.
1. A diffserv network region must be able to provide standard QoS 1. A diffserv network region must be able to provide support for the
services between its border routers. It must be possible to invoke standard intserv QoS services between its border routers. It must be
these services by use of a standard DSCP. possible to invoke these services by use of standard PHBs within the
diffserv region and appropriate behavior at the edge of the diffserv
2. There must be appropriate service mappings from intserv service region.
types to these diffserv services.
3. Diffserv network regions must provide admission control 2. Diffserv network regions must provide admission control
information to intserv network regions. This information can be information to intserv network regions. This information can be
provided by a dynamic protocol or, at the very least, through static provided by a dynamic protocol or through static service level
service level agreements. agreements enforced at the edges of the diffserv region.
4. 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
[8,10,18, 19]. [3,6,15, 16].
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.
Bernet, ed. et al. 18
Integrated Services Operation Over Diffserv Networks June, 1999
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.). tunneling, MPLS, etc.). This might include protocols by which an
_oracle_ conveys information about resource availability within a
diffserv region to border routers.
6.2 Protection of Intserv Traffic from Other Traffic 6.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. RSVP/intserv signaled - this is traffic associated with a. End-to-end Intserv traffic - this is typically traffic
quantitative applications. It requires a specific quantity of associated with quantitative QoS applications. It requires a
resources with a high degree of assurance. specific quantity of resources with a high degree of assurance.
b. Qualitative - this is traffic associated with applications that b. Non-intserv traffic. The Diffserv region may allocate resources
are not quantitative. Its resource requirements are not readily to traffic that does not make use of intserv techniques to quantify
quantifiable. It requires a 'better than best-effort' level of its requirements, e.g. through the use of static provisioning and
SLSs enforced at the edges of the region. Such traffic might be
associated with applications whose QoS requirements are not readily
quantifiable but which require a 'better than best-effort' level of
service. service.
Bernet, ed. et. al 15
Use of RSVP with Diffserv March, 1999
c. All other (best-effort) traffic c. All other (best-effort) traffic
These classes of traffic must be isolated from each other by the These three classes of traffic must be isolated from each other by
appropriate configuration of policers and classifiers at ingress the appropriate configuration of policers and classifiers at ingress
points to the diffserv network region, and by appropriate points to the diffserv network region, and by appropriate
provisioning within the diffserv network region. To provide provisioning within the diffserv network region. To provide
protection for RSVP/intserv signaled traffic in diffserv regions of protection for Intserv traffic in diffserv regions of the network,
the network, we suggest that the DSCPs assigned to such traffic not we suggest that the DSCPs assigned to such traffic not overlap with
overlap with the DSCPs assigned to other traffic. the DSCPs assigned to other traffic.
7. Multicast 7. Multicast
To be written. To be written.
8. Security Considerations 8. Security Considerations
8.1 General RSVP Security 8.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 RSVP/intserv regions of a network. Therefore, all both diffserv and Intserv regions of a network. Therefore, all RSVP
RSVP security considerations apply [11]. In addition, network 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 8.2 Host Marking
Though it does not mandate host marking, our proposal does recommend Bernet, ed. et al. 19
it. Allowing hosts to set the DSCP directly may alarm network
administrators. The obvious concern is that hosts may attempt to Integrated Services Operation Over Diffserv Networks June, 1999
'steal' resources. In fact, hosts may attempt to exceed negotiated
capacity in diffserv network regions at a particular service level Though it does not mandate host marking of the DSCP, our proposal
regardless of whether they invoke this service level directly (by does allow it. Allowing hosts to set the DSCP directly may alarm
setting the DSCP) or indirectly (by submitting traffic that network administrators. The obvious concern is that hosts may
classifies in an intermediate marking router to a particular diff- attempt to 'steal' resources. In fact, hosts may attempt to exceed
serv DSCP). negotiated capacity in diffserv network regions at a particular
service level regardless of whether they invoke this service level
directly (by setting the DSCP) or indirectly (by submitting traffic
that classifies in an intermediate marking router to a particular
diff-serv DSCP).
In either case, it will be necessary for each diffserv network In either case, it will be necessary for each diffserv network
region to protect its resources by policing to assure that customers region to protect its resources by policing to assure that customers
do not use more resources than they are entitled to, at each service do not use more resources than they are entitled to, at each service
level (DSCP). If the sending host does not do the marking, the level (DSCP). If the sending host does not do the marking, the
boundary router (or trusted intermediate routers) must provide MF boundary router (or trusted intermediate routers) must provide MF
classification, mark and police. If the sending host does do the classification, mark and police. If the sending host does do the
marking, the boundary router needs only to provide BA classification marking, the boundary router needs only to provide BA classification
and to police to ensure that the customer is not exceeding the and to police to ensure that the customer is not exceeding the
aggregate capacity negotiated for the service level. aggregate capacity negotiated for the service level.
In summary, the security concerns of marking the DSCP at the edge of In summary, there are no additional security concerns raised by
the network can be dismissed since each diffserv provider will have marking the DSCP at the edge of the network since diffserv providers
to police at their boundary anyway. Furthermore, this approach will have to police at their boundaries anyway. Furthermore, this
reduces the granularity at which border routers must police, thereby approach reduces the granularity at which border routers must
pushing finer grain shaping and policing responsibility to the edges police, thereby pushing finer grain shaping and policing
of the network, where it scales better. The larger diffserv network responsibility to the edges of the network, where it scales better.
regions are thus focused on the task of protecting their networks, The larger diffserv network regions are thus focused on the task of
protecting their networks, while the Intserv network regions are
Bernet, ed. et. al 16 focused on the task of shaping and policing their own traffic to be
Use of RSVP with Diffserv March, 1999 in compliance with their negotiated intserv parameters.
while the RSVP/intserv network regions are focused on the task of
shaping and policing their own traffic to be in compliance with
their negotiated intserv parameters.
7. Acknowledgments 9. 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 draft: David to improvements to the previous version(s) of this draft: David
Oran, Andy Veitch, Curtis Villamizer, Walter Weiss, and Russel Oran, Andy Veitch, Curtis Villamizer, Walter Weiss, Francois le
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 [12]. the original intserv architecture document [10].
8. References 10. References
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S.,
"Resource Reservation Protocol (RSVP) Version 1 Functional "Resource Reservation Protocol (RSVP) Version 1 Functional
Specification", RFC 2205, Proposed Standard, September 1997 Specification", RFC 2205, Proposed Standard, September 1997
[2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M., [2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M.,
"SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based "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", Internet Draft,
Bernet, ed. et al. 20
Integrated Services Operation Over Diffserv Networks June, 1999
[3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated [3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated
Services State", Internet Draft, December 1997. Services State", Internet Draft, draft-berson-rsvp-aggregation-
00.txt, August 1998.
[4] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit [4] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit
Differentiated Services Architecture for the Internet", Internet Differentiated Services Architecture for the Internet", Internet
Draft, December 1997. Draft, draft-nichols-diff-svc-arch-01.txt, April 1999.
[5] Seaman, M., Smith, A. and Crawley, E., "Integrated Services Over
[6] Elleson, E. and Blake, S., "A Proposal for the Format and
Semantics of the TOS Byte and Traffic Class Byte in Ipv4 and
Ipv6 Headers", Internet Draft, November 1997
[7] Ferguson, P., "Simple Differential Services: IP TOS and [5] Seaman, M., Smith, A., Crawley, E., and Wroclawski, J.,
Precedence, Delay Indication, and Drop Preference", Internet "Integrated Service Mappings on IEEE 802 Networks", Internet
[8] Guerin, R., Blake, S. and Herzog, S.,"Aggregating RSVP based QoS [6] Guerin, R., Blake, S. and Herzog, S.,"Aggregating RSVP based QoS
Requests", Internet Draft, November 1997. Requests", Internet Draft, draft-guerin-aggreg-rsvp-00.txt,
November 1997.
[9] Nichols, Kathleen, et al., "Definition of the Differentiated [7] Nichols, Kathleen, et al., "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC
2474, December 1998. 2474, December 1998.
[10] Blake, S., et al., "An Architecture for Differentiated [8] Blake, S., et al., "An Architecture for Differentiated
Services." RFC 2475, December 1998. Services." RFC 2475, December 1998.
[11] Baker, F., "RSVP Cryptographic Authentication", Internet Draft, [9] Baker, F., "RSVP Cryptographic Authentication", Internet Draft,
draft-ietf-rsvp-md5-08.txt, February 1999
Bernet, ed. et. al 17
Use of RSVP with Diffserv March, 1999
August 1997
[12] Braden, R., Clark, D. and Shenker, S., "Integrated Services in [10] Braden, R., Clark, D. and Shenker, S., "Integrated Services in
the Internet Architecture: an Overview", Internet RFC 1633, the Internet Architecture: an Overview", Internet RFC 1633,
[13] Garrett, M. W., and Borden, M., "Interoperation of Controlled- [11] Garrett, M. W., and Borden, M., "Interoperation of Controlled-
Load Service and Guaranteed Service with ATM", RFC2381, August Load Service and Guaranteed Service with ATM", RFC2381, August
1998. 1998.
[14] Weiss, Walter, Private communication, November 1998. [12] Weiss, Walter, Private communication, November 1998.
[15] Berson, S. and Vincent, S., "Aggregation of Internet Integrated
Services State", Internet Draft, August 1998.
[16] Kent, S., Atkinson, R., "Security Architecture for the Internet [13] Kent, S., Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 2401, November 1998. Protocol", RFC 2401, November 1998.
[17] Bernet, Y., "Usage and Format of the DCLASS Object with RSVP [14] Bernet, Y., "Usage and Format of the DCLASS Object with RSVP
Signaling", Internet Draft, February 1999. Signaling", Internet Draft, draft-bernet-dclass-00.txt,
February 1999.
[18] Baker, F., Iturralde, C., "RSVP Reservation Aggregation", [15] Baker, F., Iturralde, C., le Faucheur, F., and Davie, B. "RSVP
Internet Draft, February 1999. Reservation Aggregation", Internet Draft, draft-baker-rsvp-
aggregation-00.txt, February 1999.
[19] Terzis, A., Krawczyk, J., Wroclawski, J., Zhang, L., "RSVP [16] Terzis, A., Krawczyk, J., Wroclawski, J., Zhang, L., "RSVP
Operation Over IP Tunnels", Internet Draft, February 1999. Operation Over IP Tunnels", Internet Draft, draft-ietf-rsvp-
tunnel-03.txt, April 1999.
Bernet, ed. et al. 21
Integrated Services Operation Over Diffserv Networks June, 1999
[17] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, D., and
Sastry, A., _COPS Usage for RSVP_, Internet Draft, draft-ietf-
rap-cops-rsvp-05.txt, June 1999.
Author's Addresses: Author's Addresses:
Yoram Bernet Yoram Bernet
Microsoft Microsoft
One Microsoft Way, Redmond, WA 98052 One Microsoft Way, Redmond, WA 98052
Phone: (425) 936-9568 Phone: (425) 936-9568
Email: yoramb@microsoft.com Email: yoramb@microsoft.com
Raj Yavatkar Raj Yavatkar
skipping to change at line 1021 skipping to change at line 1199
Phone: (425) 703-2032 Phone: (425) 703-2032
Email: peterf@microsoft.com Email: peterf@microsoft.com
Fred Baker Fred Baker
Cisco Systems Cisco Systems
519 Lado Drive, Santa Barbara, CA 93111 519 Lado Drive, Santa Barbara, CA 93111
Phone: (408) 526-4257 Phone: (408) 526-4257
Email: fred@cisco.com Email: fred@cisco.com
Lixia Zhang Lixia Zhang
Bernet, ed. et. al 18
Use of RSVP with Diffserv March, 1999
UCLA UCLA
4531G Boelter Hall Los Angeles, CA 90095 4531G Boelter Hall Los Angeles, CA 90095
Phone: +1 310-825-2695 Phone: +1 310-825-2695
Email: lixia@cs.ucla.edu 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 Palo Alto, CA 94303
Phone: +1 650-786-6368 Phone: +1 650-786-6368
Email: speer@Eng.Sun.COM Email: speer@Eng.Sun.COM
Bob Braden Bob Braden
USC Information Sciences Institute USC Information Sciences Institute
4676 Admiralty Way Marina del Rey, CA 90292-6695 4676 Admiralty Way Marina del Rey, CA 90292-6695
Phone: 310-822-1511 Phone: 310-822-1511
Email: braden@isi.edu Email: braden@isi.edu
This draft expires September, 1999 Bruce Davie
Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824
Phone: (978)-244-8000
Bernet, ed. et. al 19 Bernet, ed. et al. 22
Integrated Services Operation Over Diffserv Networks June, 1999
Email: bsd@cisco.com
This draft expires December, 1999
Bernet, ed. et al. 23
 End of changes. 152 change blocks. 
457 lines changed or deleted 634 lines changed or added

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