Internet Draft Y. Bernet, Microsoft
Expiration: August 1999 R. Yavatkar, Microsoft
File: draft-ietf-diffserv-rsvp-02.ps P. Ford, Microsoft
F. Baker, Cisco
L. Zhang, UCLA
K. Nichols, Cisco
M. Speer, Sun Microsystems
R. Braden, ISI
Interoperation of RSVP/Int-Serv and Diff-Serv Networks
February 26, 1999
Status of Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
linebreak http://www.ietf.org/shadow.html.
Abstract
Differentiated Services (diff-serv) and RSVP/Integrated Services
(RSVP/int-serv) provide complementary approaches to the problem of
providing QoS for Internet end systems. These approachs must be able
to coexist and effectively interoperate. This document outlines one
important model for such interoperation, in which diff-serv is used
by transit networks in the core of the Internet while hosts and edge
networks use RSVP/int-serv. It also contains a brief discussion of
some alternative models for interoperation.
Bernet, Ed. et. al Expiration: August 1999 [Page 1]
Internet Draft Use Of RSVP with Diffserv February 1999
1. Introduction
Work on QoS-enabled IP networks has led to two distinct approaches:
the Integrated Services (int-serv) architecture [12] and its
signaling protocol RSVP [1], and the Differentiated Services (diff-
serv) architecture [10].
RSVP enables applications to signal per-flow QoS requirements to the
network, with explicit admission control. Int-serv uses RSVP
signaling to request tight QoS with quantitative parameters. Int-
serv also imposes fine-grain policing and scheduling of traffic, to
ensure that admitted flows receive their service requests in strict
isolation from each other and from best-effort traffic. RSVP
signaling configures packet classifiers in the int-serv capable
routers along the path of the flow. These classifiers perform a
fine-grain or `MF' [10] classification of packets, using on IP
addresses and port numbers for example.
Some basic limitations to the RSVP/int-serv model have impeded its
deployment in the Internet at large.
o The use of per-flow state and per-flow processing raises
scalability concerns for large networks.
o Only a small number of hosts currently generate RSVP signaling.
While this number is expected to grow dramatically, some
applications may never generate RSVP signaling.
o Some applications require a form of QoS that cannot be expressed
using the int-serv model.
o The necessary policy control mechanisms -- access control,
authentication, and accounting -- are not available.
The market is pushing for immediate deployment of a QoS solution that
addresses the needs of the Internet as well as enterprise networks.
This push led to the development of Differentiated Services. In
contrast to the per-flow orientation of int-serv and RSVP, diff-serv
networks classify packets into one of a small number of aggregated
flows or "classes", based on bits set in the TOS field of each
packet's IP header. This is known as `BA' classification [10]. In
addition to eliminating the requirement for per-flow state, diff-serv
QoS can initially be deployed using long-term provisioning rather
than short-term reservations established by end-to-end signaling.
We view int-serv and diff-serv as complementary tools in the pursuit
of end-to-end QoS. For many applications, the loose or "qualitative"
QoS provided by diff-serv will be adequate. However, some
Bernet, Ed. et. al Expiration: August 1999 [Page 2]
Internet Draft Use Of RSVP with Diffserv February 1999
applications will require the tight quantitative end-to-end QoS
assurance provided by int-serv and RSVP. Current examples of
applications that need tight QoS include IP-telephony, video-on-
demand, and various non-multimedia mission-critical applications, and
such applications may proliferate in the future. The diff-serv
mechanisms that are deployed must be able to interoperate effectively
with hosts and networks that provide per-flow QoS using int-serv
models.
There are several different models for coexistence and interoperation
between RSVP/int-serv and diff-serv. This draft is primarily
concerned with one important model, although Section 5 presents a
brief look at other models. Under our model, diff-serv mechanisms
are used within transit networks in the `core' of the network, while
RSVP/int-serv mechanisms are used within stub networks at the 'edge'.
From the int-serv viewpoint, the diff-serv transit network is treated
as a virtual link connecting int-serv/RSVP capable routers. This
model builds upon work in progress on RSVP aggregation [8, 15].
This model will provide a framework that will allow deployment of
diff-serv networks and deployment of RSVP/int-serv networks to
proceed at their own pace, providing immediate incremental benefits
in areas of the network in which one or the other is deployed and
additional benefits where both are deployed. Ultimately, we want
RSVP/int-serv and diff-serv mechanisms to interact seamlessly.
Network administrators should be able to determine for their own
networks the degree to which diff-serv capabilities are pushed
towards the edge of their networks, or the degree to which RSVP/int-
serv capabilities are pushed towards the core of the Internet.
Section 2 provides an overview of our model for interoperation
between int-serv and diff-serv, and discusses some of the
assumptions. Section 3 presents the model in more detail, while
Section 4 discusses its implications for diff-serv. Finally, Section
5 briefly lists some other possible models for interoperation.
Appendix A contains a list of some important terms used in this
document.
Even though one of the goals of this draft is to describe a framework
for co-existence of RSVP/int-serv with diff-serv, the draft currently
does not address the issues specific to IP multicast flows. See
Section 5.
2. Overview of the Model
This section examines the issues in providing tight quantitative
end-to-end QoS over end-to-end paths that includes both int-serv
networks and diff-serv networks, and introduces our model.
Bernet, Ed. et. al Expiration: August 1999 [Page 3]
Internet Draft Use Of RSVP with Diffserv February 1999
2.1 Quantitative End-to-End QoS
The primary focus of this document on end-to-end quantitative QoS.
Although quantitative QoS applications may generate only a small
fraction of all traffic, servicing this traffic may comprise a
significant fraction of the revenues associated with QoS. In
addition, while qualitative QoS applications can be satisfied by
conventional diff-serv alone, quantitative QoS applications
require additional support.
Diff-serv is expected to define some well-defined edge-to-edge
services, which will be formed by concatenation of the `per-hop-
behaviors' (PHBs [10]) that are being defined for internal diff-
serv routers, possibly with some defined shaping and/or policing
at the ingress. Our model assumes that it will be possible to map
the quantitative QoS services defined by int-serv into these
diff-serv services within the diff-serv network, in order to
satisfy the end-to-end requirement of a quantitative QoS
application.
2.2 Packet Marking
Within the diff-serv regions of the network, traffic is allotted
service based on the contents of the DS-field in the IP headers.
Setting the DS-field is referred to as `marking' the packet. QoS
applications must be able to effect the correct marking of DS-
fields before their packets enter a diff-serv network. There are
two choices for accomplishing this.
Host Marking
Hosts may directly mark DS-fields in the packets transmitted
by QoS applications. Such marking may be based on host
configuration or on local communication between QoS
applications and the host operating system.
Int-serv Router Marking
Routers external to the diff-serv network may mark DS-fields
on behalf of QoS applications, based on MF classification.
The MF classifier might be dynamically configured by RSVP
signaling between QoS applications, or it might be controlled
statically by manual configuration or automated configuration
scripts.
MF classification is expected to be limited to examination of the
network and transport-layer (port) fields of a packet. An
advantage of host marking is that it allows marking to depend upon
application-specific information that cannot be deduced from MF
classification. For example, consider the need to give
Bernet, Ed. et. al Expiration: August 1999 [Page 4]
Internet Draft Use Of RSVP with Diffserv February 1999
preferential service to a website's home page (over other, less
important pages at the site) or the case of encrypted traffic
flows (IPSEC).
The information required to express useful mappings of application
traffic flows to service levels is likely to be quite complex and
to change frequently. Thus, manual configuration is likely to
impose a significant management burden. If the configuration
information is very simple and does not change over time, the
management burden may be relatively minor; however, this means
that the granularity of allotting service levels to flows will be
sub-optimal. These considerations argue for host-based marking or
for dynamic configuration of a router's classifier/marker in
response to application requests.
2.3 Granularity of Allotment
The term `granularity' is used here to refer to the degree of
specificity that is available in allotting a specific service
level to a specific traffic flow. There are two measures of
allotment granularity: granularity of packet classification and
temporal granularity.
Fine grain classification might implement the following
requirement: "Telephony traffic from user X is allotted service
level A, while telephony traffic from user Y is allotted service
level B, and web traffic from any user is allotted service level
C." Coarse grain classification might be limited to something of
the form: "All traffic from subnet 1.0.0.0 receives service level
A, while all traffic from subnet 2.0.0.0 receives service level
B."
Temporal granularity determines the frequency with which the
service allotted to a flow may change. A temporally fine grain
system would allow immediate changes in allotment of service
levels to traffic flows, with times of the order of seconds or
less. A temporally coarse-grained system might have service
levels set by static provisioning with time frames of days or
weeks.
2.4 Policing
It may be necessary to protect the network by policing at various
points, within the stub network and/or at the interface to the
transit network. For example, within the stub network, first-hop
routers may police the aggregate traffic coming from a host to
ensure that the host is not exceeding its traffic limit.
Bernet, Ed. et. al Expiration: August 1999 [Page 5]
Internet Draft Use Of RSVP with Diffserv February 1999
It should be noted that some diff-serv PHBs (e.g., a "billing" PHB
[14]) may not require any policing at all at any point in the
network.
2.5 Admission Control
Under RSVP/int-serv, quantitative QoS applications use RSVP to
submit QoS requests to explicit admission control at each hop of
the end-to-end path. Integrated Services admission control (ISAC)
may be avoided only on hops that are known to be sufficiently
over-provisioned to satisfy the service requirements. When a
request is rejected, the host application may choose to try again
with a smaller request or to accept the best-effort service
available everywhere along the path, or it may simply avoid
sending traffic. These mechanisms protect traffic on flows that
were previously admitted.
In diff-serv regions of the network, admission control may be
provided implicitly by policing at ingress points, based on
provisioning. However, to support end-to-end tight QoS, explicit
admission control must be applied to the virtual hop represented
by the diff-serv transit network. An diff-serv service level used
by the int-serv traffic is provisioned for some maximum level of
traffic. The admission control function must ensure that this
limit is not exceeded by the total int-serv traffic submitted for
this class.
2.6 Policy Control
QoS support provides preferential treatment to particular traffic
flows. As a result, admission control must be based on policy as
well as on resource availability.
In an int-serv network, resource-based admission control is
handled by RSVP enabled routers (and SBMs [2]), and is typically
at the granularity of individual users. Policy based admission
control is handled by RSVP-capable policy servers. These assure
that int-serv network resources are allotted to users according to
policy specific to the int-serv network. In addition, policy
servers within the int-serv network must assure that appropriate
policy is applied when diff-serv resources are allotted to int-
serv users.
In a diff-serv network, resource and policy-based admission
control are handled by entities such as bandwidth brokers. Policy
decisions made within the diff-serv network are likely to be at
the granularity of peer networks. In general, the diff-serv
network may make multiple service levels available to a single
Bernet, Ed. et. al Expiration: August 1999 [Page 6]
Internet Draft Use Of RSVP with Diffserv February 1999
peer int-serv network.
3. Description of Model
We envision an internet that consists of RSVP/int-serv capable stub
networks interconnected by diff-serv capable transit networks. The
simplest example of this model is a diff-serv capable transit network
and two RSVP/int-serv capable stub networks, as shown in Figure 1.
The transit network contains a mesh of routers, at least some of
which are diff-serv capable. The stub networks contain meshes of
routers, at least some of which are int-serv capable.
/ Stub / Transit / Stub / Network / Network / Network | | | | | |
|---| | |---| |---| |---| |---| | |---|
|Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx |
|---| | |-- | |---| |---| |---| | |---|
| | | | | |
RSVP/ / diff-serv / RSVP/ /
int-serv/ / int-serv/
Figure 1: Sample Network Configuration
In the interest of simplicity, Figure 1 shows a single QoS sender Tx
on one of the stub networks and a single QoS receiver Rx on the
other. The edge routers (ER1, ER2) within the RSVP/int-serv networks
interface to the border routers (BR1, BR1) of the diff-serv network.
From an economic viewpoint, we may consider that the transit network
sells service to the stub networks, which in turn sell service to end
systems. Thus, we may think of the stub networks as customers of the
transit network. In the following, we use the term "customer" for
each of the stub networks in Figure 1.
3.1 Components of the Model
We now define the major components of the proposed model.
3.1.1 Hosts
Both sending and receiving hosts use RSVP to communicate the
quantitative QoS requirements of QoS-aware applications running
on the host. Typically, a QoS process within the host
operating system generates RSVP signaling on behalf of the
applications; this process may also invoke local traffic
control.
Bernet, Ed. et. al Expiration: August 1999 [Page 7]
Internet Draft Use Of RSVP with Diffserv February 1999
Traffic control in the host may mark the DS-field in
transmitted packets, and it may shape transmitted traffic to
the requirements of the int-serv service in use.
Alternatively, the first-hop router within the int-serv network
may provide these traffic control functions.
3.1.2 End-to-End RSVP Signaling
We assume that RSVP signaling messages travel end-to-end
between hosts Tx and Rx to support int-serv reservations in the
stub networks. We require that these end-to-end RSVP messages
be tunneled transparently across the diff-serv transit network.
Mechanisms for this purpose are proposed in [8]; they do not
require the routers in the transit network to
understand/interpret RSVP messages and do not adversely impact
the transit network.
3.1.3 Edge Routers
We choose to place the boundary between the RSVP/int-serv
region and the diff-serv region of the network within the edge
routers. It is helpful to think of an edge router as
consisting of two halves: a standard RSVP half, which
interfaces to a stub network, and a diff-serv half, which
interfaces to the transit network. The RSVP half has full RSVP
capability. It is able to do MF classification, if required,
and it is able to police traffic that will be passed to the
border router.
The diff-serv half of the edge router provides an interface to
the diff-serv network's admission control function, which we
refer to as as `DSAC' (Diff-Serv Admission Control).
The customer(s) (owner(s) of the stub networks) and the carrier
owning the transit network will negotiate a contract for the
capacity to be provided at each of a number of standard diff-
serv service levels. If the service agreement between the stub
networks and the transit networks is statically provisioned,
then the DSAC can be simply based upon a table that specifies
capacity at each service level. If the service agreement is
dynamic, the DSAC may communicate with counterparts within the
diff-serv network (such as a bandwidth broker [4]) in order to
make admission control decisions based on provisioned limits as
well as the topology and the capacity of the diff-serv network.
Since the individual int-serv flows are policed according to
int-serv rules within the stub network, the edge router needs
to shape only the aggregate stream, not the individual flows.
Bernet, Ed. et. al Expiration: August 1999 [Page 8]
Internet Draft Use Of RSVP with Diffserv February 1999
3.1.4 Border Routers
BR1 and BR2 are diff-serv capable border routers, and are not
required to run RSVP. They are expected to implement the
policing function of diff-serv ingress routers, based on the
results of a BA classifier. They are required neither to
provide MF classification nor to mark the DS-field (with the
possible exception of differential marking to indicate out-of-
profile traffic [10, 8]).
3.1.5 Stub Networks
A stub network consists of int-serv capable hosts and some
number of routers. These routers may reasonably be assumed to
be RSVP/int-serv capable, although this might not be required
for a small over-provisioned stub network. If they are not
int-serv capable, we assume that they are not capable of per-
flow classification, signaling, or admission control and will
pass RSVP messages unhindered.
3.1.6 Transit Network
The transit network is not typically capable of per-flow
classification, signaling, and admission control. It provides
two or more levels of service based on the DS-field in the
headers of carried packets (diff-serv capable). Furthermore,
the transit network is able to carry RSVP messages
transparently, with minimal or no impact on its performance
(see [8]). The transit network may include multiple carrier
networks.
3.1.7 Service Mapping
RSVP signaling requests carry an int-serv service type and a
set of quantitative parameters known as a "flowspec"; these
describe the QoS expected from the int-serv regions of the
network. At each hop in an int-serv network, the generic int-
serv service requests are interpreted in a form meaningful to
the specific link layer medium. For example, at an ATM hop, a
VC of the correct type (CBR, ABR or VBR) is established [13].
At an 802.1 hop, the int-serv service type is mapped to an
appropriate 802.1p priority level [5].
In our model, the entire diff-serv network plays the role of a
single virtual link layer as far as RSVP/int-serv are
concerned. Therefore, the int-serv service request must be
mapped to the DS-field when the packets enter the diff-serv
cloud. The requested int-serv service must be mapped to a
Bernet, Ed. et. al Expiration: August 1999 [Page 9]
Internet Draft Use Of RSVP with Diffserv February 1999
diff-serv service level that can reasonably extend the int-serv
service type requested by the application. The edge router can
then provide admission control to the diff-serv network by
accepting or rejecting the request based on the capacity
available at the requested diff-serv service level.
One of two schemes may be used to map int-serv service types to
diff-serv service levels.
Default
In this scheme, there is some standard, well-known mapping
from int-serv service type to a PHB that will invoke the
appropriate behavior in the diffserv network.
To improve the quality of the mapping, it may prove
necessary to add additional information to an int-serv QoS
request. For example, consider QoS requests for two
different flows, one interactive voice traffic and the
other latency-tolerant traffic. They may both have the
same int-serv parameters (especially using the Controlled
Load service), but they are likely to map to different
diff-serv services. For this reason, we suggest adding a
qualifier to the int-serv service type indicating its
relative latency tolerance (high or low). The qualifier
would be defined as a standard object in int-serv
signaling messages.
Customer-Specified
In this scheme, the edge routers in the customer (stub)
networks are allowed to modify the service mapping. RESV
messages originating at hosts will carry the usual int-
serv service type (perhaps with a qualifier, as described
above). When a RESV message arrives at the edge router
from which the traffic enters the diff-serv region (e.g.,
router ER1 in Figure 1), the edge router determines the
PHB code point that should be used to obtain the
corresponding diff-serv service level. This information
is appended to the RESV message by ER1 and carried to the
sending host. When the RESV message arrives at the
sending host, the sender (or intermediate int-serv
routers) start marking outgoing packets with the indicated
PHB code point.
A decision to override the well-known service mapping at the
edge router may be based on configuration and/or a policy
decision. For example, when a reservation request arrives at
Bernet, Ed. et. al Expiration: August 1999 [Page 10]
Internet Draft Use Of RSVP with Diffserv February 1999
the ingress to a diff-serv network, if accepted reservations
have already reached the pre-negotiated capacity limit at the
corresponding service level then the edge router may decide to
use a PHB corresponding to a different service level, based on
an administratively-set policy.
3.2 Example: Obtaining End-to-End QoS
The following sequence illustrates the process by which an
application obtains end-to-end QoS.
1. The QoS process on the sending host Tx generates an RSVP PATH
message that describes the traffic offered by the sending
application.
2. The PATH message is carried toward the receiving host Rx. In
the sender's stub network, standard RSVP processing is
applied at RSVP capable nodes (routers, SBMs, etc).
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 message is sent onward, to the transit
network.
4. The PATH message is carried transparently through the transit
network, and then processed in stub router ER2 according to
standard RSVP processing rules.
5. When the PATH message reaches the receiving host Rx, its QoS
process generates an RSVP RESV message, indicating interest
in the offered traffic at a certain int-serv service level.
6. The RESV message is carried back towards the sending host.
Consistent with standard RSVP processing, it may be rejected
at any RSVP node in the receiver's stub network 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
downstream interface of ER2 are deemed insufficient to carry
the resources requested. If it is not rejected, it will be
carried transparently through the transit network, arriving
at ER1.
8. In ER1, the RESV message triggers DSAC processing. The DSAC
compares the resources requested to the resources available
at the corresponding diff-serv service level, in the diff-
serv enabled transit network. If the RESV message is
Bernet, Ed. et. al Expiration: August 1999 [Page 11]
Internet Draft Use Of RSVP with Diffserv February 1999
admitted, the DSAC updates the available capacity for the
service class, by subtracting the approved resources from the
available capacity.
9. Assuming the available capacity is sufficient, the RESV
message is admitted and is allowed to continue upstream
towards the sending host. If the available capacity is
insufficient, the RESV message is rejected and the available
capacity for the service class remains unchanged.
10. The RESV message proceeds through the sender's stub network.
RSVP nodes in the sending stub network may reject it. If it
is not rejected, it will arrive at the sender host Tx.
11. At Tx, the QoS process receives the RESV message. It
interprets receipt of the message as an indication that the
specified traffic has been admitted for the specified int-
serv service type (in the RSVP enabled regions of the
network) and for the corresponding diff-serv service level
(in the diff-serv enabled regions of the network).
Tx begins to set the DS-field in the headers of transmitted
packets to the value which maps to the Intserv service type
specified in the admitted RESV message.
In this manner, we obtain end-to-end QoS through a combination of
networks that support RSVP style reservations and networks that
support diff-serv style prioritization. The successful arrival of
RESV messages at the original sender indicates that admission
control has succeeded both in the RSVP regions of the network and
in the diff-serv regions of the network.
3.3 Variations of the Model
It is useful to consider some variations of the model just
presented.
3.3.1 Moving the Boundary
We have assumed that the boundary between the RSVP/int-serv
network and the diff-serv network lies in the edge routers.
Alternative models could shift this boundary to the left or to
the right in Figure 1. It could for example, be placed within
the border routers in the transit network. In this case, the
DSAC would be implemented entirely within the diff-serv network
(and would essentially be the bandwidth broker proposed in
[4]); however, it would require that the diff-serv border
routers be RSVP capable.
Bernet, Ed. et. al Expiration: August 1999 [Page 12]
Internet Draft Use Of RSVP with Diffserv February 1999
Alternative, the boundary could be shifted all the way to the
end hosts. This would mean that the traffic was using diff-
serv mechanisms in the stub networks as well as the transit
network, while the int-serv mechanisms would be only in the
host. The QoS-aware application could still use RSVP within
the lost to signal its needs. The host would implement per-
flow policing, the DSAC function, and packet marking.
3.3.2 Service Agreements
o Statically-Provisioned Service Agreements
In the simplest model, service agreements are negotiated
statically between stub networks and transit networks. A
service agreement consists of a table of capacities
available to a stub network, at each diff-serv service
level. In this case, DSAC functionality is provided at
the edge routers in the stub networks. The `diff-serv
half' of these routers appear to the `RSVP half' as a
sending interface with resource limits defined by the
service agreement table. While there may be bandwidth
brokers and dynamic provisioning within the transit
networks, these are not coupled with the int-serv stub
networks, and admission control in the two regions of the
network is completely independent.
o Dynamic Service Agreements
In a more sophisticated model, service agreements between
customer stub networks and carrier transit networks are
more dynamic. Customers may be able to dynamically
request changes to the service agreement. In this case, a
statically provisioned edge router cannot provide the
required DSAC functionality. Instead, DSAC functionality
must be provided by coupling the stub network's admission
control with the transit network's admission control.
The two admission control mechanisms meet at the boundary
between the diff-serv network and the int-serv network.
This boundary may be implemented at the edge router (in
the stub network), at the border router (in the transit
network), or at the bandwidth broker for the int-serv
network.
Note that coupling int-serv and diff-serv admission
control does not imply that each int-serv admission
control request will result in DSAC processing. Int-serv
admission control requests may be aggregated at the
Bernet, Ed. et. al Expiration: August 1999 [Page 13]
Internet Draft Use Of RSVP with Diffserv February 1999
boundary between the int-serv and the diff-serv network.
For example, int-serv admission control requests may
trigger DSAC requests to bandwidth brokers only when some
high-water or low-water resource threshold is crossed.
Separate high-water and low-water thresholds can provide
hysteresis to prevent thrashing.
%.cm In the latter case, any MF classification on %.cm behalf
of the diff-serv ingress point is provided as a service to the
%.cm customer and goes beyond policing requirements).
3.3.3 Setting the DS-field
Allowing hosts to set the DS-field directly may alarm network
administrators. The obvious concern is that hosts may attempt
to 'steal' resources. In fact, hosts may attempt to exceed the
negotiated capacity at a particular service level regardless of
whether they invoke this service level directly (by setting the
DS-byte) or indirectly (by submitting traffic that classifies
in an intermediate router to a particular diff-serv PHB).
In summary, the security concerns of marking the DS-field at
the edge of the network can be dismissed since each carrier
will have to do some form of policing (per-flow or per-host) at
their boundary anyway. Furthermore, this approach reduces the
granularity at which border routers must police, thereby
pushing finer grain shaping and policing responsibility to the
edges of the network, where it scales better. The carriers are
thus focused on the task of protecting their transit networks,
while the customers are focused on the task of shaping and
policing their own traffic to be in compliance with their
negotiated token bucket parameters.
It is also possible to mark the DS-field at intermediate
routers rather than at the host and still realize many of the
benefits of our approach. In this case, intermediate routers
may use the RSVP signaling to configure an MF classifier and
marker. Then the configuration of MF classifiers and markers
would be dynamic (minimizing the management burden), and full
resource- and policy-based admission control could be applied.
The disadvantages of marking the DS-field at intermediate
routers (instead of the host) are that full MF classifiers are
required at the intermediate nodes and that responsibility for
Bernet, Ed. et. al Expiration: August 1999 [Page 14]
Internet Draft Use Of RSVP with Diffserv February 1999
traffic separation is shifted away from the host.
Nonetheless, marking at intermediate routers will be necessary
to support those hosts which support RSVP signaling but are
incapable of marking the DS-field. In addition, there may be
cases in which the network administrators wish to shift the
responsibility for traffic separation away from the hosts. In
particular, we expect that there will continue to be a need for
top-down provisioned MF classification, especially for
qualitative (as opposed to quantitative) QoS applications. See
Section 5.2.
4. Implications for Diff-Serv
We have described a framework for end-to-end QoS in which a diff-serv
network can be included as a segment of an int-serv path. This
section discusses some of the implications of this framework for
diff-serv.
4.1 Requirements for Diff-Serv
In order to use a diff-serv network as described in this draft,
the diff-serv network must satisfy the following requirements.
1. A diff-serv network must be able to provide standard QoS
services between its border routers, and such a service must
be selectable by specifying a standard code in a (PHB) sub-
field of the DS-field of a packet.
2. There must be appropriate service mappings from int-serv
services into these diff-serv services.
3. Diff-serv networks must provide admission control information
to the int-serv network. This information can be provided by
a dynamic protocol or, at the very least, through static
service level agreements.
4. Diff-serv networks must be able to transparently carry RSVP
messages, in such a manner that they can be recovered at the
egress point from the diff-serv network.
4.2 End-to-End Integrity of the DS-field
Our model assumes that int-serv networks uses a code point of the
DS-field in order to specify the desired PHB within the transit
network. It also assumes that packets submitted to the transit
network specifying a certain DS-field will receive a standard
service throughout the transit network. Strictly speaking, this
Bernet, Ed. et. al Expiration: August 1999 [Page 15]
Internet Draft Use Of RSVP with Diffserv February 1999
does not dictate that the transit network must leave the DS-field
field intact. For example, the border router may map a DS-field
value set by the host or edge router to a different value before
forwarding the data packets.
However, we see little value in allowing the PHB field to be
altered within the network. This is likely to perpetuate local
and incompatible interpretations of the field.
4.3 Policing and Shaping
We are assuming that border routers will police in aggregate. As
a result, the customer cannot rely on border routers to provide
traffic isolation between the customer's flows, when policing or
shaping. Instead, it is the customer's responsibility to ensure
that the customer's flows are properly shaped and policed within
the customer's sending network. Overall, this approach simplifies
border routers and still allows protection against misbehaving
hosts/users.
Ideally, hosts should provide per-flow shaping at their sending
interfaces. However, there is always a chance that the customer's
traffic will become distorted as it nears the boundary between the
customer and the carrier. In this case, the customer should do
per flow policing (or even re-shaping) at the egress point from
the customer's network unless the policing agreement at the other
side is known to accommodate the transient bursts that can arise
from adding the flows.
4.4 Managing Resource Pools
Network administrators must be able to share diff-serv network
resources between three types of traffic:
a. Quantitative (explicitly signaled) QoS application traffic
b. Qualitative (implicitly signaled) QoS application traffic
c. All other (best-effort) traffic
These pools must be isolated from each other by the appropriate
configuration of policers and classifiers at ingress points to the
diff-serv network, and by appropriate provisioning within the
diff-serv network. To provide protection for quantitative QoS
traffic in diff-serv regions of the network, we suggest that the
DS codepoints allotted to such traffic must not overlap the
codepoints assigned to other traffic (qualitative QoS and best-
Bernet, Ed. et. al Expiration: August 1999 [Page 16]
Internet Draft Use Of RSVP with Diffserv February 1999
effort traffic).
5. Other Models
5.1 RSVP and Diff-Serv
Since RSVP was originally designed to support int-serv, we use the
term "RVSP/int-serv" as the complement to diff-serv. However,
RSVP and int-serv are separable, and RSVP may be used as a
general-purpose QoS signaling protocol. For example, RSVP might
be used for dynamic provisioning and admission control in the
diff-serv region of the network. Routers in the diff-serv region
would continue use the DS-field in the IP header to identify and
offer services to flow aggregates.
5.2 Qualitative QoS
This document has focused largely on the class of applications
that use RSVP to explicitly signal per-flow QoS requirements and
that expect end-to-end tight QoS assurances. We have been
referring to these applications as `quantitative QoS
applications'. Suitable end-to-end services must also be
available to qualitative QoS applications. The services that
these applications require are generally less demanding.
Qualitative services can be obtained from the diff-serv regions of
the network with loose top-down provisioning. Network managers
can configure classifiers at the ingress to the diff-serv network
to recognize traffic requiring specific qualitative service
levels. Thus, these classification fields are used as a form of
implicit signaling. In the int-serv portion of the network,
qualitative QoS applications can get best-effort service, which
may be good enough.
There would be no explicit admission control for such qualitative
QoS applications. Therefore, it is difficult to assure that the
total traffic offered at an ingress point will not exceed the
provisioned capacity for a particular service level. When the
traffic exceeds the allowed limit, there is only indirect feedback
to the applications, in the form of packet loss or an Congestion
Experienced mark from Explicit Congestion Notification (ECN).
Thus, traffic from qualitative applications can be offered only
loose QoS.
5.3 Multicasting
<To be written>
Bernet, Ed. et. al Expiration: August 1999 [Page 17]
Internet Draft Use Of RSVP with Diffserv February 1999
6. Security Considerations
We are proposing that RSVP signaling be used to obtain resources in
both the diff-serv and int-serv regions of the network. Therefore,
all RSVP security considerations apply [11]. In addition, network
administrators are expected to protect network resources by
configuring secure policers at interfaces with untrusted customers.
7. Acknowledgments
Authors thank the following individuals for their comments that led
to improvements to the previous version(s) of this draft: David Oran,
Andy Veitch, Curtis Villamizer, Walter Weiss, and Russel white.
Many of the ideas in this document have been previously discussed in
the original int-serv architecture document [12].
8. References
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S.,
"Resource Reservation Protocol (RSVP) Version 1 Functional
Specification", RFC 2205, Proposed Standard, September 1997
[2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M.,
"SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based Admission
Control Over IEEE 802 Style Networks", Internet Draft, March 1998
[3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated
Services State", Internet Draft, December 1997.
[4] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit
Differentiated Services Architecture for the Internet", Internet
Draft, December 1997.
[5] Seaman, M., Smith, A. and Crawley, E., "Integrated Services Over
IEEE 802.1D/802.1p Networks", Internet Draft, June 1997
[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
Precedence, Delay Indication, and Drop Preference", Internet Draft,
November 1997
[8] Guerin, R., Blake, S. and Herzog, S.,"Aggregating RSVP based QoS
Requests", Internet Draft, November 1997.
Bernet, Ed. et. al Expiration: August 1999 [Page 18]
Internet Draft Use Of RSVP with Diffserv February 1999
[9] Nichols, Kathleen, et al., "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[10] Blake, S., et al., "An Architecture for Differentiated
Services." RFC 2475, December 1998.
[11] Baker, F., "RSVP Cryptographic Authentication", Internet Draft,
August 1997
[12] Braden, R., Clark, D. and Shenker, S., "Integrated Services in
the Internet Architecture: an Overview", Internet RFC 1633, June 1994
[13] Garrett, M. W., and Borden, M., "Interoperation of Controlled-
Load Service and Guaranteed Service with ATM", RFC2381, August 1998.
[14] Weiss, Walter, Private communication, November 1998.
[15] Berson, S. and Vincent, S., "Aggregation of Internet Integrated
Services State", Internet Draft, August 1998.
APPENDIX A. Terminology
The following terms were used in this draft.
Int-serv
The part of an internet that uses per-flow classification,
signaling, and admission control to deliver per-flow QoS
guarantee.
[Diff-serv region (or diff-serv capable network)] The part of an
internet that provides aggregate QoS services
Quantitative
Application for which QoS requirements are readily quantifiable,
and which relies on these QoS requirements to function properly.
Qualitative
Applications for which relative, but not readily quantifiable,
QoS requirements exist.
QoS Application that requires some form of QoS, either qualitative
or quantitative.
LooseQoS assurances that are relative, rather than absolute, or
generally not quantifiable.
Bernet, Ed. et. al Expiration: August 1999 [Page 19]
Internet Draft Use Of RSVP with Diffserv February 1999
TightQoS assurances which are quantifiable, though they may or may
not provide 100% guarantee.
Top-down
Traditional provisioning methods that configure network
capacities using heuristics and experience, typically from a
console, based upon traffic predictions.
Bernet, Ed. et. al Expiration: August 1999 [Page 20]
Internet Draft Use Of RSVP with Diffserv February 1999
Author's Addresses
Yoram Bernet
Microsoft
One Microsoft Way,
Redmond, WA 98052
Phone: (425) 936-9568
Email: yoramb@microsoft.com
Raj Yavatkar
Intel Corporation, JF3-206
2111 NE 25th. Avenue,
Hillsboro, OR 97124
Phone: (503) 264-9077
Email: raj.yavatkar@intel.com
Peter Ford
Microsoft
One Microsoft Way,
Redmond, WA 98052
Phone: (425) 703-2032
Email: peterf@microsoft.com
Fred Baker
Cisco Systems
519 Lado Drive,
Santa Barbara, CA 93111
Phone: (408) 526-4257
Email: fred@cisco.com
Lixia Zhang
UCLA
4531G Boelter Hall
Los Angeles, CA 90095
Phone: +1 310-825-2695
Email: lixia@cs.ucla.edu
Kathleen Nichols
Cisco Systems
Email: kmn@cisco.com
Michael Speer
Sun Microsystems, Inc
901 San Antonio Road UMPK15-215
Palo Alto, CA 94303
phone: +1 650-786-6368
Email: speer@Eng.Sun.COM
Bernet, Ed. et. al Expiration: August 1999 [Page 21]
Internet Draft Use Of RSVP with Diffserv February 1999
Bob Braden
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
phone: 310-822-1511
Email: braden@isi.edu
Bernet, Ed. et. al Expiration: August 1999 [Page 22]
