The Use of RSVP with IETF Integrated Services
RFC 2210

Document Type RFC - Proposed Standard (September 1997; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2210 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text