Home   A   B   C   D   E   F   G   H   I   J   K   L   M   N   O   P   Q   R   S   T   U   V   W   X   Y   Z  

Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification :: RFC2205


     





Network Working Group                                   R. Braden, Ed.
Request for Comments: 2205                                         ISI
Category: Standards Track                                     L. Zhang
                                                                  UCLA
                                                             S. Berson
                                                                   ISI
                                                             S. Herzog
                                                          IBM Research
                                                              S. Jamin
                                                     Univ. of Michigan
                                                        September 1997


                Resource ReSerVation Protocol (RSVP) --

                   Version 1 Functional Specification

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 memo describes version 1 of RSVP, a resource reservation setup
   protocol designed for an integrated services Internet.  RSVP provides
   receiver-initiated setup of resource reservations for multicast or
   unicast data flows, with good scaling and robustness properties.




















Braden, Ed., et. al.        Standards Track                     [Page 1]

RFC 2205                          RSVP                    September 1997


Table of Contents

   1. Introduction ................................................... 4
      1.1 Data Flows ................................................. 7
      1.2 Reservation Model .......................................... 8
      1.3 Reservation Styles .........................................11
      1.4 Examples of Styles .........................................14
   2. RSVP Protocol Mechanisms .......................................19
      2.1 RSVP Messages ..............................................19
      2.2 Merging Flowspecs ..........................................21
      2.3 Soft State .................................................22
      2.4 Teardown ...................................................24
      2.5 Errors .....................................................25
      2.6 Confirmation ...............................................27
      2.7 Policy Control .............................................27
      2.8 Security ...................................................28
      2.9 Non-RSVP Clouds ............................................29
      2.10 Host Model ................................................30
   3. RSVP Functional Specification ..................................32
      3.1 RSVP Message Formats .......................................32
      3.2 Port Usage .................................................47
      3.3 Sending RSVP Messages ......................................48
      3.4 Avoiding RSVP Message Loops ................................50
      3.5 Blockade State .............................................54
      3.6 Local Repair ...............................................56
      3.7 Time Parameters ............................................57
      3.8 Traffic Policing and Non-Integrated Service Hops ...........58
      3.9 Multihomed Hosts ...........................................59
      3.10 Future Compatibility ......................................61
      3.11 RSVP Interfaces ...........................................63
   4. Acknowledgments ................................................76
   APPENDIX A. Object Definitions ....................................77
   APPENDIX B. Error Codes and Values ................................92
   APPENDIX C. UDP Encapsulation .....................................98
   APPENDIX D. Glossary .............................................102
   REFERENCES .......................................................111
   SECURITY CONSIDERATIONS ..........................................111
   AUTHORS' ADDRESSES ...............................................112













Braden, Ed., et. al.        Standards Track                     [Page 2]

RFC 2205                          RSVP                    September 1997


   What's Changed

   This revision contains the following very minor changes from the ID14
   version.


      o    For clarity, each message type is now defined separately in
           Section 3.1.

      o    We added more precise and complete rules for accepting Path
           messages for unicast and multicast destinations (Section
           3.1.3).

      o    We added more precise and complete rules for processing and
           forwarding PathTear messages (Section 3.1.5).

      o    A note was added that a SCOPE object will be ignored if it
           appears in a ResvTear message (Section 3.1.6).

      o    A note was added that a SENDER_TSPEC or ADSPEC object will be
           ignored if it appears in a PathTear message (Section 3.1.5).

      o    The obsolete error code Ambiguous Filter Spec (09) was
           removed, and a new (and more consistent) name was given to
           error code 08 (Appendix B).

      o    In the generic interface to traffic control, the Adspec was
           added as a parameter to the AddFlow and ModFlow calls
           (3.11.2).  This is needed to accommodate a node that updates
           the slack term (S) of Guaranteed service.

      o    An error subtype was added for an Adspec error (Appendix B).

      o    Additional explanation was added for handling a CONFIRM
           object (Section 3.1.4).

      o    The rules for forwarding objects with unknown class type were
           clarified.

      o    Additional discussion was added to the Introduction and to
           Section 3.11.2 about the relationship of RSVP to the link
           layer.  (Section 3.10).

      o    Section 2.7 on Policy and Security was split into two
           sections, and some additional discussion of security was
           included.

      o    There were some minor editorial improvements.



Braden, Ed., et. al.        Standards Track                     [Page 3]

RFC 2205                          RSVP                    September 1997


1. Introduction

   This document defines RSVP, a resource reservation setup protocol
   designed for an integrated services Internet [RSVP93, RFC 1633].  The
   RSVP protocol is used by a host to request specific qualities of
   service from the network for particular application data streams or
   flows.  RSVP is also used by routers to deliver quality-of-service
   (QoS) requests to all nodes along the path(s) of the flows and to
   establish and maintain state to provide the requested service.  RSVP
   requests will generally result in resources being reserved in each
   node along the data path.

   RSVP requests resources for simplex flows, i.e., it requests
   resources in only one direction.  Therefore, RSVP treats a sender as
   logically distinct from a receiver, although the same application
   process may act as both a sender and a receiver at the same time.
   RSVP operates on top of IPv4 or IPv6, occupying the place of a
   transport protocol in the protocol stack.  However, RSVP does not
   transport application data but is rather an Internet control
   protocol, like ICMP, IGMP, or routing protocols.  Like the
   implementations of routing and management protocols, an
   implementation of RSVP will typically execute in the background, not
   in the data forwarding path, as shown in Figure 1.

   RSVP is not itself a routing protocol; RSVP is designed to operate
   with current and future unicast and multicast routing protocols.  An
   RSVP process consults the local routing database(s) to obtain routes.
   In the multicast case, for example, a host sends IGMP messages to
   join a multicast group and then sends RSVP messages to reserve
   resources along the delivery path(s) of that group.  Routing
   protocols determine where packets get forwarded; RSVP is only
   concerned with the QoS of those packets that are forwarded in
   accordance with routing.

   In order to efficiently accommodate large groups, dynamic group
   membership, and heterogeneous receiver requirements, RSVP makes
   receivers responsible for requesting a specific QoS [RSVP93].  A QoS
   request from a receiver host application is passed to the local RSVP
   process.  The RSVP protocol then carries the request to all the nodes
   (routers and hosts) along the reverse data path(s) to the data
   source(s), but only as far as the router where the receiver's data
   path joins the multicast distribution tree.  As a result, RSVP's
   reservation overhead is in general logarithmic rather than linear in
   the number of receivers.







Braden, Ed., et. al.        Standards Track                     [Page 4]

RFC 2205                          RSVP                    September 1997



              HOST                              ROUTER

 _____________________________       ____________________________
|  _______                    |     |                            |
| |       |   _______         |     |            _______         |
| |Appli- |  |       |        |RSVP |           |       |        |
| | cation|  | RSVP <---------------------------> RSVP  <---------->
| |       <-->       |        |     | _______   |       |        |
| |       |  |process|  _____ |     ||Routing|  |process|  _____ |
| |_._____|  |       -->Polcy||     ||       <-->       -->Polcy||
|   |        |__.__._| |Cntrl||     ||process|  |__.__._| |Cntrl||
|   |data       |  |   |_____||     ||__.____|     |  |   |_____||
|===|===========|==|==========|     |===|==========|==|==========|
|   |   --------|  |    _____ |     |   |  --------|  |    _____ |
|   |  |        |  ---->Admis||     |   |  |       |  ---->Admis||
|  _V__V_    ___V____  |Cntrl||     |  _V__V_    __V_____ |Cntrl||
| |      |  |        | |_____||     | |      |  |        ||_____||
| |Class-|  | Packet |        |     | |Class-|  | Packet |       |
| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>
| |______|  |________|        |data | |______|  |________|       |data
|                             |     |                            |
|_____________________________|     |____________________________|


                  Figure 1: RSVP in Hosts and Routers


   Quality of service is implemented for a particular data flow by
   mechanisms collectively called "traffic control".  These mechanisms
   include (1) a packet classifier, (2) admission control, and (3) a
   "packet scheduler" or some other link-layer-dependent mechanism to
   determine when particular packets are forwarded.  The "packet
   classifier" determines the QoS class (and perhaps the route) for each
   packet.  For each outgoing interface, the "packet scheduler" or other
   link-layer-dependent mechanism achieves the promised QoS.  Traffic
   control implements QoS service models defined by the Integrated
   Services Working Group.

   During reservation setup, an RSVP QoS request is passed to two local
   decision modules, "admission control" and "policy control".
   Admission control determines whether the node has sufficient
   available resources to supply the requested QoS.  Policy control








Braden, Ed., et. al.        Standards Track                     [Page 5]

RFC 2205                          RSVP                    September 1997


   determines whether the user has administrative permission to make the
   reservation.  If both checks succeed, parameters are set in the
   packet classifier and in the link layer interface (e.g., in the
   packet scheduler) to obtain the desired QoS.  If either check fails,
   the RSVP program returns an error notification to the application
   process that originated the request.

   RSVP protocol mechanisms provide a general facility for creating and
   maintaining distributed reservation state across a mesh of multicast
   or unicast delivery paths.  RSVP itself transfers and manipulates QoS
   and policy control parameters as opaque data, passing them to the
   appropriate traffic control and policy control modules for
   interpretation.  The structure and contents of the QoS parameters are
   documented in specifications developed by the Integrated Services
   Working Group; see [RFC 2210].  The structure and contents of the
   policy parameters are under development.

   Since the membership of a large multicast group and the resulting
   multicast tree topology are likely to change with time, the RSVP
   design assumes that state for RSVP and traffic control state is to be
   built and destroyed incrementally in routers and hosts.  For this
   purpose, RSVP establishes "soft" state; that is, RSVP sends periodic
   refresh messages to maintain the state along the reserved path(s).
   In the absence of refresh messages, the state automatically times out
   and is deleted.

   In summary, RSVP has the following attributes:

   o    RSVP makes resource reservations for both unicast and many-to-
        many multicast applications, adapting dynamically to changing
        group membership as well as to changing routes.

   o    RSVP is simplex, i.e., it makes reservations for unidirectional
        data flows.

   o    RSVP is receiver-oriented, i.e., the receiver of a data flow
        initiates and maintains the resource reservation used for that
        flow.

   o    RSVP maintains "soft" state in routers and hosts, providing
        graceful support for dynamic membership changes and automatic
        adaptation to routing changes.

   o    RSVP is not a routing protocol but depends upon present and
        future routing protocols.

   o    RSVP transports and maintains traffic control and policy control
        parameters that are opaque to RSVP.



Braden, Ed., et. al.        Standards Track                     [Page 6]

RFC 2205                          RSVP                    September 1997


   o    RSVP provides several reservation models or "styles" (defined
        below) to fit a variety of applications.

   o    RSVP provides transparent operation through routers that do not
        support it.

   o    RSVP supports both IPv4 and IPv6.

   Further discussion on the objectives and general justification for
   RSVP design are presented in [RSVP93] and [RFC 1633].

   The remainder of this section describes the RSVP reservation
   services.  Section 2 presents an overview of the RSVP protocol
   mechanisms.  Section 3 contains the functional specification of RSVP,
   while Section 4 presents explicit message processing rules.  Appendix
   A defines the variable-length typed data objects used in the RSVP
   protocol.  Appendix B defines error codes and values.  Appendix C
   defines a UDP encapsulation of RSVP messages, for hosts whose
   operating systems provide inadequate raw network I/O support.

   1.1 Data Flows

      RSVP defines a "session" to be a data flow with a particular
      destination and transport-layer protocol.  RSVP treats each
      session independently, and this document often omits the implied
      qualification "for the same session".

      An RSVP session is defined by the triple: (DestAddress, ProtocolId
      [, DstPort]).  Here DestAddress, the IP destination address of the
      data packets, may be a unicast or multicast address.  ProtocolId
      is the IP protocol ID.  The optional DstPort parameter is a
      "generalized destination port", i.e., some further demultiplexing
      point in the transport or application protocol layer.  DstPort
      could be defined by a UDP/TCP destination port field, by an
      equivalent field in another transport protocol, or by some
      application-specific information.

      Although the RSVP protocol is designed to be easily extensible for
      greater generality, the basic protocol documented here supports
      only UDP/TCP ports as generalized ports.  Note that it is not
      strictly necessary to include DstPort in the session definition
      when DestAddress is multicast, since different sessions can always
      have different multicast addresses.  However, DstPort is necessary
      to allow more than one unicast session addressed to the same
      receiver host.






Braden, Ed., et. al.        Standards Track                     [Page 7]

