rfc2998.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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
   how such a region may be used in delivery of end-to-end QOS when only
   BA classification is performed inside the Diffserv region.

   Non-Diffserv Region.  The portions of the network outside the
   Diffserv region.  Such a region may also offer a variety of different