RFC relevance of integrated

As per Relevance of the word integrated, we have this rfc below:

Network Working Group Y.
Request for Comments: 2998 P.
Category: Informational
R.

F.

L.

M.
Sun
R.

B.

J.
MIT
E.

November 2000

A Framework for Integrated Services Operation over Diffserv

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited

Copyright

Copyright (C) The Internet Society (2000). All Rights Reserved

The Integrated Services (Intserv) architecture provides a means
the delivery of end-to-end Quality of Service (QoS) to
over heterogeneous networks. To support this end-to-end model,
Intserv architecture must be supported over a wide variety
different types of network elements. In this context, a network
supports Differentiated Services (Diffserv) may be viewed as
network element in the total end-to-end path. This
describes a framework by which Integrated Services may be
over Diffserv networks

Bernet, et al. Informational [Page 1]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

Table of

1. Introduction ................................................. 3
1.1 Integrated Services Architecture ............................ 3
1.2 RSVP ........................................................ 3
1.3 Diffserv .................................................... 4
1.4 Roles of Intserv, RSVP and Diffserv ......................... 4
1.5 Components of Intserv, RSVP and Diffserv .................... 5
1.6 The Framework ............................................... 6
1.7 Contents .................................................... 6
2. Benefits of Using Intserv with Diffserv ...................... 7
2.1 Resource Based Admission Control ............................ 7
2.2 Policy Based Admission Control .............................. 8
2.3 Assistance in Traffic Identification/Classification ......... 8
2.3.1 Host Marking .............................................. 9
2.3.2 Router Marking ............................................ 9
2.4 Traffic Conditioning ........................................ 10
3. The Framework ................................................ 10
3.1 Reference Network ........................................... 11
3.1.1 Hosts ..................................................... 11
3.1.2 End-to-End RSVP Signaling ................................. 12
3.1.3 Edge Routers .............................................. 12
3.1.4 Border Routers ............................................ 12
3.1.5 Diffserv Network Region ................................... 13
3.1.6 Non-Diffserv Network Regions .............................. 13
3.2 Service Mapping ............................................. 13
3.2.1 Default Mapping ........................................... 14
3.2.2 Network Driven Mapping .................................... 14
3.2.3 Microflow Separation ...................................... 14
3.3 Resource Management in Diffserv Regions ..................... 15
4. Detailed Examples of the Operation
Intserv over Diffserv Regions ................................ 16
4.1 Statically Provisioned Diffserv Network Region .............. 16
4.1.1 Sequence of Events in Obtaining End-to-end QoS ............ 16
4.2 RSVP-Aware Diffserv Network Region .......................... 18
4.2.1 Aggregated or Tunneled RSVP ............................... 19
4.2.3 Per-flow RSVP ............................................. 20
4.2.4 Granularity of Deployment of RSVP Aware Routers ........... 20
4.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region ..... 21
5. Implications of the Framework for Diffserv Network Regions ... 21
5.1 Requirements from Diffserv Network Regions .................. 21
5.2 Protection of Intserv Traffic from Other Traffic ............ 22
6. Multicast .................................................... 22
6.1 Remarking of packets in branch point routers ................ 24
6.2 Multicast SLSs and Heterogeneous Trees ...................... 25
7. Security Considerations ...................................... 26
7.1 General RSVP Security ....................................... 26
7.2 Host Marking ................................................ 26

Bernet, et al. Informational [Page 2]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

8. Acknowledgments .............................................. 27
9. References ................................................... 27
10. Authors' Addresses .......................................... 29
11. Full Copyright Statement ................................... 31

1.

Work on QoS-enabled IP networks has led to two distinct approaches
the Integrated Services architecture (Intserv) [10] and
accompanying signaling protocol, RSVP [1], and the
Services architecture (Diffserv) [8]. This document describes
in which a Diffserv network can be used in the context of the
architecture to support the delivery of end-to-end QOS

1.1 Integrated Services

The integrated services architecture defined a set of extensions
the traditional best effort model of the Internet with the goal
allowing end-to-end QOS to be provided to applications. One of
key components of the architecture is a set of service definitions
the current set of services consists of the controlled load
guaranteed services. The architecture assumes that some
setup mechanism is used to convey information to routers so that
can provide requested services to flows that require them.
RSVP is the most widely known example of such a setup mechanism,
Intserv architecture is designed to accommodate other mechanisms

Intserv services are implemented by "network elements". While it
common for network elements to be individual nodes such as routers
links, more complex entities, such as ATM "clouds" or 802.3
may also function as network elements. As discussed in more
below, a Diffserv network (or "cloud") may be viewed as a
element within a larger Intserv network

1.2

RSVP is a signaling protocol that applications may use to
resources from the network. The network responds by
admitting or rejecting RSVP requests. Certain applications that
quantifiable resource requirements express these requirements
Intserv parameters as defined in the appropriate Intserv
specification. As noted above, RSVP and Intserv are separable.
is a signaling protocol which may carry Intserv information.
defines the models for expressing service types, quantifying
requirements and for determining the availability of the
resources at relevant network elements (admission control).

Bernet, et al. Informational [Page 3]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

The current prevailing model of RSVP usage is based on a
RSVP/Intserv architecture. In this model, RSVP signals per-
resource requirements to network elements, using Intserv parameters
These network elements apply Intserv admission control to
requests. In addition, traffic control mechanisms on the
element are configured to ensure that each admitted flow receives
service requested in strict isolation from other traffic. To
end, RSVP signaling configures microflow (MF) [8] packet
in Intserv capable routers along the path of the traffic flow.
classifiers enable per-flow classification of packets based on
addresses and port numbers

The following factors have impeded deployment of RSVP (and
Intserv architecture) in the Internet at large

1. The use of per-flow state and per-flow processing
scalability concerns for large networks

2. Only a small number of hosts currently generate RSVP signaling
While this number is expected to grow dramatically,
applications may never generate RSVP signaling

3. The necessary policy control mechanisms -- access control
authentication, and accounting -- have only recently
available [17].

1.3

In contrast to the per-flow orientation of RSVP, Diffserv
classify packets into one of a small number of aggregated flows
"classes", based on the Diffserv codepoint (DSCP) in the packet's
header. This is known as behavior aggregate (BA) classification [8].
At each Diffserv router, packets are subjected to a "per-
behavior" (PHB), which is invoked by the DSCP. The primary
of Diffserv is its scalability. Diffserv eliminates the need
per-flow state and per-flow processing and therefore scales well
large networks

1.4 Roles of Intserv, RSVP and

We view Intserv, RSVP and Diffserv as complementary technologies
the pursuit of end-to-end QoS. Together, these mechanisms
facilitate deployment of applications such as IP-telephony, video
on-demand, and various non-multimedia mission-critical applications
Intserv enables hosts to request per-flow, quantifiable resources
along end-to-end data paths and to obtain feedback
admissibility of these requests. Diffserv enables scalability
large networks

Bernet, et al. Informational [Page 4]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

1.5 Components of Intserv, RSVP and

Before proceeding, it is helpful to identify the following
of the QoS technologies described

RSVP signaling - This term refers to the standard RSVP
protocol. RSVP signaling is used by hosts to signal
resource requirements to the network (and to each other).
elements use RSVP signaling to return an admission control
to hosts. RSVP signaling may or may not carry Intserv parameters

Admission control at a network element may or may not be based on
Intserv model

MF traffic control - This term refers to traffic control which
applied independently to individual traffic flows and
requires recognizing individual traffic flows via MF classification

Aggregate traffic control - This term refers to traffic control
is applied collectively to sets of traffic flows. These sets
traffic flows are recognized based on BA (DSCP) classification.
this document, we use the terms "aggregate traffic control"
"Diffserv" interchangeably

Aggregate RSVP. While the existing definition of RSVP supports
per-flow reservations, extensions to RSVP are being developed
enable RSVP reservations to be made for aggregated traffic, i.e.,
sets of flows that may be recognized by BA classification. This
of RSVP may be useful in controlling the allocation of bandwidth
Diffserv networks

Per-flow RSVP. The conventional usage of RSVP to perform
reservations for individual microflows

RSVP/Intserv - This term is used to refer to the prevailing model
RSVP usage which includes RSVP signaling with Intserv parameters
Intserv admission control and per-flow traffic control at
elements

Diffserv Region. A set of contiguous routers which support
classification and traffic control. While such a region may
support MF classification, the goal of this document is to
how such a region may be used in delivery of end-to-end QOS when
BA classification is performed inside the Diffserv region

Non-Diffserv Region. The portions of the network outside
Diffserv region. Such a region may also offer a variety of
types of classification and traffic control

Bernet, et al. Informational [Page 5]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

Note that, for the purposes of this document, the defining
of a Diffserv region is the type of classification and
control that is used for the delivery of end-to-end QOS for
particular application. Thus, while it may not be possible
identify a certain region as "purely Diffserv" with respect to
traffic flowing through the region, it is possible to define it
this way from the perspective of the treatment of traffic from
single application

1.6 The

In the framework we present, end-to-end, quantitative QoS is
by applying the Intserv model end-to-end across a network
one or more Diffserv regions. The Diffserv regions may, but are
required to, participate in end-to-end RSVP signaling for the
of optimizing resource allocation and supporting admission control

From the perspective of Intserv, Diffserv regions of the network
treated as virtual links connecting Intserv capable routers or
(much as an 802.1p network region is treated as a virtual link
[5]). Within the Diffserv regions of the network routers
specific PHBs (aggregate traffic control). The total amount
traffic that is admitted into the Diffserv region that will receive
certain PHB may be limited by policing at the edge. As a result
expect that the Diffserv regions of the network will be able
support the Intserv style services requested from the periphery.
our framework, we address the support of end-to-end
Services over the Diffserv regions of the network. Our goal is
enable seamless inter-operation. As a result, the
administrator is free to choose which regions of the network act
Diffserv regions. In one extreme the Diffserv region is pushed
the way to the periphery, with hosts alone having full
capability. In the other extreme, Intserv is pushed all the way
the core, with no Diffserv region

1.7

In section 3 we discuss the benefits that can be realized by
the aggregate traffic control provided by Diffserv network regions
the broader context of the Intserv architecture. In section 4,
present the framework and the reference network. Section 5
two possible realizations of the framework. Section 6 discusses
implications of the framework for Diffserv. Section 7 presents
issues specific to multicast flows

Bernet, et al. Informational [Page 6]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

2. Benefits of Using Intserv with

The primary benefit of Diffserv aggregate traffic control is
scalability. In this section, we discuss the benefits
interoperation with Intserv can bring to a Diffserv network region
Note that this discussion is in the context of servicing
QoS applications specifically. By this we mean those
that are able to quantify their traffic and QoS requirements

2.1 Resource Based Admission

In Intserv networks, quantitative QoS applications use an
setup mechanism (e.g., RSVP) to request resources from the network
The network may accept or reject these requests in response. This
"explicit admission control". Explicit and dynamic admission
helps to assure that network resources are optimally used.
further understand this issue, consider a Diffserv network
providing only aggregate traffic control with no signaling. In
Diffserv network region, admission control is applied in a
static way by provisioning policing parameters at network elements
For example, a network element at the ingress to a Diffserv
region could be provisioned to accept only 50 Kbps of traffic for
EF DSCP

While such static forms of admission control do protect the
to some degree, they can be quite ineffective. For example,
that there may be 10 IP telephony sessions originating outside
Diffserv network region, each requiring 10 Kbps of EF service
the Diffserv network region. Since the network element
the Diffserv network region is provisioned to accept only 50 Kbps
traffic for the EF DSCP, it will discard half the offered traffic
This traffic will be discarded from the aggregation of traffic
EF, with no regard to the microflow from which it originated. As
result, it is likely that of the ten IP telephony sessions, none
obtain satisfactory service when in fact, there are
resources available in the Diffserv network region to satisfy
sessions

In the case of explicitly signaled, dynamic admission control,
network will signal rejection in response to requests for
that would exceed the 50 Kbps limit. As a result, upstream
elements (including originating hosts) and applications will have
information they require to take corrective action. The
might respond by refraining from transmitting, or by
admission for a lesser traffic profile. The host operating
might respond by marking the application's traffic for the DSCP
corresponds to best-effort service. Upstream network elements
respond by re-marking packets on the rejected flow to a lower

Bernet, et al. Informational [Page 7]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

level. In some cases, it may be possible to reroute traffic
alternate paths or even alternate networks (e.g., the PSTN for
calls). In any case, the integrity of those flows that were
would be preserved, at the expense of the flows that were
admitted. Thus, by appointing an Intserv-conversant
control agent for the Diffserv region of the network it is
to enhance the service that the network can provide to
QoS applications

2.2 Policy Based Admission

In network regions where RSVP is used, resource requests can
intercepted by RSVP-aware network elements and can be
against policies stored in policy databases. These resource
securely identify the user and the application for which
resources are requested. Consequently, the network element is
to consider per-user and/or per-application policy when
whether or not to admit a resource request. So, in addition
optimizing the use of resources in a Diffserv network region (
discussed in 3.1) RSVP conversant admission control agents can
used to apply specific customer policies in determining the
customer traffic flows entitled to use the Diffserv network region'
resources. Customer policies can be used to allocate resources
specific users and/or applications

By comparison, in Diffserv network regions without RSVP signaling
policies are typically applied based on the Diffserv customer
from which traffic originates, not on the originating user
application within the customer network

2.3 Assistance in Traffic Identification/

Within Diffserv network regions, traffic is allotted service based
the DSCP marked in each packet's IP header. Thus, in order to
a particular level of service within the Diffserv network region,
is necessary to effect the marking of the correct DSCP in
headers. There are two mechanisms for doing so, host marking
router marking. In the case of host marking, the host
system marks the DSCP in transmitted packets. In the case of
marking, routers in the network are configured to identify
traffic (typically based on MF classification) and to mark the
as packets transit the router. There are advantages
disadvantages to each scheme. Regardless of the scheme used
explicit signaling offers significant benefits

Bernet, et al. Informational [Page 8]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

2.3.1 Host

In the case of host marking, the host operating system marks the
in transmitted packets. This approach has the benefit of
per-flow classification and marking to the source of the traffic
where it scales best. It also enables the host to make
regarding the mark that is appropriate for each transmitted
and hence the relative importance attached to each packet. The
is generally better equipped to make this decision than the network
Furthermore, if IPSEC encryption is used, the host may be the
device in the network that is able to make a meaningful
of the appropriate marking for each packet, since various fields
as port numbers would be unavailable to routers for
classification

Host marking requires that the host be aware of the interpretation
DSCPs by the network. This information can be configured into
host. However, such configuration imposes a management burden
Alternatively, hosts can use an explicit signaling protocol such
RSVP to query the network to obtain a suitable DSCP or set of
to apply to packets for which a certain Intserv service has
requested. An example of how this can be achieved is described
[14].

2.3.2 Router

In the case of router marking, MF classification criteria must
configured in the router in some way. This may be done
(e.g., using COPS provisioning), by request from the host
system, or statically via manual configuration or via
scripts

There are significant difficulties in doing so statically. In
cases, it is desirable to allot service to traffic based on
application and/or user originating the traffic. At times it
possible to identify packets associated with a specific
by the IP port numbers in the headers. It may also be possible
identify packets originating from a specific user by the source
address. However, such classification criteria may
frequently. Users may be assigned different IP addresses by DHCP
Applications may use transient ports. To further complicate matters
multiple users may share an IP address. These factors make it
difficult to manage static configuration of the
information required to mark traffic in routers

An attractive alternative to static configuration is to allow
operating systems to signal classification criteria to the router
behalf of users and applications. As we will show later in

Bernet, et al. Informational [Page 9]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

document, RSVP signaling is ideally suited for this task.
addition to enabling dynamic and accurate updating of
classification criteria, RSVP signaling enables classification
IPSEC [13] packets (by use of the SPI) which would otherwise
unrecognizable

2.4 Traffic

Intserv-capable network elements are able to condition traffic at
per-flow granularity, by some combination of shaping and/or policing
Pre-conditioning traffic in this manner before it is submitted to
Diffserv region of the network is beneficial. In particular,
enhances the ability of the Diffserv region of the network to
quantitative services using aggregate traffic control

3. The

In the general framework we envision an Internet in which
Integrated Services architecture is used to deliver end-to-end QOS
applications. The network includes some combination of
capable nodes (in which MF classification and per-flow
control is applied) and Diffserv regions (in which aggregate
control is applied). Individual routers may or may not
in RSVP signaling regardless of where in the network they reside

We will consider two specific realizations of the framework. In
first, resources within the Diffserv regions of the network
statically provisioned and these regions include no RSVP
devices. In the second, resources within the Diffserv region of
network are dynamically provisioned and select devices within
Diffserv network regions participate in RSVP signaling

Bernet, et al. Informational [Page 10]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

3.1 Reference

The two realizations of the framework will be discussed in
context of the following reference network

________ ______________ ________
/ \ / \ / \
/ \ / \ / \
|---| | |---| |---| |---| |---| | |---|
|Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx |
|---| | |-- | |---| |---| |---| | |---|
\ / \ / \ /
\________/ \______________/ \________/

Non-Diffserv region Diffserv region Non-Diffserv

Figure 1: Sample Network

The reference network includes a Diffserv region in the middle of
larger network supporting Intserv end-to-end. The Diffserv
contains a mesh of routers, at least some of which provide
traffic control. The regions outside the Diffserv region (non
Diffserv regions) contain meshes of routers and attached hosts,
least some of which support the Integrated Services architecture

In the interest of simplicity we consider a single QoS sender,
communicating across this network with a single QoS receiver, Rx
The edge routers (ER1, ER2) which are adjacent to the Diffserv
interface to the border routers (BR1, BR2) within the
region

From an economic viewpoint, we may consider that the Diffserv
sells service to the network outside the Diffserv region, which
turn provides service to hosts. Thus, we may think of the non
Diffserv regions as clients or customers of the Diffserv region.
the following, we use the term "customer" for the non-
regions. Note that the boundaries of the regions may or may
align with administrative domain boundaries, and that a single
might contain multiple administrative domains

We now define the major components of the reference network

3.1.1

We assume that both sending and receiving hosts use RSVP
communicate the quantitative QoS requirements of QoS-
applications running on the host. In principle, other mechanisms
be used to establish resource reservations in Intserv-capable nodes

Bernet, et al. Informational [Page 11]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

but RSVP is clearly the prevalent mechanism for this purpose

Typically, a QoS process within the host operating system
RSVP signaling on behalf of applications. This process may
invoke local traffic control

As discussed above, traffic control in the host may mark the DSCP
transmitted packets, and shape transmitted traffic to
requirements of the Intserv service in use. Alternatively, the
Intserv-capable router downstream from the host may provide
traffic control functions

3.1.2 End-to-End RSVP

We assume that RSVP signaling messages travel end-to-end
hosts Tx and Rx to support RSVP/Intserv reservations outside
Diffserv network region. We require that these end-to-end
messages are at least carried across the Diffserv region.
on the specific realization of the framework, these messages may
processed by none, some or all of the routers in the Diffserv region

3.1.3 Edge

ER1 and ER2 are edge routers, residing adjacent to the
network regions. The functionality of the edge routers
depending on the specific realization of the framework. In the
in which the Diffserv network region is RSVP unaware, edge
act as admission control agents to the Diffserv network.
process signaling messages from both Tx and Rx, and apply
control based on resource availability within the Diffserv
region and on customer defined policy. In the case in which
Diffserv network region is RSVP aware, the edge routers
admission control based on local resource availability and
customer defined policy. In this case, the border routers act as
admission control agent to the Diffserv network region

We will later describe the functionality of the edge routers
greater depth for each of the two realizations of the framework

3.1.4 Border

BR1 and BR2 are border routers, residing in the Diffserv
region. The functionality of the border routers varies depending
the specific realization of the framework. In the case in which
Diffserv network region is RSVP-unaware, these routers act as
Diffserv routers. As such, their sole responsibility is to
submitted traffic based on the service level specified in the
and the agreement negotiated with the customer (

Bernet, et al. Informational [Page 12]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

trafficcontrol). In the case in which the Diffserv network region
RSVP-aware, the border routers participate in RSVP signaling and
as admission control agents for the Diffserv network region

We will later describe the functionality of the border routers
greater depth for each of the two realizations of the framework

3.1.5 Diffserv Network

The Diffserv network region supports aggregate traffic control and
assumed not to be capable of MF classification. Depending on
specific realization of the framework, some number of routers
the Diffserv region may be RSVP aware and therefore capable of per
flow signaling and admission control. If devices in the
region are not RSVP aware, they will pass RSVP messages
with negligible performance impact (see [6]).

The Diffserv network region provides two or more levels of
based on the DSCP in packet headers. It may be a
administrative domain or may span multiple domains

3.1.6 Non-Diffserv Network

The network outside of the Diffserv region consists of
capable hosts and other network elements. Other elements may
routers and perhaps various types of network (e.g., 802, ATM, etc.).
These network elements may reasonably be assumed to support Intserv
although this might not be required in the case of over-provisioning
Even if these elements are not Intserv capable, we assume that
will pass RSVP messages unhindered. Routers outside of the
network region are not precluded from providing aggregate
control to some subset of the traffic passing through them

3.2 Service

Intserv service requests specify an Intserv service type and a set
quantitative parameters known as a "flowspec". At each hop in
Intserv network, the Intserv service requests are interpreted in
form meaningful to the specific link layer medium. For example at
802.1 hop, the Intserv parameters are mapped to an appropriate 802.1
priority level [5].

In our framework, Diffserv regions of the network are analogous
the 802.1p capable switched segments described in [5]. Requests
Intserv services must be mapped onto the underlying capabilities
the Diffserv network region. Aspects of the mapping include

Bernet, et al. Informational [Page 13]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

- selecting an appropriate PHB, or set of PHBs, for the
service
- performing appropriate policing (including, perhaps, shaping
remarking) at the edges of the Diffserv region
- exporting Intserv parameters from the Diffserv region (e.g.,
the updating of ADSPECs);
- performing admission control on the Intserv requests that
into account the resource availability in the Diffserv region

Exactly how these functions are performed will be a function of
way bandwidth is managed inside the Diffserv network region, which
a topic we discuss in Section 4.3.

When the PHB (or set of PHBs) has been selected for a
Intserv flow, it may be necessary to communicate the choice of
for the flow to other network elements. Two schemes may be used
achieve this end, as discussed below

3.2.1 Default

In this scheme, there is some standard, well-known mapping
Intserv service type to a DSCP that will invoke the
behavior in the Diffserv network

3.2.2 Network Driven

In this scheme, RSVP conversant routers in the Diffserv
region (perhaps at its edge) may override the well-known
described in 4.2.1. In the case that DSCPs are marked at the
to the Diffserv region, the DSCPs can simply be remarked at
boundary routers. However, in the case that DSCP marking
upstream of the Diffserv region, either in a host or a router,
the appropriate mapping needs to be communicated upstream, to
marking device. This may be accomplished using RSVP, as described
[14].

The decision regarding where to mark DSCP and whether to override
well-known service mapping is a mater of policy to be decided by
administrator of the Diffserv network region in cooperation with
administrator of the network adjacent to the Diffserv region

3.2.3 Microflow

Boundary routers residing at the edge of the Diffserv region
typically police traffic submitted from the outside the
region in order to protect resources within the Diffserv region
This policing will be applied on an aggregate basis, with no
for the individual microflows making up each aggregate. As a result

Bernet, et al. Informational [Page 14]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

it is possible for a misbehaving microflow to claim more than
fair share of resources within the aggregate, thereby degrading
service provided to other microflows. This problem may be
by

1. Providing per microflow policing at the edge routers - this
generally the most appropriate location for microflow policing,
it pushes per-flow work to the edges of the network, where it
better. In addition, since Intserv-capable routers outside
Diffserv region are responsible for providing microflow service
their customers and the Diffserv region is responsible for
aggregate service to its customers, this distribution
functionality mirrors the distribution of responsibility

2. Providing per microflow policing at the border routers -
approach tends to be less scalable than the previous approach.
also imposes a management burden on the Diffserv region of
network. However, it may be appropriate in certain cases, for
Diffserv boundary routers to offer per microflow policing as
value-add to its Intserv customers

3. Relying on upstream shaping and policing - in certain cases,
customer may trust the shaping of certain groups of
sufficiently to not warrant reshaping or policing at the boundary
the Diffserv region. Note that, even if the hosts are
microflows properly, these shaped flows may become distorted as
transit through the non-Diffserv region of the network. Depending
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
another is a matter of policy to be decided by the administrator
the network outside the Diffserv region

3.3 Resource Management in Diffserv

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
Bandwidth Broker).

Some of the details of using each of these different approaches
discussed in the following section

Bernet, et al. Informational [Page 15]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

4. Detailed Examples of the Operation of Intserv over Diffserv

In this section we provide detailed examples of our framework
action. We discuss two examples, one in which the Diffserv
region is RSVP unaware, the other in which the Diffserv
region is RSVP aware

4.1 Statically Provisioned Diffserv Network

In this example, no devices in the Diffserv network region are
aware. The Diffserv network region is statically provisioned.
customer(s) of the Diffserv network regions and the owner of
Diffserv network region have negotiated a static contract (
level specification, or SLS) for the transmit capacity to be
to the customer at each of a number of standard Diffserv
levels. The "transmit capacity" may be simply an amount of
or it could be a more complex "profile" involving a number of
such as burst size, peak rate, time of day etc

It is helpful to consider each edge router in the customer network
consisting of two halves, a standard Intserv half, which
to the customer's network regions and a Diffserv half
interfaces to the Diffserv network region. The Intserv half is
to identify and process traffic on per-flow granularity

The Diffserv half of the router can be considered to consist of
number of virtual transmit interfaces, one for each Diffserv
level negotiated in the SLS. The router contains a table
indicates the transmit capacity provisioned, per the SLS at
Diffserv service level. This table, in conjunction with the
mapping described in 4.2.1, is used to perform admission
decisions on Intserv flows which cross the Diffserv network region

4.1.1 Sequence of Events in Obtaining End-to-end

The following sequence illustrates the process by which
application obtains end-to-end QoS when RSVP is used by the hosts

1. The QoS process on the sending host Tx generates an RSVP
message that describes the traffic offered by the
application

2. The PATH message is carried toward the receiving host, Rx. In
network region to which the sender is attached, standard RSVP/
processing is applied at capable network elements

3. At the edge router ER1, the PATH message is subjected to
RSVP processing and PATH state is installed in the router. The

Bernet, et al. Informational [Page 16]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

message is sent onward to the Diffserv network region

4. The PATH message is ignored by routers in the Diffserv
region and then processed at ER2 according to standard
processing rules

5. When the PATH message reaches the receiving host Rx, the
system generates an RSVP RESV message, indicating interest in
traffic of a certain Intserv service type

6. The RESV message is carried back towards the Diffserv
region and the sending host. Consistent with standard RSVP/
processing, it may be rejected at any RSVP-capable node in the
if resources are deemed insufficient to carry the traffic requested

7. At ER2, the RESV message is subjected to standard RSVP/
processing. It may be rejected if resources on the
interface of ER2 are deemed insufficient to carry the
requested. If it is not rejected, it will be carried
through the Diffserv network region, arriving at ER1.

8. In ER1, the RESV message triggers admission control processing
ER1 compares the resources requested in the RSVP/Intserv request
the resources available in the Diffserv network region at
corresponding Diffserv service level. The corresponding
level is determined by the Intserv to Diffserv mapping
previously. The availability of resources is determined by
capacity provisioned in the SLS. ER1 may also apply a
decision such that the resource request may be rejected based on
customer's specific policy criteria, even though the
resources are determined to be available per the SLS

9. If ER1 approves the request, the RESV message is admitted and
allowed to continue upstream towards the sender. If it rejects
request, the RESV is not forwarded and the appropriate RSVP
messages are sent. If the request is approved, ER1 updates
internal tables to indicate the reduced capacity available at
admitted service level on its transmit interface

10. The RESV message proceeds through the network region to which
sender is attached. Any RSVP node in this region may reject
reservation request due to inadequate resources or policy. If
request is not rejected, the RESV message will arrive at the
host, Tx

11. At Tx, the QoS process receives the RESV message. It
receipt of the message as indication that the specified traffic
has been admitted for the specified Intserv service type (in

Bernet, et al. Informational [Page 17]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

Intserv-capable nodes). It may also learn the appropriate
marking to apply to packets for this flow from information
in the RESV

12. Tx may mark the DSCP in the headers of packets that
transmitted on the admitted traffic flow. The DSCP may be
default value which maps to the Intserv service type specified in
admitted RESV message, or it may be a value explicitly provided
the RESV

In this manner, we obtain end-to-end QoS through a combination
networks that support RSVP/Intserv and networks that
Diffserv

4.2 RSVP-Aware Diffserv Network

In this example, the customer's edge routers are standard
routers. The border router, BR1 is RSVP aware. In addition,
may be other routers within the Diffserv network region which
RSVP aware. Note that although these routers are able to
in some form of RSVP signaling, they classify and schedule traffic
aggregate, based on DSCP, not on the per-flow classification
used by standard RSVP/Intserv routers. It can be said that
control-plane is RSVP while their data-plane is Diffserv.
approach exploits the benefits of RSVP signaling while
much of the scalability associated with Diffserv

In the preceding example, there is no signaling between the
network region and network elements outside it. The negotiation
an SLS is the only explicit exchange of resource
information between the two network regions. ER1 is configured
the information represented by the SLS and as such, is able to act
an admission control agent for the Diffserv network region.
configuration does not readily support dynamically changing SLSs
since ER1 requires reconfiguration each time the SLS changes. It
also difficult to make efficient use of the resources in the
network region. This is because admission control does not
the availability of resources in the Diffserv network region
the specific path that would be impacted

By contrast, when the Diffserv network region is RSVP aware,
admission control agent is part of the Diffserv network. As
result, changes in the capacity available in the Diffserv
region can be indicated to the Intserv-capable nodes outside
Diffserv region via RSVP. By including routers interior to
Diffserv network region in RSVP signaling, it is possible
simultaneously improve the efficiency of resource usage within
Diffserv region and to improve the level of confidence that

Bernet, et al. Informational [Page 18]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

resources requested at admission control are indeed available at
particular point in time. This is because admission control can
linked to the availability of resources along the specific path
would be impacted. We refer to this benefit of RSVP signaling
"topology aware admission control". A further benefit of
RSVP signaling within the Diffserv network region is that it
possible to effect changes in the provisioning of the
network region (e.g., allocating more or less bandwidth to the
queue in a router) in response to resource requests from outside
the Diffserv region

Various mechanisms may be used within the Diffserv network region
support dynamic provisioning and topology aware admission control
These include aggregated RSVP, per-flow RSVP and bandwidth brokers
as described in the following paragraphs

4.2.1 Aggregated or Tunneled

A number of documents [3,6,15,16] propose mechanisms for
RSVP to reserve resources for an aggregation of flows between
of a network. Border routers may interact with core routers
other border routers using aggregated RSVP to reserve
between edges of the Diffserv network region. Initial
levels for each service level may be established between major
routers, based on anticipated traffic patterns. Border routers
trigger changes in reservation levels as a result of the
per-flow RSVP requests from the non-Diffserv regions reaching high
low-water marks

In this approach, admission of per-flow RSVP requests from
outside the Diffserv region would be counted against the
aggregate reservations for the corresponding service level. The
of the aggregate reservations may or may not be dynamically
to deal with the changes in per-flow reservations

The advantage of this approach is that it offers dynamic,
aware admission control to the Diffserv network region
requiring the level of RSVP signaling processing that would
required to support per-flow RSVP

We note that resource management of a Diffserv region
aggregated RSVP is most likely to be feasible only within a
administrative domain, as each domain will probably choose its
mechanism to manage its resources

Bernet, et al. Informational [Page 19]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

4.2.3 Per-flow

In this approach, described in [3], routers in the Diffserv
region respond to the standard per-flow RSVP signaling
from the Intserv-capable nodes outside the Diffserv region.
approach provides the benefits of the previous approach (dynamic
topology aware admission control) without requiring aggregated
support. Resources are also used more efficiently as a result of
per-flow admission control. However, the demands on RSVP
resources within the Diffserv network region may be
higher than in an aggregated RSVP approach

Note that per-flow RSVP and aggregated RSVP are not
exclusive in a single Diffserv region. It is possible to use per-
RSVP at the edges of the Diffserv region and aggregation only in
"core" region within the Diffserv region

4.2.4 Granularity of Deployment of RSVP Aware

In 4.2.2 and 4.2.3 some subset of the routers within the
network is RSVP signaling aware (though traffic control is
as opposed to per-flow). The relative number of routers in the
that participate in RSVP signaling is a provisioning decision
must be made by the network administrator

In one extreme case, only the border routers participate in
signaling. In this case, either the Diffserv network region must
extremely over-provisioned and therefore, inefficiently used, or
it must be carefully and statically provisioned for limited
patterns. The border routers must enforce these patterns

In the other extreme case, each router in the Diffserv network
might participate in RSVP signaling. In this case, resources can
used with optimal efficiency, but signaling processing
and associated overhead increase. As noted above, RSVP
is one way to limit the signaling overhead at the cost of some
of optimality in resource utilization

It is likely that some network administrators will compromise
enabling RSVP signaling on some subset of routers in the
network region. These routers will likely represent major
switching points with over-provisioned or statically
regions of RSVP unaware routers between them

Bernet, et al. Informational [Page 20]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

4.3 Dynamically Provisioned, Non-RSVP-aware Diffserv

Border routers might not use any form of RSVP signaling within
Diffserv network region but might instead use custom protocols
interact with an "oracle". The oracle is an agent that
sufficient knowledge of resource availability and network topology
make admission control decisions. The set of RSVP aware routers
the previous two examples can be considered collectively as a form
distributed oracle. In various definitions of the "bandwidth broker
[4], it is able to act as a centralized oracle

5. Implications of the Framework for Diffserv Network

