📄 rfc2998.txt
字号:
Network Working Group Y. Bernet
Request for Comments: 2998 P. Ford
Category: Informational Microsoft
R. Yavatkar
Intel
F. Baker
Cisco
L. Zhang
UCLA
M. Speer
Sun Microsystems
R. Braden
ISI
B. Davie
Cisco
J. Wroclawski
MIT LCS
E. Felstaine
SANRAD
November 2000
A Framework for Integrated Services Operation over Diffserv Networks
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
The Integrated Services (Intserv) architecture provides a means for
the delivery of end-to-end Quality of Service (QoS) to applications
over heterogeneous networks. To support this end-to-end model, the
Intserv architecture must be supported over a wide variety of
different types of network elements. In this context, a network that
supports Differentiated Services (Diffserv) may be viewed as a
network element in the total end-to-end path. This document
describes a framework by which Integrated Services may be supported
over Diffserv networks.
Bernet, et al. Informational [Page 1]
RFC 2998 Integrated Services Over Diffserv Networks November 2000
Table of Contents
1. Introduction ................................................. 3
1.1 Integrated Services Architecture ............................ 3
1.2 RSVP ........................................................ 3
1.3 Diffserv .................................................... 4
1.4 Roles of Intserv, RSVP and Diffserv ......................... 4
1.5 Components of Intserv, RSVP and Diffserv .................... 5
1.6 The Framework ............................................... 6
1.7 Contents .................................................... 6
2. Benefits of Using Intserv with Diffserv ...................... 7
2.1 Resource Based Admission Control ............................ 7
2.2 Policy Based Admission Control .............................. 8
2.3 Assistance in Traffic Identification/Classification ......... 8
2.3.1 Host Marking .............................................. 9
2.3.2 Router Marking ............................................ 9
2.4 Traffic Conditioning ........................................ 10
3. The Framework ................................................ 10
3.1 Reference Network ........................................... 11
3.1.1 Hosts ..................................................... 11
3.1.2 End-to-End RSVP Signaling ................................. 12
3.1.3 Edge Routers .............................................. 12
3.1.4 Border Routers ............................................ 12
3.1.5 Diffserv Network Region ................................... 13
3.1.6 Non-Diffserv Network Regions .............................. 13
3.2 Service Mapping ............................................. 13
3.2.1 Default Mapping ........................................... 14
3.2.2 Network Driven Mapping .................................... 14
3.2.3 Microflow Separation ...................................... 14
3.3 Resource Management in Diffserv Regions ..................... 15
4. Detailed Examples of the Operation of
Intserv over Diffserv Regions ................................ 16
4.1 Statically Provisioned Diffserv Network Region .............. 16
4.1.1 Sequence of Events in Obtaining End-to-end QoS ............ 16
4.2 RSVP-Aware Diffserv Network Region .......................... 18
4.2.1 Aggregated or Tunneled RSVP ............................... 19
4.2.3 Per-flow RSVP ............................................. 20
4.2.4 Granularity of Deployment of RSVP Aware Routers ........... 20
4.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region ..... 21
5. Implications of the Framework for Diffserv Network Regions ... 21
5.1 Requirements from Diffserv Network Regions .................. 21
5.2 Protection of Intserv Traffic from Other Traffic ............ 22
6. Multicast .................................................... 22
6.1 Remarking of packets in branch point routers ................ 24
6.2 Multicast SLSs and Heterogeneous Trees ...................... 25
7. Security Considerations ...................................... 26
7.1 General RSVP Security ....................................... 26
7.2 Host Marking ................................................ 26
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. Introduction
Work on QoS-enabled IP networks has led to two distinct approaches:
the Integrated Services architecture (Intserv) [10] and its
accompanying signaling protocol, RSVP [1], and the Differentiated
Services architecture (Diffserv) [8]. This document describes ways
in which a Diffserv network can be used in the context of the Intserv
architecture to support the delivery of end-to-end QOS.
1.1 Integrated Services Architecture
The integrated services architecture defined a set of extensions to
the traditional best effort model of the Internet with the goal of
allowing end-to-end QOS to be provided to applications. One of the
key components of the architecture is a set of service definitions;
the current set of services consists of the controlled load and
guaranteed services. The architecture assumes that some explicit
setup mechanism is used to convey information to routers so that they
can provide requested services to flows that require them. While
RSVP is the most widely known example of such a setup mechanism, the
Intserv architecture is designed to accommodate other mechanisms.
Intserv services are implemented by "network elements". While it is
common for network elements to be individual nodes such as routers or
links, more complex entities, such as ATM "clouds" or 802.3 networks
may also function as network elements. As discussed in more detail
below, a Diffserv network (or "cloud") may be viewed as a network
element within a larger Intserv network.
1.2 RSVP
RSVP is a signaling protocol that applications may use to request
resources from the network. The network responds by explicitly
admitting or rejecting RSVP requests. Certain applications that have
quantifiable resource requirements express these requirements using
Intserv parameters as defined in the appropriate Intserv service
specification. As noted above, RSVP and Intserv are separable. RSVP
is a signaling protocol which may carry Intserv information. Intserv
defines the models for expressing service types, quantifying resource
requirements and for determining the availability of the requested
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 combined
RSVP/Intserv architecture. In this model, RSVP signals per-flow
resource requirements to network elements, using Intserv parameters.
These network elements apply Intserv admission control to signaled
requests. In addition, traffic control mechanisms on the network
element are configured to ensure that each admitted flow receives the
service requested in strict isolation from other traffic. To this
end, RSVP signaling configures microflow (MF) [8] packet classifiers
in Intserv capable routers along the path of the traffic flow. These
classifiers enable per-flow classification of packets based on IP
addresses and port numbers.
The following factors have impeded deployment of RSVP (and the
Intserv architecture) in the Internet at large:
1. The use of per-flow state and per-flow processing raises
scalability concerns for large networks.
2. Only a small number of hosts currently generate RSVP signaling.
While this number is expected to grow dramatically, many
applications may never generate RSVP signaling.
3. The necessary policy control mechanisms -- access control,
authentication, and accounting -- have only recently become
available [17].
1.3 Diffserv
In contrast to the per-flow orientation of RSVP, Diffserv networks
classify packets into one of a small number of aggregated flows or
"classes", based on the Diffserv codepoint (DSCP) in the packet's IP
header. This is known as behavior aggregate (BA) classification [8].
At each Diffserv router, packets are subjected to a "per-hop
behavior" (PHB), which is invoked by the DSCP. The primary benefit
of Diffserv is its scalability. Diffserv eliminates the need for
per-flow state and per-flow processing and therefore scales well to
large networks.
1.4 Roles of Intserv, RSVP and Diffserv
We view Intserv, RSVP and Diffserv as complementary technologies in
the pursuit of end-to-end QoS. Together, these mechanisms can
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 regarding
admissibility of these requests. Diffserv enables scalability across
large networks.
Bernet, et al. Informational [Page 4]
RFC 2998 Integrated Services Over Diffserv Networks November 2000
1.5 Components of Intserv, RSVP and Diffserv
Before proceeding, it is helpful to identify the following components
of the QoS technologies described:
RSVP signaling - This term refers to the standard RSVP signaling
protocol. RSVP signaling is used by hosts to signal application
resource requirements to the network (and to each other). Network
elements use RSVP signaling to return an admission control decision
to hosts. RSVP signaling may or may not carry Intserv parameters.
Admission control at a network element may or may not be based on the
Intserv model.
MF traffic control - This term refers to traffic control which is
applied independently to individual traffic flows and therefore
requires recognizing individual traffic flows via MF classification.
Aggregate traffic control - This term refers to traffic control which
is applied collectively to sets of traffic flows. These sets of
traffic flows are recognized based on BA (DSCP) classification. In
this document, we use the terms "aggregate traffic control" and
"Diffserv" interchangeably.
Aggregate RSVP. While the existing definition of RSVP supports only
per-flow reservations, extensions to RSVP are being developed to
enable RSVP reservations to be made for aggregated traffic, i.e.,
sets of flows that may be recognized by BA classification. This use
of RSVP may be useful in controlling the allocation of bandwidth in
Diffserv networks.
Per-flow RSVP. The conventional usage of RSVP to perform resource
reservations for individual microflows.
RSVP/Intserv - This term is used to refer to the prevailing model of
RSVP usage which includes RSVP signaling with Intserv parameters,
Intserv admission control and per-flow traffic control at network
elements.
Diffserv Region. A set of contiguous routers which support BA
classification and traffic control. While such a region may also
support MF classification, the goal of this document is to describe
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -