RFC 2210 (rfc2210) - Page 2 of 33

The Use of RSVP with IETF Integrated Services

Alternative Format: Original Text Document


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

Web Standards & Support: