rfc2210.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,428 行 · 第 1/5 页

Network Working Group                                      J. Wroclawski
Request for Comments: 2210                                       MIT LCS
Category: Standards Track                                 September 1997



             The Use of RSVP with IETF Integrated Services


Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This note describes the use of the RSVP resource reservation protocol
   with the Controlled-Load and Guaranteed QoS control services.  The
   RSVP protocol defines several data objects which carry resource
   reservation information but are opaque to RSVP itself.  The usage and
   data format of those objects is given here.

1. Introduction

   The Internet integrated services framework provides the ability for
   applications to choose among multiple, controlled levels of delivery
   service for their data packets. To support this capability, two
   things are required:

      - Individual network elements (subnets and IP routers) along the
      path followed by an application's data packets must support
      mechanisms to control the quality of service delivered to those
      packets.

      - A way to communicate the application's requirements to network
      elements along the path and to convey QoS management information
      between network elements and the application must be provided.

   In the integrated services framework the first function is provided
   by QoS control services such as Controlled-Load [RFC 2211] and
   Guaranteed [RFC 2212].  The second function may be provided in a
   number of ways, but is frequently implemented by a resource
   reservation setup protocol such as RSVP [RFC 2205].





Wroclawski                  Standards Track                     [Page 1]

RFC 2210                   RSVP with INTSERV              September 1997


   Because RSVP is designed to be used with a variety of QoS control
   services, and because the QoS control services are designed to be
   used with a variety of setup mechanisms, a logical separation exists
   between the two specifications. The RSVP specification does not
   define the internal format of those RSVP protocol fields, or objects,
   which are related to invoking QoS control services. Rather, RSVP
   treats these objects as opaque.  The objects can carry different
   information to meet different application and QoS control service
   requirements.

   Similarly, interfaces to the QoS control services are defined in a
   general format, so that the services can be used with a variety of
   setup mechanisms.

   This RFC provides the information required to use RSVP and the
   integrated service framework's QoS control services together. It
   defines the usage and contents of three RSVP protocol objects, the
   FLOWSPEC, ADSPEC, and SENDER_TSPEC, in an environment supporting the
   Controlled-Load and/or Guaranteed QoS control services. If new
   services or capabilities are added to the integrated services
   framework, this note will be revised as required.

2. Use of RSVP

   Several types of data must be transported between applications and
   network elements to correctly invoke QoS control services.

      NOTE: In addition to the data used to directly invoke QoS control
      services, RSVP carries authentication, accounting, and policy
      information needed to manage the use of these services. This note
      is concerned only with the RSVP objects needed to actually invoke
      QoS control services, and does not discuss accounting or policy
      objects.

   This data includes:

      - Information generated by each receiver describing the QoS
      control service desired, a description of the traffic flow to
      which the resource reservation should apply (the Receiver TSpec),
      and whatever parameters are required to invoke the service (the
      Receiver RSpec). This information is carried from the receivers to
      intermediate network elements and the sender(s) by RSVP FLOWSPEC
      objects. The information being carried in a FLOWSPEC object may
      change at intermediate points in the network due to reservation
      merging and other factors.






Wroclawski                  Standards Track                     [Page 2]

RFC 2210                   RSVP with INTSERV              September 1997


      - Information generated at each sender describing the data traffic
      generated by that sender (the Sender TSpec). This information is
      carried from the sender to intermediate network elements and the
      receiver(s) by RSVP, but is never modified by intermediate
      elements within the network. This information is carried in RSVP
      SENDER_TSPEC objects.

      - Information generated or modified within the network and used at
      the receivers to make reservation decisions.  This information
      might include available services, delay and bandwidth estimates,
      and operating parameters used by specific QoS control services.
      this information is collected from network elements and carried
      towards receivers in RSVP ADSPEC objects.  Rather than carrying
      information from each intermediate node separately to the
      receivers, the information in the ADSPEC represents a summary,
      computed as the ADSPEC passes each hop.  The size of this summary
      remains (roughly) constant as the ADSPEC flows through the
      network, giving good scaling properties.

   From the point of view of RSVP objects, the breakdown is as follows:

      - The RSVP SENDER_TSPEC object carries the traffic specification
      (sender TSpec) generated by each data source within an RSVP
      session.  It is transported unchanged through the network, and
      delivered to both intermediate nodes and receiving applications.

      - The RSVP ADSPEC object carries information which is generated at
      either data sources or intermediate network elements, is flowing
      downstream towards receivers, and may be used and updated inside
      the network before being delivered to receiving applications.
      This information includes both parameters describing the
      properties of the data path, including the availability of
      specific QoS control services, and parameters required by specific
      QoS control services to operate correctly.

      - The RSVP FLOWSPEC object carries reservation request
      (Receiver_TSpec and RSpec) information generated by data
      receivers.  The information in the FLOWSPEC flows upstream towards
      data sources.  It may be used or updated at intermediate network
      elements before arriving at the sending application.

        NOTE: The existence of both SENDER_TSPEC and ADSPEC RSVP objects
        is somewhat historical. Using the message format described in
        this note it would be possible to place all of the service
        control information carried "downstream" by RSVP in the same
        object. However, the distinction between data which is not
        updated within the network (in the SENDER_TSPEC object) and data
        which is updated within the network (in the ADSPEC object) may



Wroclawski                  Standards Track                     [Page 3]

RFC 2210                   RSVP with INTSERV              September 1997


        be useful to an implementation in practice, and is therefore
        retained.

2.1 Summary of operation

   Operation proceeds as follows:

   An application instance participating in an RSVP session as a data
   sender registers with RSVP. One piece of information provided by the
   application instance is the Sender TSpec describing the traffic the
   application expects to generate.  This information is used to
   construct an RSVP SENDER_TSPEC object, which is included in RSVP PATH
   messages generated for the application.

   The sending application also constructs an initial RSVP ADSPEC
   object.  This adspec carries information about the QoS control
   capabilities and requirements of the sending application itself, and
   forms the starting point for the accumulation of path properties
   described below. The ADSPEC is added to the RSVP PATH message created
   at the sender.

      NOTE: For the convenience of application programmers, a host RSVP
      implementation may allow the sending application not to provide an
      initial adspec, instead supplying its own default.  This usage is
      most likely when the application sender does not itself
      participate in the end-to-end QoS control process (by actively
      scheduling CPU usage and similar means) and does not itself care
      which QoS control service is selected by the receivers.

      Typically the default ADSPEC supplied by the host RSVP in this
      case would support all QoS control services known to the host.
      However, the exact behavior of this mechanism is implementation
      dependent.

   The ADSPEC is modified by subsequent network elements as the RSVP
   PATH message moves from sender to receiver(s).  At each network
   element, the ADSPEC is passed from RSVP to the traffic control
   module.  The traffic control module updates the ADSPEC, which may
   contain data for several QoS control services, by identifying the
   services mentioned in the ADSPEC and calling each such service to
   update its portion of the ADSPEC. If the traffic control module
   discovers a QoS control service mentioned in the ADSPEC but not
   implemented by the network element, a flag is set to report this to
   the receiver.  The updated ADSPEC is then returned to RSVP for
   delivery to the next hop along the path.






Wroclawski                  Standards Track                     [Page 4]

RFC 2210                   RSVP with INTSERV              September 1997


   Upon arrival of the PATH message at an application receiver, the data
   in the SENDER_TSPEC and ADSPEC objects is passed across the RSVP API
   to the application.  The application (perhaps with the help of a
   library of common resource-reservation functions) interprets the
   arriving data, and uses it to guide the selection of resource
   reservation parameters.  Examples of this include use of the arriving
   "PATH_MTU" composed characterization parameter [RFC 2215] to
   determine the maximum packet size parameter in the reservation
   request and use of the arriving Guaranteed service "C" and "D"
   parameters [RFC 2212] to calculate a mathematical bound on delivered
   packet delay when using the Guaranteed service.

   An application receiver wishing to make a resource reservation
   supplies its local RSVP with the necessary reservation parameters.
   Among these are the QoS control service desired (Guaranteed or
   Controlled-Load), the traffic specifier (TSpec) describing the level
   of traffic for which resources should be reserved, and, if needed by
   the selected QoS control service, an RSpec describing the level of
   service desired.  These parameters are composed into an RSVP FLOWSPEC
   object and transmitted upstream by RSVP.

   At each RSVP-aware point in the network, the SENDER_TSPECs arriving
   in PATH messages and the FLOWSPECs arriving in RESV messages are used
   to request an appropriate resource reservation from the desired QoS
   control service.  State merging, message forwarding, and error
   handling proceed according to the rules of the RSVP protocol.

   Finally, the merged FLOWSPEC object arriving at each of an RSVP
   session's data senders is delivered to the application to inform each
   sender of the merged reservation request and properties of the data
   path.

2.2. RSVP support for multiple QoS control services

   The design described in this note supports RSVP sessions in which the
   receivers choose a QoS control service at runtime.

   To make this possible, a receiver must have all the information
   needed to choose a particular service before it makes the choice.
   This means that the RSVP SENDER_TSPEC and ADSPEC objects must provide
   the receivers with information for all services which might be
   chosen.

   The Sender TSpec used by the two currently defined QoS control
   services is identical.  This simplifies the RSVP SENDER_TSPEC object,
   which need carry only a single TSpec data structure in this shared
   format.  This common SENDER_TSPEC can be used with either Guaranteed
   or Controlled-Load service.



Wroclawski                  Standards Track                     [Page 5]

RFC 2210                   RSVP with INTSERV              September 1997