RFC 2205                          RSVP                    September 1997


      Figure 2 illustrates the flow of data packets in a single RSVP
      session, assuming multicast data distribution.  The arrows
      indicate data flowing from senders S1 and S2 to receivers R1, R2,
      and R3, and the cloud represents the distribution mesh created by
      multicast routing.  Multicast distribution forwards a copy of each
      data packet from a sender Si to every receiver Rj; a unicast
      distribution session has a single receiver R.  Each sender Si may
      be running in a unique Internet host, or a single host may contain
      multiple senders distinguished by "generalized source ports".


              Senders                              Receivers
                          _____________________
                         (                     ) ===> R1
                 S1 ===> (    Multicast        )
                         (                     ) ===> R2
                         (    distribution     )
                 S2 ===> (                     )
                         (    by Internet      ) ===> R3
                         (_____________________)

                 Figure 2: Multicast Distribution Session


      For unicast transmission, there will be a single destination host
      but there may be multiple senders; RSVP can set up reservations
      for multipoint-to-single-point transmission.

   1.2 Reservation Model

      An elementary RSVP reservation request consists of a "flowspec"
      together with a "filter spec"; this pair is called a "flow
      descriptor".  The flowspec specifies a desired QoS.  The filter
      spec, together with a session specification, defines the set of
      data packets -- the "flow" -- to receive the QoS defined by the
      flowspec.  The flowspec is used to set parameters in the node's
      packet scheduler or other link layer mechanism, while the filter
      spec is used to set parameters in the packet classifier.  Data
      packets that are addressed to a particular session but do not
      match any of the filter specs for that session are handled as
      best-effort traffic.

      The flowspec in a reservation request will generally include a
      service class and two sets of numeric parameters: (1) an "Rspec"
      (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
      (T for `traffic') that describes the data flow.  The formats and
      contents of Tspecs and Rspecs are determined by the integrated
      service models [RFC 2210] and are generally opaque to RSVP.



Braden, Ed., et. al.        Standards Track                     [Page 8]

RFC 2205                          RSVP                    September 1997


      The exact format of a filter spec depends upon whether IPv4 or
      IPv6 is in use; see Appendix A.  In the most general approach
      [RSVP93], filter specs may select arbitrary subsets of the packets
      in a given session.  Such subsets might be defined in terms of
      senders (i.e., sender IP address and generalized source port), in
      terms of a higher-level protocol, or generally in terms of any
      fields in any protocol headers in the packet.  For example, filter
      specs might be used to select different subflows of a
      hierarchically-encoded video stream by selecting on fields in an
      application-layer header.  In the interest of simplicity (and to
      minimize layer violation), the basic filter spec format defined in
      the present RSVP specification has a very restricted form: sender
      IP address and optionally the UDP/TCP port number SrcPort.

      Because the UDP/TCP port numbers are used for packet
      classification, each router must be able to examine these fields.
      This raises three potential problems.

      1.   It is necessary to avoid IP fragmentation of a data flow for
           which a resource reservation is desired.

           Document [RFC 2210] specifies a procedure for applications
           using RSVP facilities to compute the minimum MTU over a
           multicast tree and return the result to the senders.

      2.   IPv6 inserts a variable number of variable-length Internet-
           layer headers before the transport header, increasing the
           difficulty and cost of packet classification for QoS.

           Efficient classification of IPv6 data packets could be
           obtained using the Flow Label field of the IPv6 header.  The
           details will be provided in the future.

      3.   IP-level Security, under either IPv4 or IPv6, may encrypt the
           entire transport header, hiding the port numbers of data
           packets from intermediate routers.

           A small extension to RSVP for IP Security under IPv4 and IPv6
           is described separately in [RFC 2207].

      RSVP messages carrying reservation requests originate at receivers
      and are passed upstream towards the sender(s).  Note: in this
      document, we define the directional terms "upstream" vs.
      "downstream", "previous hop" vs. "next hop", and "incoming
      interface" vs "outgoing interface" with respect to the direction
      of data flow.





Braden, Ed., et. al.        Standards Track                     [Page 9]

RFC 2205                          RSVP                    September 1997


      At each intermediate node, a reservation request triggers two
      general actions, as follows:

      1.   Make a reservation on a link

           The RSVP process passes the request to admission control and
           policy control.  If either test fails, the reservation is
           rejected and the RSVP process returns an error message to the
           appropriate receiver(s).  If both succeed, the node sets the
           packet classifier to select the data packets defined by the
           filter spec, and it interacts with the appropriate link layer
           to obtain the desired QoS defined by the flowspec.

           The detailed rules for satisfying an RSVP QoS request depend
           upon the particular link layer technology in use on each
           interface.  Specifications are under development in the ISSLL
           Working Group for mapping reservation requests into popular
           link layer technologies.  For a simple leased line, the
           desired QoS will be obtained from the packet scheduler in the
           link layer driver, for example.  If the link-layer technology
           implements its own QoS management capability, then RSVP must
           negotiate with the link layer to obtain the requested QoS.
           Note that the action to control QoS occurs at the place where
           the data enters the link-layer medium, i.e., at the upstream
           end of the logical or physical link, although an RSVP
           reservation request originates from receiver(s) downstream.

      2.   Forward the request upstream

           A reservation request is propagated upstream towards the
           appropriate senders.  The set of sender hosts to which a
           given reservation request is propagated is called the "scope"
           of that request.

           The reservation request that a node forwards upstream may
           differ from the request that it received from downstream, for
           two reasons.  The traffic control mechanism may modify the
           flowspec hop-by-hop.  More importantly, reservations from
           different downstream branches of the multicast tree(s) from
           the same sender (or set of senders) must be " merged" as
           reservations travel upstream.


      When a receiver originates a reservation request, it can also
      request a confirmation message to indicate that its request was
      (probably) installed in the network.  A successful reservation
      request propagates upstream along the multicast tree until it
      reaches a point where an existing reservation is equal or greater



Braden, Ed., et. al.        Standards Track                    [Page 10]

RFC 2205                          RSVP                    September 1997


      than that being requested.  At that point, the arriving request is
      merged with the reservation in place and need not be forwarded
      further; the node may then send a reservation confirmation message
      back to the receiver.  Note that the receipt of a confirmation is
      only a high-probability indication, not a guarantee, that the
      requested service is in place all the way to the sender(s), as
      explained in Section 2.6.

      The basic RSVP reservation model is "one pass": a receiver sends a
      reservation request upstream, and each node in the path either
      accepts or rejects the request.  This scheme provides no easy way
      for a receiver to find out the resulting end-to-end service.
      Therefore, RSVP supports an enhancement to one-pass service known
      as "One Pass With Advertising" (OPWA) [OPWA95].  With OPWA, RSVP
      control packets are sent downstream, following the data paths, to
      gather information that may be used to predict the end-to-end QoS.
      The results ("advertisements") are delivered by RSVP to the
      receiver hosts and perhaps to the receiver applications.  The
      advertisements may then be used by the receiver to construct, or
      to dynamically adjust, an appropriate reservation request.

   1.3 Reservation Styles

      A reservation request includes a set of options that are
      collectively called the reservation "style".

      One reservation option concerns the treatment of reservations for
      different senders within the same session: establish a "distinct"
      reservation for each upstream sender, or else make a single
      reservation that is "shared" among all packets of selected
      senders.

      Another reservation option controls the selection of senders; it
      may be an "explicit" list of all selected senders, or a "wildcard"
      that implicitly selects all the senders to the session.  In an
      explicit sender-selection reservation, each filter spec must match
      exactly one sender, while in a wildcard sender-selection no filter
      spec is needed.













Braden, Ed., et. al.        Standards Track                    [Page 11]

RFC 2205                          RSVP                    September 1997



           Sender   ||             Reservations:
         Selection  ||     Distinct     |        Shared
           _________||__________________|____________________
                    ||                  |                    |
          Explicit  ||  Fixed-Filter    |  Shared-Explicit   |
                    ||  (FF) style      |  (SE) Style        |
          __________||__________________|____________________|
                    ||                  |                    |
          Wildcard  ||  (None defined)  |  Wildcard-Filter   |
                    ||                  |  (WF) Style        |
          __________||__________________|____________________|


                 Figure 3: Reservation Attributes and Styles



      The following styles are currently defined (see Figure 3):

      o    Wildcard-Filter (WF) Style

           The WF style implies the options: "shared" reservation and
           "wildcard" sender selection.  Thus, a WF-style reservation
           creates a single reservation shared by flows from all
           upstream senders.  This reservation may be thought of as a
           shared "pipe", whose "size" is the largest of the resource
           requests from all receivers, independent of the number of
           senders using it.  A WF-style reservation is propagated
           upstream towards all sender hosts, and it automatically
           extends to new senders as they appear.

           Symbolically, we can represent a WF-style reservation request
           by:

               WF( * {Q})


           where the asterisk represents wildcard sender selection and Q
           represents the flowspec.

      o    Fixed-Filter (FF) Style

           The FF style implies the options: "distinct" reservations and
           "explicit" sender selection.  Thus, an elementary FF-style
           reservation request creates a distinct reservation for data
           packets from a particular sender, not sharing them with other
           senders' packets for the same session.



Braden, Ed., et. al.        Standards Track                    [Page 12]

RFC 2205                          RSVP                    September 1997


           Symbolically, we can represent an elementary FF reservation
           request by:

               FF( S{Q})


           where S is the selected sender and Q is the corresponding
           flowspec; the pair forms a flow descriptor.  RSVP allows
           multiple elementary FF-style reservations to be requested at
           the same time, using a list of flow descriptors:

               FF( S1{Q1}, S2{Q2}, ...)


           The total reservation on a link for a given session is the
           `sum' of Q1, Q2, ... for all requested senders.

      o    Shared Explicit (SE) Style

           The SE style implies the options: "shared" reservation and
           "explicit" sender selection.  Thus, an SE-style reservation
           creates a single reservation shared by selected upstream
           senders.  Unlike the WF style, the SE style allows a receiver
           to explicitly specify the set of senders to be included.

           We can represent an SE reservation request containing a
           flowspec Q and a list of senders S1, S2, ... by:

               SE( (S1,S2,...){Q} )


      Shared reservations, created by WF and SE styles, are appropriate
      for those multicast applications in which multiple data sources
      are unlikely to transmit simultaneously.  Packetized audio is an
      example of an application suitable for shared reservations; since
      a limited number of people talk at once, each receiver might issue
      a WF or SE reservation request for twice the bandwidth required
      for one sender (to allow some over-speaking).  On the other hand,
      the FF style, which creates distinct reservations for the flows
      from different senders, is appropriate for video signals.

      The RSVP rules disallow merging of shared reservations with
      distinct reservations, since these modes are fundamentally
      incompatible.  They also disallow merging explicit sender
      selection with wildcard sender selection, since this might produce
      an unexpected service for a receiver that specified explicit
      selection.  As a result of these prohibitions, WF, SE, and FF
      styles are all mutually incompatible.



Braden, Ed., et. al.        Standards Track                    [Page 13]

RFC 2205                          RSVP                    September 1997


      It would seem possible to simulate the effect of a WF reservation
      using the SE style.  When an application asked for WF, the RSVP
      process on the receiver host could use local state to create an
      equivalent SE reservation that explicitly listed all senders.
      However, an SE reservation forces the packet classifier in each
      node to explicitly select each sender in the list, while a WF
      allows the packet classifier to simply "wild card" the sender
      address and port.  When there is a large list of senders, a WF
      style reservation can therefore result in considerably less
      overhead than an equivalent SE style reservation.  For this
      reason, both SE and WF are included in the protocol.

      Other reservation options and styles may be defined in the future.

   1.4 Examples of Styles

      This section presents examples of each of the reservation styles
      and shows the effects of merging.

      Figure 4 illustrates a router with two incoming interfaces,
      labeled (a) and (b), through which flows will arrive, and two
      outgoing interfaces, labeled (c) and (d), through which data will
      be forwarded.  This topology will be assumed in the examples that
      follow.  There are three upstream senders; packets from sender S1
      (S2 and S3) arrive through previous hop (a) ((b), respectively).
      There are also three downstream receivers; packets bound for R1
      (R2 and R3) are routed via outgoing interface (c) ((d),
      respectively).  We furthermore assume that outgoing interface (d)
      is connected to a broadcast LAN, i.e., that replication occurs in
      the network; R2 and R3 are reached via different next hop routers
      (not shown).

      We must also specify the multicast routes within the node of
      Figure 4.  Assume first that data packets from each Si shown in
      Figure 4 are routed to both outgoing interfaces.  Under this
      assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter,
      Fixed-Filter, and Shared-Explicit reservations, respectively.














Braden, Ed., et. al.        Standards Track                    [Page 14]

RFC 2205                          RSVP                    September 1997


                         ________________
                     (a)|                | (c)
      ( S1 ) ---------->|                |----------> ( R1 )
                        |     Router     |      |
                     (b)|                | (d)  |---> ( R2 )
      ( S2,S3 ) ------->|                |------|
                        |________________|      |---> ( R3 )
                                                |

                        Figure 4: Router Configuration



      For simplicity, these examples show flowspecs as one-dimensional
      multiples of some base resource quantity B.  The "Receives" column
      shows the RSVP reservation requests received over outgoing
      interfaces (c) and (d), and the "Reserves" column shows the
      resulting reservation state for each interface.   The "Sends"
      column shows the reservation requests that are sent upstream to
      previous hops (a) and (b).  In the "Reserves" column, each box
      represents one reserved "pipe" on the outgoing link, with the
      corresponding flow descriptor.

      Figure 5, showing the WF style, illustrates two distinct
      situations in which merging is required.  (1) Each of the two next
      hops on interface (d) results in a separate RSVP reservation
      request, as shown; these two requests must be merged into the
      effective flowspec, 3B, that is used to make the reservation on
      interface (d).  (2) The reservations on the interfaces (c) and (d)
      must be merged in order to forward the reservation requests
      upstream; as a result, the larger flowspec 4B is forwarded
      upstream to each previous hop.



















Braden, Ed., et. al.        Standards Track                    [Page 15]

RFC 2205                          RSVP                    September 1997



                             |
               Sends         |       Reserves             Receives
                             |
                             |       _______
         WF( *{4B} ) <- (a)  |  (c) | * {4B}|    (c) <- WF( *{4B} )
                             |      |_______|
                             |
      -----------------------|----------------------------------------
                             |       _______
         WF( *{4B} ) <- (b)  |  (d) | * {3B}|    (d) <- WF( *{3B} )
                             |      |_______|        <- WF( *{2B} )

              Figure 5: Wildcard-Filter (WF) Reservation Example



      Figure 6 shows Fixed-Filter (FF) style reservations.  For each
      outgoing interface, there is a separate reservation for each
      source that has been requested, but this reservation will be
      shared among all the receivers that made the request.  The flow
      descriptors for senders S2 and S3, received through outgoing
      interfaces (c) and (d), are packed (not merged) into the request
      forwarded to previous hop (b).  On the other hand, the three
      different flow descriptors specifying sender S1 are merged into
      the single request FF( S1{4B} ) that is sent to previous hop (a).


                          |
            Sends         |       Reserves             Receives
                          |
                          |       ________
     FF( S1{4B} ) <- (a)  |  (c) | S1{4B} |  (c) <- FF( S1{4B}, S2{5B} )
                          |      |________|
                          |      | S2{5B} |
                          |      |________|
     ---------------------|---------------------------------------------
                          |       ________
                  <- (b)  |  (d) | S1{3B} |  (d) <- FF( S1{3B}, S3{B} )
     FF( S2{5B}, S3{B} )  |      |________|      <- FF( S1{B} )
                          |      | S3{B}  |
                          |      |________|

              Figure 6: Fixed-Filter (FF) Reservation Example







Braden, Ed., et. al.        Standards Track                    [Page 16]

RFC 2205                          RSVP                    September 1997


      Figure 7 shows an example of Shared-Explicit (SE) style
      reservations.  When SE-style reservations are merged, the
      resulting filter spec is the union of the original filter specs,
      and the resulting flowspec is the largest flowspec.


                          |
            Sends         |       Reserves             Receives
                          |
                          |       ________
     SE( S1{3B} ) <- (a)  |  (c) |(S1,S2) |   (c) <- SE( (S1,S2){B} )
                          |      |   {B}  |
                          |      |________|
     ---------------------|---------------------------------------------
                          |      __________
                  <- (b)  | (d) |(S1,S2,S3)|  (d) <- SE( (S1,S3){3B} )
     SE( (S2,S3){3B} )    |     |   {3B}   |      <- SE( S2{2B} )
                          |     |__________|

            Figure 7: Shared-Explicit (SE) Reservation Example



      The three examples just shown assume that data packets from S1,
      S2, and S3 are routed to both outgoing interfaces.  The top part
      of Figure 8 shows another routing assumption: data packets from S2
      and S3 are not forwarded to interface (c), e.g., because the
      network topology provides a shorter path for these senders towards
      R1, not traversing this node.  The bottom part of Figure 8 shows
      WF style reservations under this assumption.  Since there is no
      route from (b) to (c), the reservation forwarded out interface (b)
      considers only the reservation on interface (d).



















Braden, Ed., et. al.        Standards Track                    [Page 17]

RFC 2205                          RSVP                    September 1997


                         _______________
                     (a)|               | (c)
      ( S1 ) ---------->| >-----------> |----------> ( R1 )
                        |    >          |
                        |      >        |
                     (b)|        >      | (d)
      ( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 )
                        |_______________|

                       Router Configuration


                             |
               Sends         |       Reserves             Receives
                             |
                             |       _______
         WF( *{4B} ) <- (a)  |  (c) | * {4B}|   (c) <- WF( *{4B} )
                             |      |_______|
                             |
      -----------------------|----------------------------------------
                             |       _______
         WF( *{3B} ) <- (b)  |  (d) | * {3B}|   (d) <- WF( * {3B} )
                             |      |_______|       <- WF( * {2B} )

             Figure 8: WF Reservation Example -- Partial Routing


























Braden, Ed., et. al.        Standards Track                    [Page 18]

RFC 2205                          RSVP                    September 1997


2. RSVP Protocol Mechanisms

   2.1 RSVP Messages


       Previous       Incoming           Outgoing             Next
       Hops           Interfaces         Interfaces           Hops

       _____             _____________________                _____
      |     | data -->  |                     |  data -->    |     |
      |  A  |-----------| a                 c |--------------|  C  |
      |_____| Path -->  |                     |  Path -->    |_____|
              <-- Resv  |                     |  <-- Resv     _____
       _____            |       ROUTER        |           |  |     |
      |     |  |        |                     |           |--|  D  |
      |  B  |--| data-->|                     |  data --> |  |_____|
      |_____|  |--------| b                 d |-----------|
               | Path-->|                     |  Path --> |   _____
       _____   | <--Resv|_____________________|  <-- Resv |  |     |
      |     |  |                                          |--|  D' |
      |  B' |--|                                          |  |_____|
      |_____|  |                                          |

                         Figure 9: Router Using RSVP



      Figure 9 illustrates RSVP's model of a router node.  Each data
      flow arrives from a "previous hop" through a corresponding
      "incoming interface" and departs through one or more "outgoing
      interface"(s).  The same interface may act in both the incoming
      and outgoing roles for different data flows in the same session.
      Multiple previous hops and/or next hops may be reached through a
      given physical interface; for example, the figure implies that D
      and D' are connected to (d) with a broadcast LAN.

      There are two fundamental RSVP message types: Resv and Path.

      Each receiver host sends RSVP reservation request (Resv) messages
      upstream towards the senders.  These messages must follow exactly
      the reverse of the path(s) the data packets will use, upstream to
      all the sender hosts included in the sender selection.  They
      create and maintain "reservation state" in each node along the
      path(s).  Resv messages must finally be delivered to the sender
      hosts themselves, so that the hosts can set up appropriate traffic
      control parameters for the first hop.  The processing of Resv
      messages was discussed previously in Section 1.2.




Braden, Ed., et. al.        Standards Track                    [Page 19]

RFC 2205                          RSVP                    September 1997


      Each RSVP sender host transmits RSVP "Path" messages downstream
      along the uni-/multicast routes provided by the routing
      protocol(s), following the paths of the data.  These Path messages
      store "path state" in each node along the way.  This path state
      includes at least the unicast IP address of the previous hop node,
      which is used to route the Resv messages hop-by-hop in the reverse
      direction.  (In the future, some routing protocols may supply
      reverse path forwarding information directly, replacing the
      reverse-routing function of path state).

      A Path message contains the following information in addition to
      the previous hop address:

      o    Sender Template

           A Path message is required to carry a Sender Template, which
           describes the format of data packets that the sender will
           originate.  This template is in the form of a filter spec
           that could be used to select this sender's packets from
           others in the same session on the same link.

           Sender Templates have exactly the same expressive power and
           format as filter specs that appear in Resv messages.
           Therefore a Sender Template may specify only the sender IP
           address and optionally the UDP/TCP sender port, and it
           assumes the protocol Id specified for the session.

      o    Sender Tspec

           A Path message is required to carry a Sender Tspec, which
           defines the traffic characteristics of the data flow that the
           sender will generate.  This Tspec is used by traffic control
           to prevent over-reservation, and perhaps unnecessary
           Admission Control failures.

      o    Adspec

           A Path message may carry a package of OPWA advertising
           information, known as an "Adspec".  An Adspec received in a
           Path message is passed to the local traffic control, which
           returns an updated Adspec; the updated version is then
           forwarded in Path messages sent downstream.









Braden, Ed., et. al.        Standards Track                    [Page 20]

RFC 2205                          RSVP                    September 1997


      Path messages are sent with the same source and destination
      addresses as the data, so that they will be routed correctly
      through non-RSVP clouds (see Section 2.9).  On the other hand,
      Resv messages are sent hop-by-hop; each RSVP-speaking node
      forwards a Resv message to the unicast address of a previous RSVP
      hop.

   2.2 Merging Flowspecs

      A Resv message forwarded to a previous hop carries a flowspec that
      is the "largest" of the flowspecs requested by the next hops to
      which the data flow will be sent (however, see Section 3.5 for a
      different merging rule used in certain cases).  We say the
      flowspecs have been "merged".  The examples shown in Section 1.4
      illustrated another case of merging, when there are multiple
      reservation requests from different next hops for the same session
      and with the same filter spec, but RSVP should install only one
      reservation on that interface.  Here again, the installed
      reservation should have an effective flowspec that is the
      "largest" of the flowspecs requested by the different next hops.

      Since flowspecs are opaque to RSVP, the actual rules for comparing
      flowspecs must be defined and implemented outside RSVP proper.
      The comparison rules are defined in the appropriate integrated
      service specification document.  An RSVP implementation will need
      to call service-specific routines to perform flowspec merging.

      Note that flowspecs are generally multi-dimensional vectors; they
      may contain both Tspec and Rspec components, each of which may
      itself be multi-dimensional.  Therefore, it may not be possible to
      strictly order two flowspecs.  For example, if one request calls
      for a higher bandwidth and another calls for a tighter delay
      bound, one is not "larger" than the other.  In such a case,
      instead of taking the larger, the service-specific merging
      routines must be able to return a third flowspec that is at least
      as large as each; mathematically, this is the "least upper bound"
      (LUB).  In some cases, a flowspec at least as small is needed;
      this is the "greatest lower bound" (GLB) GLB (Greatest Lower
      Bound).

      The following steps are used to calculate the effective flowspec
      (Re, Te) to be installed on an interface [RFC 2210].  Here Te is
      the effective Tspec and Re is the effective Rspec.








Braden, Ed., et. al.        Standards Track                    [Page 21]

RFC 2205                          RSVP                    September 1997


      1.   An effective flowspec is determined for the outgoing
           interface.  Depending upon the link-layer technology, this
           may require merging flowspecs from different next hops; this
           means computing the effective flowspec as the LUB of the
           flowspecs.  Note that what flowspecs to merge is determined
           by the link layer medium (see Section 3.11.2), while how to
           merge them is determined by the service model in use [RFC
           2210].

           The result is a flowspec that is opaque to RSVP but actually
           consists of the pair (Re, Resv_Te), where is Re is the
           effective Rspec and Resv_Te is the effective Tspec.

      2.   A service-specific calculation of Path_Te, the sum of all
           Tspecs that were supplied in Path messages from different
           previous hops (e.g., some or all of A, B, and B' in Figure
           9), is performed.

      3.   (Re, Resv_Te) and Path_Te are passed to traffic control.
           Traffic control will compute the effective flowspec as the
           "minimum" of Path_Te and Resv_Te, in a service-dependent
           manner.

      Section 3.11.6 defines a generic set of service-specific calls to
      compare flowspecs, to compute the LUB and GLB of flowspecs, and to
      compare and sum Tspecs.

   2.3 Soft State

      RSVP takes a "soft state" approach to managing the reservation
      state in routers and hosts.  RSVP soft state is created and
      periodically refreshed by Path and Resv messages.  The state is
      deleted if no matching refresh messages arrive before the
      expiration of a "cleanup timeout" interval.  State may also be
      deleted by an explicit "teardown" message, described in the next
      section.  At the expiration of each "refresh timeout" period and
      after a state change, RSVP scans its state to build and forward
      Path and Resv refresh messages to succeeding hops.

      Path and Resv messages are idempotent.  When a route changes, the
      next Path message will initialize the path state on the new route,
      and future Resv messages will establish reservation state there;
      the state on the now-unused segment of the route will time out.
      Thus, whether a message is "new" or a "refresh" is determined
      separately at each node, depending upon the existence of state at
      that node.





Braden, Ed., et. al.        Standards Track                    [Page 22]

RFC 2205                          RSVP                    September 1997


      RSVP sends its messages as IP datagrams with no reliability
      enhancement.  Periodic transmission of refresh messages by hosts
      and routers is expected to handle the occasional loss of an RSVP
      message.  If the effective cleanup timeout is set to K times the
      refresh timeout period, then RSVP can tolerate K-1 successive RSVP
      packet losses without falsely deleting state.  The network traffic
      control mechanism should be statically configured to grant some
      minimal bandwidth for RSVP messages to protect them from
      congestion losses.

      The state maintained by RSVP is dynamic; to change the set of
      senders Si or to change any QoS request, a host simply starts
      sending revised Path and/or Resv messages.  The result will be an
      appropriate adjustment in the RSVP state in all nodes along the
      path; unused state will time out if it is not explicitly torn
      down.

      In steady state, state is refreshed hop-by-hop to allow merging.
      When the received state differs from the stored state, the stored
      state is updated.  If this update results in modification of state
      to be forwarded in refresh messages, these refresh messages must
      be generated and forwarded immediately, so that state changes can
      be propagated end-to-end without delay.  However, propagation of a
      change stops when and if it reaches a point where merging causes
      no resulting state change.  This minimizes RSVP control traffic
      due to changes and is essential for scaling to large multicast
      groups.

      State that is received through a particular interface I* should
      never be forwarded out the same interface.  Conversely, state that
      is forwarded out interface I* must be computed using only state
      that arrived on interfaces different from I*.  A trivial example
      of this rule is illustrated in Figure 10, which shows a transit
      router with one sender and one receiver on each interface (and
      assumes one next/previous hop per interface).  Interfaces (a) and
      (c) serve as both outgoing and incoming interfaces for this
      session.  Both receivers are making wildcard-style reservations,
      in which the Resv messages are forwarded to all previous hops for
      senders in the group, with the exception of the next hop from
      which they came.  The result is independent reservations in the
      two directions.

      There is an additional rule governing the forwarding of Resv
      messages: state from Resv messages received from outgoing
      interface Io should be forwarded to incoming interface Ii only if
      Path messages from Ii are forwarded to Io.





Braden, Ed., et. al.        Standards Track                    [Page 23]

RFC 2205                          RSVP                    September 1997


                         ________________
                      a |                | c
      ( R1, S1 ) <----->|     Router     |<-----> ( R2, S2 )
                        |________________|

             Send                |        Receive
                                 |
        WF( *{3B}) <-- (a)       |     (c) <-- WF( *{3B})
                                 |
             Receive             |          Send
                                 |
        WF( *{4B}) --> (a)       |     (c) --> WF( *{4B})
                                 |
             Reserve on (a)      |        Reserve on (c)
              __________         |        __________
             |  * {4B}  |        |       |   * {3B} |
             |__________|        |       |__________|
                                 |

                     Figure 10: Independent Reservations


   2.4 Teardown

      RSVP "teardown" messages remove path or reservation state
      immediately.  Although it is not necessary to explicitly tear down
      an old reservation, we recommend that all end hosts send a
      teardown request as soon as an application finishes.

      There are two types of RSVP teardown message, PathTear and
      ResvTear.  A PathTear message travels towards all receivers
      downstream from its point of initiation and deletes path state, as
      well as all dependent reservation state, along the way.  An
      ResvTear message deletes reservation state and travels towards all
      senders upstream from its point of initiation.  A PathTear
      (ResvTear) message may be conceptualized as a reversed-sense Path
      message (Resv message, respectively).

      A teardown request may be initiated either by an application in an
      end system (sender or receiver), or by a router as the result of
      state timeout or service preemption.  Once initiated, a teardown
      request must be forwarded hop-by-hop without delay.  A teardown
      message deletes the specified state in the node where it is
      received.  As always, this state change will be propagated
      immediately to the next node, but only if there will be a net
      change after merging.  As a result, a ResvTear message will prune
      the reservation state back (only) as far as possible.




Braden, Ed., et. al.        Standards Track                    [Page 24]

RFC 2205                          RSVP                    September 1997


      Like all other RSVP messages, teardown requests are not delivered
      reliably.  The loss of a teardown request message will not cause a
      protocol failure because the unused state will eventually time out
      even though it is not explicitly deleted.  If a teardown message
      is lost, the router that failed to receive that message will time
      out its state and initiate a new teardown message beyond the loss
      point.  Assuming that RSVP message loss probability is small, the
      longest time to delete state will seldom exceed one refresh
      timeout period.

      It should be possible to tear down any subset of the established
      state.  For path state, the granularity for teardown is a single
      sender.  For reservation state, the granularity is an individual
      filter spec.  For example, refer to Figure 7.  Receiver R1 could
      send a ResvTear message for sender S2 only (or for any subset of
      the filter spec list), leaving S1 in place.

      A ResvTear message specifies the style and filters; any flowspec
      is ignored.  Whatever flowspec is in place will be removed if all
      its filter specs are torn down.

   2.5 Errors

      There are two RSVP error messages, ResvErr and PathErr.  PathErr
      messages are very simple; they are simply sent upstream to the
      sender that created the error, and they do not change path state
      in the nodes though which they pass.  There are only a few
      possible causes of path errors.

      However, there are a number of ways for a syntactically valid
      reservation request to fail at some node along the path.  A node
      may also decide to preempt an established reservation.  The
      handling of ResvErr messages is somewhat complex (Section 3.5).
      Since a request that fails may be the result of merging a number
      of requests, a reservation error must be reported to all of the
      responsible receivers.  In addition, merging heterogeneous
      requests creates a potential difficulty known as the "killer
      reservation" problem, in which one request could deny service to
      another.  There are actually two killer-reservation problems.

      1.   The first killer reservation problem (KR-I) arises when there
           is already a reservation Q0 in place.  If another receiver
           now makes a larger reservation Q1 > Q0, the result of merging
           Q0 and Q1 may be rejected by admission control in some
           upstream node.  This must not deny service to Q0.






Braden, Ed., et. al.        Standards Track                    [Page 25]

RFC 2205                          RSVP                    September 1997


           The solution to this problem is simple: when admission
           control fails for a reservation request, any existing
           reservation is left in place.

      2.   The second killer reservation problem (KR-II) is the
           converse: the receiver making a reservation Q1 is persistent
           even though Admission Control is failing for Q1 in some node.
           This must not prevent a different receiver from now
           establishing a smaller reservation Q0 that would succeed if
           not merged with Q1.

           To solve this problem, a ResvErr message establishes
           additional state, called "blockade state", in each node
           through which it passes.  Blockade state in a node modifies
           the merging procedure to omit the offending flowspec (Q1 in
           the example) from the merge, allowing a smaller request to be
           forwarded and established.  The Q1 reservation state is said
           to be "blockaded".  Detailed rules are presented in Section
           3.5.

      A reservation request that fails Admission Control creates
      blockade state but is left in place in nodes downstream of the
      failure point.  It has been suggested that these reservations
      downstream from the failure represent "wasted" reservations and
      should be timed out if not actively deleted.  However, the
      downstream reservations are left in place, for the following
      reasons:

      o    There are two possible reasons for a receiver persisting in a
           failed reservation: (1) it is polling for resource
           availability along the entire path, or (2) it wants to obtain
           the desired QoS along as much of the path as possible.
           Certainly in the second case, and perhaps in the first case,
           the receiver will want to hold onto the reservations it has
           made downstream from the failure.

      o    If these downstream reservations were not retained, the
           responsiveness of RSVP to certain transient failures would be
           impaired.  For example, suppose a route "flaps" to an
           alternate route that is congested, so an existing reservation
           suddenly fails, then quickly recovers to the original route.
           The blockade state in each downstream router must not remove
           the state or prevent its immediate refresh.

      o    If we did not refresh the downstream reservations, they might
           time out, to be restored every Tb seconds (where Tb is the
           blockade state timeout interval).  Such intermittent behavior
           might be very distressing for users.



Braden, Ed., et. al.        Standards Track                    [Page 26]

RFC 2205                          RSVP                    September 1997


   2.6 Confirmation

      To request a confirmation for its reservation request, a receiver
      Rj includes in the Resv message a confirmation-request object
      containing Rj's IP address.  At each merge point, only the largest
      flowspec and any accompanying confirmation-request object is
      forwarded upstream.  If the reservation request from Rj is equal
      to or smaller than the reservation in place on a node, its Resv is
      not forwarded further, and if the Resv included a confirmation-
      request object, a ResvConf message is sent back to Rj.  If the
      confirmation request is forwarded, it is forwarded immediately,
      and no more than once for each request.

      This confirmation mechanism has the following consequences:

      o    A new reservation request with a flowspec larger than any in
           place for a session will normally result in either a ResvErr
           or a ResvConf message back to the receiver from each sender.
           In this case, the ResvConf message will be an end-to-end
           confirmation.

      o    The receipt of a ResvConf gives no guarantees.  Assume the
           first two reservation requests from receivers R1 and R2
           arrive at the node where they are merged.  R2, whose
           reservation was the second to arrive at that node, may
           receive a ResvConf from that node while R1's request has not
           yet propagated all the way to a matching sender and may still
           fail.  Thus, R2 may receive a ResvConf although there is no
           end-to-end reservation in place; furthermore, R2 may receive
           a ResvConf followed by a ResvErr.


   2.7 Policy Control

      RSVP-mediated QoS requests allow particular user(s) to obtain
      preferential access to network resources.  To prevent abuse, some
      form of back pressure will generally be required on users who make
      reservations.  For example, such back pressure may be accomplished
      by administrative access policies, or it may depend upon some form
      of user feedback such as real or virtual billing for the "cost" of
      a reservation.  In any case, reliable user identification and
      selective admission will generally be needed when a reservation is
      requested.

      The term "policy control" is used for the mechanisms required to
      support access policies and back pressure for RSVP reservations.
      When a new reservation is requested, each node must answer two
      questions: "Are enough resources available to meet this request?"



Braden, Ed., et. al.        Standards Track                    [Page 27]

RFC 2205                          RSVP                    September 1997


      and "Is this user allowed to make this reservation?"  These two
      decisions are termed the "admission control" decision and the
      "policy control" decision, respectively, and both must be
      favorable in order for RSVP to make a reservation.  Different
      administrative domains in the Internet may have different
      reservation policies.

      The input to policy control is referred to as "policy data", which
      RSVP carries in POLICY_DATA objects.  Policy data may include
      credentials identifying users or user classes, account numbers,
      limits, quotas, etc.  Like flowspecs, policy data is opaque to
      RSVP, which simply passes it to policy control when required.
      Similarly, merging of policy data must be done by the policy
      control mechanism rather than by RSVP itself.  Note that the merge
      points for policy data are likely to be at the boundaries of
      administrative domains.  It may therefore be necessary to carry
      accumulated and unmerged policy data upstream through multiple
      nodes before reaching one of these merge points.

      Carrying user-provided policy data in Resv messages presents a
      potential scaling problem.  When a multicast group has a large
      number of receivers, it will be impossible or undesirable to carry
      all receivers' policy data upstream.  The policy data will have to
      be administratively merged at places near the receivers, to avoid
      excessive policy data.  Further discussion of these issues and an
      example of a policy control scheme will be found in [PolArch96].
      Specifications for the format of policy data objects and RSVP
      processing rules for them are under development.

   2.8 Security

      RSVP raises the following security issues.

      o    Message integrity and node authentication

           Corrupted or spoofed reservation requests could lead to theft
           of service by unauthorized parties or to denial of service
           caused by locking up network resources.  RSVP protects
           against such attacks with a hop-by-hop authentication
           mechanism using an encrypted hash function.  The mechanism is
           supported by INTEGRITY objects that may appear in any RSVP
           message.  These objects use a keyed cryptographic digest
           technique, which assumes that RSVP neighbors share a secret.
           Although this mechanism is part of the base RSVP
           specification, it is described in a companion document
           [Baker96].





Braden, Ed., et. al.        Standards Track                    [Page 28]

RFC 2205                          RSVP                    September 1997


           Widespread use of the RSVP integrity mechanism will require
           the availability of the long-sought key management and
           distribution infrastructure for routers.  Until that
           infrastructure becomes available, manual key management will
           be required to secure RSVP message integrity.

      o    User authentication

           Policy control will depend upon positive authentication of
           the user responsible for each reservation request.  Policy
           data may therefore include cryptographically protected user
           certificates.  Specification of such certificates is a future
           issue.

           Even without globally-verifiable user certificates, it may be
           possible to provide practical user authentication in many
           cases by establishing a chain of trust, using the hop-by-hop
           INTEGRITY mechanism described earlier.

      o    Secure data streams

           The first two security issues concerned RSVP's operation.  A
           third security issue concerns resource reservations for
           secure data streams.  In particular, the use of IPSEC (IP
           Security) in the data stream poses a problem for RSVP:  if
           the transport and higher level headers are encrypted, RSVP's
           generalized port numbers cannot be used to define a session
           or a sender.

           To solve this problem, an RSVP extension has been defined in
           which the security association identifier (IPSEC SPI) plays a
           role roughly equivalent to the generalized ports [RFC 2207].

   2.9 Non-RSVP Clouds

      It is impossible to deploy RSVP (or any new protocol) at the same
      moment throughout the entire Internet.  Furthermore, RSVP may
      never be deployed everywhere.  RSVP must therefore provide correct
      protocol operation even when two RSVP-capable routers are joined
      by an arbitrary "cloud" of non-RSVP routers.  Of course, an
      intermediate cloud that does not support RSVP is unable to perform
      resource reservation.  However, if such a cloud has sufficient
      capacity, it may still provide useful realtime service.

      RSVP is designed to operate correctly through such a non-RSVP
      cloud.  Both RSVP and non-RSVP routers forward Path messages
      towards the destination address using their local uni-/multicast
      routing table.  Therefore, the routing of Path messages will be



Braden, Ed., et. al.        Standards Track                    [Page 29]

RFC 2205                          RSVP                    September 1997


      unaffected by non-RSVP routers in the path.  When a Path message
      traverses a non-RSVP cloud, it carries to the next RSVP-capable
      node the IP address of the last RSVP-capable router before
      entering the cloud.  An Resv message is then forwarded directly to
      the next RSVP-capable router on the path(s) back towards the
      source.

      Even though RSVP operates correctly through a non-RSVP cloud, the
      non-RSVP-capable nodes will in general perturb the QoS provided to
      a receiver.  Therefore, RSVP passes a `NonRSVP' flag bit to the
      local traffic control mechanism when there are non-RSVP-capable
      hops in the path to a given sender.  Traffic control combines this
      flag bit with its own sources of information, and forwards the
      composed information on integrated service capability along the
      path to receivers using Adspecs [RFC 2210].

      Some topologies of RSVP routers and non-RSVP routers can cause
      Resv messages to arrive at the wrong RSVP-capable node, or to
      arrive at the wrong interface of the correct node.  An RSVP
      process must be prepared to handle either situation.  If the
      destination address does not match any local interface and the
      message is not a Path or PathTear, the message must be forwarded
      without further processing by this node.  To handle the wrong
      interface case, a "Logical Interface Handle" (LIH) is used.  The
      previous hop information included in a Path message includes not
      only the IP address of the previous node but also an LIH defining
      the logical outgoing interface; both values are stored in the path
      state.  A Resv message arriving at the addressed node carries both
      the IP address and the LIH of the correct outgoing interface, i.e,
      the interface that should receive the requested reservation,
      regardless of which interface it arrives on.

      The LIH may also be useful when RSVP reservations are made over a
      complex link layer, to map between IP layer and link layer flow
      entities.

   2.10 Host Model

      Before a session can be created, the session identification
      (DestAddress, ProtocolId [, DstPort]) must be assigned and
      communicated to all the senders and receivers by some out-of-band
      mechanism.  When an RSVP session is being set up, the following
      events happen at the end systems.








Braden, Ed., et. al.        Standards Track                    [Page 30]

RFC 2205                          RSVP                    September 1997


      H1   A receiver joins the multicast group specified by
           DestAddress, using IGMP.

      H2   A potential sender starts sending RSVP Path messages to the
           DestAddress.

      H3   A receiver application receives a Path message.

      H4   A receiver starts sending appropriate Resv messages,
           specifying the desired flow descriptors.

      H5   A sender application receives a Resv message.

      H6   A sender starts sending data packets.

      There are several synchronization considerations.

      o    H1 and H2 may happen in either order.

      o    Suppose that a new sender starts sending data (H6) but there
           are no multicast routes because no receivers have joined the
           group (H1).  Then the data will be dropped at some router
           node (which node depends upon the routing protocol) until
           receivers(s) appear.

      o    Suppose that a new sender starts sending Path messages (H2)
           and data (H6) simultaneously, and there are receivers but no
           Resv messages have reached the sender yet (e.g., because its
           Path messages have not yet propagated to the receiver(s)).
           Then the initial data may arrive at receivers without the
           desired QoS.  The sender could mitigate this problem by
           awaiting arrival of the first Resv message (H5); however,
           receivers that are farther away may not have reservations in
           place yet.

      o    If a receiver starts sending Resv messages (H4) before
           receiving any Path messages (H3), RSVP will return error
           messages to the receiver.

           The receiver may simply choose to ignore such error messages,
           or it may avoid them by waiting for Path messages before
           sending Resv messages.

      A specific application program interface (API) for RSVP is not
      defined in this protocol spec, as it may be host system dependent.
      However, Section 3.11.1 discusses the general requirements and
      outlines a generic interface.




Braden, Ed., et. al.        Standards Track                    [Page 31]

RFC 2205                          RSVP                    September 1997


3. RSVP Functional Specification

   3.1 RSVP Message Formats

      An RSVP message consists of a common header, followed by a body
      consisting of a variable number of variable-length, typed
      "objects".  The following subsections define the formats of the
      common header, the standard object header, and each of the RSVP
      message types.

      For each RSVP message type, there is a set of rules for the
      permissible choice of object types.  These rules are specified
      using Backus-Naur Form (BNF) augmented with square brackets
      surrounding optional sub-sequences.  The BNF implies an order for
      the objects in a message.  However, in many (but not all) cases,
      object order makes no logical difference.  An implementation
      should create messages with the objects in the order shown here,
      but accept the objects in any permissible order.

      3.1.1 Common Header

                0             1              2             3
         +-------------+-------------+-------------+-------------+
         | Vers | Flags|  Msg Type   |       RSVP Checksum       |
         +-------------+-------------+-------------+-------------+
         |  Send_TTL   | (Reserved)  |        RSVP Length        |
         +-------------+-------------+-------------+-------------+



         The fields in the common header are as follows:

         Vers: 4 bits

              Protocol version number.  This is version 1.

         Flags: 4 bits

              0x01-0x08: Reserved

                   No flag bits are defined yet.

         Msg Type: 8 bits

              1 = Path

              2 = Resv




Braden, Ed., et. al.        Standards Track                    [Page 32]

RFC 2205                          RSVP                    September 1997


              3 = PathErr

              4 = ResvErr

              5 = PathTear

              6 = ResvTear

              7 = ResvConf

         RSVP Checksum: 16 bits

              The one's complement of the one's complement sum of the
              message, with the checksum field replaced by zero for the
              purpose of computing the checksum.  An all-zero value
              means that no checksum was transmitted.

         Send_TTL: 8 bits

              The IP TTL value with which the message was sent.  See
              Section 3.8.

         RSVP Length: 16 bits

              The total length of this RSVP message in bytes, including
              the common header and the variable-length objects that
              follow.

      3.1.2 Object Formats

         Every object consists of one or more 32-bit words with a one-
         word header, with the following format:

                0             1              2             3
         +-------------+-------------+-------------+-------------+
         |       Length (bytes)      |  Class-Num  |   C-Type    |
         +-------------+-------------+-------------+-------------+
         |                                                       |
         //                  (Object contents)                   //
         |                                                       |
         +-------------+-------------+-------------+-------------+










Braden, Ed., et. al.        Standards Track                    [Page 33]

RFC 2205                          RSVP                    September 1997


         An object header has the following fields:

         Length

              A 16-bit field containing the total object length in
              bytes.  Must always be a multiple of 4, and at least 4.

         Class-Num

              Identifies the object class; values of this field are
              defined in Appendix A.  Each object class has a name,
              which is always capitalized in this document.  An RSVP
              implementation must recognize the following classes:

              NULL

                   A NULL object has a Class-Num of zero, and its C-Type
                   is ignored.  Its length must be at least 4, but can
                   be any multiple of 4.  A NULL object may appear
                   anywhere in a sequence of objects, and its contents
                   will be ignored by the receiver.

              SESSION

                   Contains the IP destination address (DestAddress),
                   the IP protocol id, and some form of generalized
                   destination port, to define a specific session for
                   the other objects that follow.  Required in every
                   RSVP message.

              RSVP_HOP

                   Carries the IP address of the RSVP-capable node that
                   sent this message and a logical outgoing interface
                   handle (LIH; see Section 3.3).  This document refers
                   to a RSVP_HOP object as a PHOP ("previous hop")
                   object for downstream messages or as a NHOP (" next
                   hop") object for upstream messages.

              TIME_VALUES

                   Contains the value for the refresh period R used by
                   the creator of the message; see Section 3.7.
                   Required in every Path and Resv message.







Braden, Ed., et. al.        Standards Track                    [Page 34]

RFC 2205                          RSVP                    September 1997


              STYLE

                   Defines the reservation style plus style-specific
                   information that is not in FLOWSPEC or FILTER_SPEC
                   objects.  Required in every Resv message.

              FLOWSPEC

                   Defines a desired QoS, in a Resv message.

              FILTER_SPEC

                   Defines a subset of session data packets that should
                   receive the desired QoS (specified by a FLOWSPEC
                   object), in a Resv message.

              SENDER_TEMPLATE

                   Contains a sender IP address and perhaps some
                   additional demultiplexing information to identify a
                   sender.  Required in a Path message.

              SENDER_TSPEC

                   Defines the traffic characteristics of a sender's
                   data flow.  Required in a Path message.

              ADSPEC

                   Carries OPWA data, in a Path message.

              ERROR_SPEC

                   Specifies an error in a PathErr, ResvErr, or a
                   confirmation in a ResvConf message.

              POLICY_DATA

                   Carries information that will allow a local policy
                   module to decide whether an associated reservation is
                   administratively permitted.  May appear in Path,
                   Resv, PathErr, or ResvErr message.

                   The use of POLICY_DATA objects is not fully specified
                   at this time; a future document will fill this gap.






Braden, Ed., et. al.        Standards Track                    [Page 35]

RFC 2205                          RSVP                    September 1997


              INTEGRITY

                   Carries cryptographic data to authenticate the
                   originating node and to verify the contents of this
                   RSVP message.  The use of the INTEGRITY object is
                   described in [Baker96].

              SCOPE

                   Carries an explicit list of sender hosts towards
                   which the information in the message is to be
                   forwarded.  May appear in a Resv, ResvErr, or
                   ResvTear message.  See Section 3.4.

              RESV_CONFIRM

                   Carries the IP address of a receiver that requested a
                   confirmation.  May appear in a Resv or ResvConf
                   message.

         C-Type

              Object type, unique within Class-Num.  Values are defined
              in Appendix A.

         The maximum object content length is 65528 bytes.  The Class-
         Num and C-Type fields may be used together as a 16-bit number
         to define a unique type for each object.

         The high-order two bits of the Class-Num is used to determine
         what action a node should take if it does not recognize the
         Class-Num of an object; see Section 3.10.

      3.1.3 Path Messages

         Each sender host periodically sends a Path message for each
         data flow it originates.  It contains a SENDER_TEMPLATE object
         defining the format of the data packets and a SENDER_TSPEC
         object specifying the traffic characteristics of the flow.
         Optionally, it may contain may be an ADSPEC object carrying
         advertising (OPWA) data for the flow.

         A Path message travels from a sender to receiver(s) along the
         same path(s) used by the data packets.  The IP source address
         of a Path message must be an address of the sender it
         describes, while the destination address must be the
         DestAddress for the session.  These addresses assure that the
         message will be correctly routed through a non-RSVP cloud.



Braden, Ed., et. al.        Standards Track                    [Page 36]

RFC 2205                          RSVP                    September 1997


         The format of a Path message is as follows:

            ::=  [  ]

                                      

                                     

                                    [  ... ]

                                    [  ]

            ::=  

                                    [  ]


         If the INTEGRITY object is present, it must immediately follow
         the common header.  There are no other requirements on
         transmission order, although the above order is recommended.
         Any number of POLICY_DATA objects may appear.

         The PHOP (i.e., RSVP_HOP) object of each Path message contains
         the previous hop address, i.e., the IP address of the interface
         through which the Path message was most recently sent.  It also
         carries a logical interface handle (LIH).

         Each RSVP-capable node along the path(s) captures a Path
         message and processes it to create path state for the sender
         defined by the SENDER_TEMPLATE and SESSION objects.  Any
         POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in
         the path state.  If an error is encountered while processing a
         Path message, a PathErr message is sent to the originating
         sender of the Path message.  Path messages must satisfy the
         rules on SrcPort and DstPort in Section 3.2.

         Periodically, the RSVP process at a node scans the path state
         to create new Path messages to forward towards the receiver(s).
         Each message contains a sender descriptor defining one sender,
         and carries the original sender's IP address as its IP source
         address.  Path messages eventually reach the applications on
         all receivers; however, they are not looped back to a receiver
         running in the same application process as the sender.

         The RSVP process forwards Path messages and replicates them as
         required by multicast sessions, using routing information it
         obtains from the appropriate uni-/multicast routing process.
         The route depends upon the session DestAddress, and for some



Braden, Ed., et. al.        Standards Track                    [Page 37]

RFC 2205                          RSVP                    September 1997


         routing protocols also upon the source (sender's IP) address.
         The routing information generally includes the list of zero or
         more outgoing interfaces to which the Path message is to be
         forwarded.  Because each outgoing interface has a different IP
         address, the Path messages sent out different interfaces
         contain different PHOP addresses.  In addition, ADSPEC objects
         carried in Path messages will also generally differ for
         different outgoing interfaces.

         Path state for a given session and sender may not necessarily
         have a unique PHOP or unique incoming interface.  There are two
         cases, corresponding to multicast and unicast sessions.

         o    Multicast Sessions

              Multicast routing allows a stable distribution tree in
              which Path messages from the same sender arrive from more
              than one PHOP, and RSVP must be prepared to maintain all
              such path state.  The RSVP rules for handling this
              situation are contained in Section 3.9.  RSVP must not
              forward (according to the rules of Section 3.9) Path
              messages that arrive on an incoming interface different
              from that provided by routing.

         o    Unicast Sessions

              For a short period following a unicast route change
              upstream, a node may receive Path messages from multiple
              PHOPs for a given (session, sender) pair.  The node cannot
              reliably determine which is the right PHOP, although the
              node will receive data from only one of the PHOPs at a
              time.  One implementation choice for RSVP is to ignore
              PHOP in matching unicast past state, and allow the PHOP to
              flip among the candidates.  Another implementation choice
              is to maintain path state for each PHOP and to send Resv
              messages upstream towards all such PHOPs.  In either case,
              the situation is a transient; the unused path state will
              time out or be torn down (because upstream path state
              timed out).

      3.1.4 Resv Messages

         Resv messages carry reservation requests hop-by-hop from
         receivers to senders, along the reverse paths of data flows for
         the session.  The IP destination address of a Resv message is
         the unicast address of a previous-hop node, obtained from the
         path state.  The IP source address is an address of the node
         that sent the message.



Braden, Ed., et. al.        Standards Track                    [Page 38]

RFC 2205                          RSVP                    September 1997


         The Resv message format is as follows:

            ::=  [  ]

                                     

                                   

                                   [  ]  [  ]

                                   [  ... ]