We have described a framework in which RSVP/Intserv style QoS can
provided across end-to-end paths that include Diffserv
regions. This section discusses some of the implications of
framework for the Diffserv network region

5.1 Requirements from Diffserv Network

A Diffserv network region must meet the following requirements
order for it to support the framework described in this document

1. A Diffserv network region must be able to provide support for
standard Intserv QoS services between its border routers. It must
possible to invoke these services by use of standard PHBs within
Diffserv region and appropriate behavior at the edge of the
region

2. Diffserv network regions must provide admission
information to their "customer" (non-Diffserv) network regions.
information can be provided by a dynamic protocol or through
service level agreements enforced at the edges of the
region

3. Diffserv network regions must be able to pass RSVP messages,
such a manner that they can be recovered at the egress of
Diffserv network region. The Diffserv network region may, but is
required to, process these messages. Mechanisms for
carrying RSVP messages across a transit network are described
[3,6,15,16].

To meet these requirements, additional work is required in the
of

1. Mapping Intserv style service specifications to services that
be provided by Diffserv network regions

Bernet, et al. Informational [Page 21]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

2. Definition of the functionality required in network elements
support RSVP signaling with aggregate traffic control (for
elements residing in the Diffserv network region).
3. Definition of mechanisms to efficiently and dynamically
resources in a Diffserv network region (e.g., aggregated RSVP
tunneling, MPLS, etc.). This might include protocols by which
"oracle" conveys information about resource availability within
Diffserv region to border routers. One example of such a
is the so-called "bandwidth broker" proposed in [19,20,21].

5.2 Protection of Intserv Traffic from Other

Network administrators must be able to share resources in
Diffserv network region between three types of traffic

a. End-to-end Intserv traffic. This is typically traffic
with quantitative QoS applications. It requires a specific
of resources with a high degree of assurance

b. Non-Intserv traffic. The Diffserv region may allocate
to traffic that does not make use of Intserv techniques to
its requirements, e.g., through the use of static provisioning
SLSs enforced at the edges of the region. Such traffic might
associated with applications whose QoS requirements are not
quantifiable but which require a "better than best-effort" level
service

c. All other (best-effort) traffic. These three classes of
must be isolated from each other by the appropriate configuration
policers and classifiers at ingress points to the Diffserv
region, and by appropriate provisioning within the Diffserv
region. To provide protection for Intserv traffic in
regions of the network, we suggest that the DSCPs assigned to
traffic not overlap with the DSCPs assigned to other traffic

6.

The use of integrated services over Diffserv networks
significantly more complex for multicast sessions than for
sessions. With respect to a multicast connection, each
region has a single ingress router and zero, one or several
routers. The difficulties of multicast are associated with
regions that contain several egress routers. (Support of
functionality outside the Diffserv region is
straightforward since every Intserv-capable router along
multicast tree stores state for each flow.)

Consider the following reference network

Bernet, et al. Informational [Page 22]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

Non-Diffserv region 2
________
/ \
| | |---|
________ _____________ | |-|Rx1|
/ \ / |--\ |---| | |---|
/ \ / /|BR2\-----\ER2| /
|---| | |---| |---| |--|/ |---| \--|____/
|Tx |-| |ER1|---|BR1|--|RR| | ________
|---| | |-- | |---| |--|\ |---| /--| \
\ / \ \|BR3/-----|ER3| | |---|
\________/ \__________|--/ |---| |-|Rx2|
| | |---|
Non-Diffserv region 1 Diffserv region \ /
\______/

Non-Diffserv region 3

Figure 2: Sample Multicast Network

The reference network is similar to that of Figure 1. However,
Figure 2, copies of the packets sent by Tx are delivered to
receivers outside of the Diffserv region, namely to Rx1 and Rx2.
Moreover, packets are copied within the Diffserv region in a "
point" router RR. In the reference network BR1 is the ingress
to the Diffserv region whereas BR2 and BR3 are the egress routers

In the simplest case the receivers, Rx1 and Rx2 in the
network, require identical reservations. The Diffserv framework [18]
supports service level specifications (SLS) from an ingress router
one, some or all of the egress routers. This calls for a "one
many" SLS within the Diffserv region, from BR1 to BR2 and BR3.
that the SLS is granted by the Diffserv region, the ingress
BR1, or perhaps an upstream node such as ER1, marks packets
the Diffserv region with the appropriate DSCP. The packets
routed to the egresses of the Diffserv domain using the
multicast address

The two major problems, explained in the following, are
with heterogeneous multicast trees containing branch points
the Diffserv region, i.e., multicast trees where the level
resource requirement is not uniform among all receivers. An
of such a scenario in the network of Figure 2 is the case where
Rx1 and Rx2 need to receive multicast data from Tx1 but only one
the receivers has requested a level of service above best effort.
consider such scenarios in the following paragraphs

Bernet, et al. Informational [Page 23]

RFC 2998 Integrated Services Over Diffserv Networks November 2000

6.1 Remarking of packets in branch point

In the above scenario, the packets that arrive at BR1 are marked
an approp