[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 03 04 05 06 07 08 09 10 11 12 13 14 15 RFC 2205

Internet Draft                                                  L. Zhang
Expires: January 1995                                               PARC
File: draft-ietf-rsvp-spec-03.txt                              R. Braden
                                                               D. Estrin
                                                               S. Herzog
                                                                S. Jamin

                Resource ReSerVation Protocol (RSVP) --

                   Version 1 Functional Specification

Status of Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific


   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.

Zhang, Braden et al      Expires: January 1995                  [Page 1]

Internet Draft             RSVP Specification                  July 1994

What's Changed Since Seattle IETF

   o    Redesign generic RSVP API (section 3.6.2)

   o    Change encoding of style in RESV messages (section 3.1.2)

   o    Clarify filterspec functions (section 2.1)

   o    Simplify definition of DF style (sections 2.2, 2.4).

   o    Revise discussion of flowspec merging (section 2.3.3).

   o    Change format of variable-length filterspecs and flowspecs
        (section 3.1 and 3.6.1).

   o    Add a user authentication field in all RSVP messages (Section

   o    Add short discussion of local repair (Section 3.3.3).

   o    Editorial nits.

1. Introduction

   This memo describes RSVP, a resource reservation setup protocol
   designed for an integrated services Internet [RSVP93,ISInt93].  An
   application invokes RSVP to request a specific quality of service
   (QoS) for a data stream.  Hosts and routers use RSVP to deliver these
   requests to the routers along the path(s) of the data stream and to
   maintain router and host state to provide the requested service.
   This generally requires reserving resources in those nodes.

   At each "node" (i.e., router or host) along the path, RSVP passes a
   new resource reservation request to an admission control routine, to
   determine whether there are sufficient resources available.  If there
   are, the node reserves the resources and updates its packet scheduler
   and classifier control parameters to provide the requested QoS
   [ISInt93].  It is expected that RSVP implementations will execute in
   user space in a host, and in background in a router.  On the other
   hand, the packet scheduler and classifier are expected to execute in
   the kernel of a host operating system, and in the high-speed packet
   forwarding path of a router.

   RSVP messages are sent as IP datagrams; thus, RSVP occupies the place
   of a transport protocol in the protocol stack.  However, like ICMP,
   IGMP, and routing protocols, RSVP is really an Internet control

Zhang, Braden et al      Expires: January 1995                  [Page 2]

Internet Draft             RSVP Specification                  July 1994

   protocol; it does not carry any application data, and its messages
   are processed by the routers in the path.

   RSVP is not itself a routing protocol, but rather it is designed to
   operate with existing and future unicast and multicast routing
   protocols.  Thus, a host sends IGMP messages to join a multicast
   group, and then it sends RSVP messages to reserve resources along the
   deliver path(s) from that group.  Unlike a routing protocol, RSVP is
   explicitly invoked by applications, to obtain a special QoS.

   The objectives and general justification for RSVP design are
   presented in [RSVP93,ISInt93].  In summary, RSVP has the following

   o    RSVP supports multicast or unicast data delivery and adapts to
        changing group membership as well as changing routes.

   o    RSVP reserves resources for simplex data streams.

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

   o    RSVP maintains "soft state" in the routers, enabling it to
        gracefully support dynamic membership changes and automatically
        adapt to routing changes.

   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.

   The RSVP protocol mechanisms provide a general facility for creating
   and maintaining distributed reservation state across a mesh of
   multicast delivery paths.  These mechanisms treat the reservation
   parameters as opaque data, except for certain well-defined
   operations, and simply pass them to the traffic control modules
   (admission control, packet scheduler, and classifier) for
   interpretation.  Although the RSVP protocol mechanisms are largely
   independent of the encoding of these parameters, the encodings must
   be defined in the reservation model that is presented to an
   application (see section 3.6.1).

   In order to efficiently accommodate heterogeneous receivers and
   dynamic group membership, RSVP makes the receivers responsible for
   requesting resource reservations [RSVP93].  Each receiver can request
   a reservation that is tailored to its particular requirement, and

Zhang, Braden et al      Expires: January 1995                  [Page 3]

Internet Draft             RSVP Specification                  July 1994

   RSVP will deliver this request to the routers along the reverse
   path(s) to the sender(s).

   There are two aspects to RSVP, its reservation model and its protocol
   mechanisms.  Sections 2.1 and 2.2 of this memo summarize the RSVP
   reservation model, while Sections 2.3 describes the protocol
   mechanisms.  Sections 2.4 gives examples of both model and mechanism,
   and Section 2.5 summarizes the model of RSVP seen by a host.  Section
   3 presents the functional specification for RSVP.

2. RSVP Overview

   2.1 RSVP Reservation Model

      Figure 1 illustrates a single multicast distribution session.  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 the multicast routing protocol.  Multicast distribution
      forwards a copy of each data packet from a sender Si to every
      receiver Rj.  Each sender Si and receiver Rj may correspond to a
      unique Internet host, or there may be multiple logical senders
      (e.g., multiple TV cameras) and/or receivers in a single host.

      RSVP reserves resources for simplex data streams, i.e., it
      reserves resources in only one direction on a link, so that a
      sender is logically distinct from a receiver.  However, the same
      application may act as both sender and receiver.

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

                   Figure 1: Multicast Distribution Session

      All data packets in a given session are addressed to the same IP
      destination address DestAddress.  For multicast delivery,
      DestAddress is the multicast group address to which the data is
      addressed.  For unicast delivery, DestAddress is simply the
      unicast address of the single receiver.  RSVP identifies a session
      by DestAddress plus a 32-bit stream identifier called the

Zhang, Braden et al      Expires: January 1995                  [Page 4]

Internet Draft             RSVP Specification                  July 1994

      "reservation id" (ResvID).  We use the term "session socket" for
      the (DestAddress, ResvID) pair that defines a session.  RSVP
      treats each session independently.  In the rest of this document,
      a particular session (hence, session socket) is always implied
      even if not stated.

      Depending upon the reservation style and the session state already
      in place, a new or modified reservation request may or may not
      result in a call to admission control at each node [ISInt93].  If
      an admission control call fails, the reservation is rejected and
      an RSVP error message is sent to the receiver(s) responsible for

      A single RSVP resource reservation request is defined by a
      "flowspec" together with a "filterspec"; this pair is called a
      "Flow Descriptor".  The flowspec specifies the desired QoS in a
      quantitative manner, e.g., the tolerable delay, the average
      throughput, the maximum burstiness, etc [Partridge92, ISInt93,
      IServ93]; it is used to set parameters to the packet scheduling
      mechanism in the node (router or host).  The filterspec (plus the
      DestAddress) defines the set of data packets to receive this
      service; it is used to set parameters in the packet classifier
      component of the node.  For all packets that are addressed to a
      particular session, only those that can match the filter spec(s)
      of that session will be forwarded according to the flowspec; the
      rest will be either dropped or sent as best-effort traffic.

      More specifically, a filterspec may have two distinct functions.

      o    Sender Selection

           A filterspec may select packets that originate from a
           particular sender Si, from the entire stream of packets
           destined to a given DestAddress.  The sender is selected
           using its IP source address and optionally a "generalized
           source port", i.e., multiplexing field(s) at the transport
           layer (e.g., a UDP destination port) and/or the application
           layer (e.g., a particular subset of a hierarchically encoded
           video stream).

      o    Receiver Sub-selection

           A filterspec may distinguish different sessions with the same
           DestAddress by selecting a subset of the packets destined to
           that address.  This subset is defined by a "generalized
           destination port", which again may include transport-layer
           (e.g., UDP destination port) and/or application-layer
           demultiplexing information.  An RSVP receiver Rj is defined

Zhang, Braden et al      Expires: January 1995                  [Page 5]

Internet Draft             RSVP Specification                  July 1994

           by the pair (Hj, Pj), where Hj is the IP host address and Pj
           is the generalized destination port.

      RSVP needs to distinguish different sessions.  It is difficult to
      do this by matching generalized destination ports buried within
      the filterspecs, since the part of the filterspec that defines the
      generalized destination port should be opaque to an RSVP module in
      a router, which does not not know the structure of transport or
      application layer protocol headers.  Therefore, RSVP identifies a
      session by the pair (DestAddress, ResvID), where the ResvID's form
      a simple space of identifiers that RSVP can use to distinguish
      different sessions with the same DestAddress.  The ResvID's need
      not themselves be (generalized) ports, but the the ResvID values
      that are used must have a one-to-one correspondence with the
      generalized ports in use for the given DestAddress.

      All reservation requests for a given session must use filterspecs
      that specify the same DestAddress and the same generalized
      destination port (since receivers of the same substream,
      downstream of a given node, must share a common resource
      reservation in that node).

   2.2 Reservation Styles

      In addition to the Flow Descriptors, each RSVP reservation request
      specifies a "reservation style".  The following reservation styles
      have been defined so far.

      1.   Wildcard-Filter (WF) Style

           A Wildcard-Filter (WF) style reservation creates a single
           resource "pipe" along each link, shared by data packets from
           all senders for the given session.  The "size" of this pipe
           is the largest of the resource requests for that link from
           all receivers, independent of the number of senders using it.
           (The concept of a "largest" flowspec is discussed later).

           The term "wildcard" implies a filterspec that selects all
           senders.  A WF reservation automatically extends to new
           senders to the session, as they appear.

      2.   Fixed-Filter (FF) Style

           A Fixed-Filter (FF) style reservation request creates
           reservation(s) for data packets from particular sender(s).  A
           FF reservation request from a particular receiver Rj contains
           a list of one or more Flow Descriptors, each consisting of a
           filterspec, which specifies some sender Si, and a

Zhang, Braden et al      Expires: January 1995                  [Page 6]

Internet Draft             RSVP Specification                  July 1994

           corresponding flowspec.

           FF reservations requested by different receivers Rj but
           selecting the same sender Si must necessarily share a single
           reservation in a given node.  This is simply the result of
           multicast distribution, which creates a single stream of data
           packets in a particular router from any Si, regardless of the
           number of receivers downstream.  The reservation for Si will
           be the maximum of the individual flowspecs from different
           downstream receivers Rj (see Section 2.3.3).

           FF reservations for different senders are distinct; they do
           NOT share a common pipe.  The total reservation on a link for
           a given session is therefore the cumulative total of the
           reservations for each requested sender.  A receiver that has
           established a FF style reservation may modify, add, or delete
           a flow descriptor at any time.  However, any additional or
           modified reservations are subject to admission control and
           may fail.

      3.   Dynamic-Filter (DF) Style

           A Dynamic-Filter (DF) style reservation decouples
           reservations from filters.  Each DF reservation request
           specifies a number D of distinct reservations to be made
           using the same specified flowspec.  The number of
           reservations that are actually made in a particular node is
           D' = min(D,Ns), where Ns is the total number of senders
           upstream of the node.

           In addition to D and the flowspec, a DF style reservation may
           also specify a list of K filterspecs, for some K in the
           range: 0 <= K <= D'.  These filterspecs define particular
           senders to use the D' reservations.  Once a DF reservation
           has been established, the receiver may change the set of
           filterspecs to specify a different selection of senders,
           without a new admission control check (assuming D' and the
           common flowspec remain unchanged).  This is known as "channel
           switching", in analogy with a television set.

           In order to provide assured channel switching, each node
           along the path must reserve enough bandwidth for all D'
           channels, even though some of this bandwidth may be unused at
           any one time.  If D' changes (because the receiver changed D
           or because the number Ns of upstream sources changed), or if
           the common flowspec changes, the refresh message is treated
           as a new reservation that is subject to admission control and

Zhang, Braden et al      Expires: January 1995                  [Page 7]

Internet Draft             RSVP Specification                  July 1994

           may fail.

           Like a FF style request, a DF style request causes distinct
           reservations for different senders.

           As noted earlier, those data packets from senders that are
           not currently selected may either be dropped or sent best-

      WF reservations are appropriate for those multicast applications
      whose application-level constraints prohibit all data sources from
      transmitting simultaneously; one example is audio conferencing,
      where a limited number of people talk at once.  Thus, each
      receiver might issue a WF reservation request for twice one audio
      channel (to allow some over-speaking).  On the other hand, the FF
      and DF styles create independent reservations for the flows from
      different senders; this is required for video signals, whose
      `silence' periods, if any, are uncoordinated among different

      The essential difference between the FF and DF styles is that the
      DF style allows a receiver to switch channels without danger of an
      admission denial due to limited resources (unless a topology
      change reroutes traffic along a lower-capacity path or new senders
      appear), once the initial reservations have been made.

      Other reservation styles may be defined in the future.

   2.3 RSVP Protocol Mechanisms

      2.3.1 RSVP Messages

         Each receiver host sends RSVP reservation (RESV) messages into
         the Internet, carrying Flow Descriptors requesting the desired
         reservation; see Figure 2.  These reservation messages must
         follow the reverse of the routes the data packets will use, all
         the way upstream to all the senders.  If a reservation request
         fails at any node, an RSVP error message is returned to the
         receiver; however, RSVP sends no positive acknowledgment
         messages to indicate success.  RESV messages are finally
         delivered to the sender hosts, so that the hosts can set up
         appropriate traffic control parameters for the first hop.

Zhang, Braden et al      Expires: January 1995                  [Page 8]

Internet Draft             RSVP Specification                  July 1994

               Sender                                       Receiver
                  Path -->  (                     )
                Si =======> (    Multicast        ) Path -->
                  <-- Resv  (                     ) =========> Rj
                            (    distribution     ) <-- Resv

                             Figure 2: RSVP Messages

         Each sender transmits RSVP PATH messages forward along the
         uni-/multicast routes provided by the routing protocol(s).
         These "Path" messages store path state in all the intermediate

         The path state is currently used by RSVP to route the RESV
         messages in the reverse direction from each receiver to all
         selected senders for a given session.  In the future, this
         function may be assumed by routing protocols.  PATH messages
         have other functions; they carry the following additional

         o    A sender template, which describes the format of data
              packets that the sender will originate.

              The sender template takes the form of two bitstrings
              forming a (value, mask) pair.  Zero mask bits represent
              "don't care" (variable) bits in data packets.  If present,
              this template is used by RSVP to match the filterspecs in
              a RESV message.  Without such a template in the path
              state, there will be no feedback (except poor service) to
              the receiver that sets an impossible filter by mistake.


                 Should sender templates be defined to be precisely
                 filterspecs, or should templates and filterspecs be
                 allowed to use different syntax?

         o    A flowspec defining an upper bound on the traffic that
              will be generated.

              This flowspec can be used by RSVP to prevent over-
              reservation on the non-shared links starting at the

Zhang, Braden et al      Expires: January 1995                  [Page 9]

Internet Draft             RSVP Specification                  July 1994

         A (template, flowspec) pair in a PATH message is called a
         Sender Descriptor.

      2.3.2 Soft State

         To maintain reservation state, RSVP keeps "soft state" in
         router and host nodes.  RSVP soft state is created and
         periodically refreshed by PATH and RESV messages, and it can be
         removed at each node by explicit "Teardown" messages.  RSVP
         also has a timer-driven cleanup procedure if no message is
         received within a cleanup timeout interval.

         When the route changes, the next PATH message will initialize
         the path state on the new route, and future RESV messages will
         establish reservation state while the state on the now-unused
         segment of the route times 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.  (This
         document will use the term "refresh message" in this effective
         sense, to indicate an RSVP message that does not modify the
         existing state at the node in question.)

         RSVP sends all its messages as IP datagrams without any
         reliability enhancement.  Periodic transmission of refresh
         messages by hosts and routers is expected to replace any lost
         RSVP messages.  However, the traffic control mechanism should
         be statically configured to grant high-reliability service to
         RSVP messages, to protect RSVP messages from severe congestion.

         If the set of senders Si or receivers Rj changes, or if any of
         the receivers' reservation requests change, the RSVP state is
         adjusted accordingly.   RSVP believes the latest PATH and RESV
         messages (ignoring the possibility of reordering).  To modify a
         reservation, a receiver simply starts sending the new values.
         It is not necessary (although it may sometimes be desirable,
         when the resources being consumed are "valuable"), to tear down
         the old reservation explicitly.

         When a RESV message is received at a router or sender host, the
         RSVP module checks whether the message is a new or a modified
         reservation request, or whether it simply refreshes an existing
         reservation.  A new or modified request is passed to the
         admission control module for a decision.  If the reservation is
         accepted, RSVP sets up (or modifies) the reservation and filter
         state.  It also forwards the RESV message to the next reverse-
         hop router(s) or sender host(s), as determined by the path (or
         routing) state.  If RSVP on the node rejects the reservation
         request due to admission control failure or to some processing

Zhang, Braden et al      Expires: January 1995                 [Page 10]

Internet Draft             RSVP Specification                  July 1994

         error, it discards the RESV message and returns a RSVP error
         message to the originating receiver host.  If the request
         modifies a previous reservation, RSVP may immediately remove
         the old state, or it may simply let the old state time out
         since it is no longer being refreshed; the details depend upon
         the style and the implementation.

          Previous    Incoming               Outgoing         Next
          Hops        Interfaces             Interfaces       Hops

          _____             _____________________              _____
         |     | data -->  |                     |  data -->  |     |
         |     |-----------|                     |------------|     |
         |_____|  <-- Resv |                     |   <-- Resv |_____|
                 Path -->  |                     |  Path -->
                           |       Router        |
          _____            |                     |             _____
         |     | data -->  |                     |   data --> |     |
         |     |-----------|                     |------------|     |
         |_____|  <-- Resv |                     |   <-- Resv |_____|
                 Path -->  |_____________________|   Path -->

                           Figure 3: Router Using RSVP

         Figure 3 illustrates RSVP's model of a router node.  Each data
         stream arrives from a previous hop through a corresponding
         incoming interface and departs through one or more outgoing
         interface(s).  Since the same host may be hosting both sender
         and receiver applications for a given session, the same
         physical interface may act in both the incoming and outgoing
         roles (for different data streams).

         The interfaces shown in Figure 3 may be physical interfaces
         (e.g., to point-to-point links), or they may be logical
         interfaces that reach multiple nodes through the same physical
         interface.  Multiple previous hops and/or next hops through a
         given physical interface can result from either the connected
         network being a shared medium (e.g., an Ethernet), or from the
         existence of non-RSVP routers in the path to the next RSVP hop
         (see Section 3.5).  It is generally necessary for RSVP to track
         both logical and physical interfaces on both the incoming and
         outgoing sides.

Zhang, Braden et al      Expires: January 1995                 [Page 11]

Internet Draft             RSVP Specification                  July 1994

      2.3.3 Merging RSVP Messages

         Whenever possible, the control information arriving in RSVP
         messages for a given session is combined into fewer outgoing
         messages; this is known generically as "merging".  Those
         messages that cause a state change are forwarded without delay,
         while the refresh messages may be merged into fewer messages,
         perhaps only one per session.

         For PATH messages, merging implies collecting together the
         Sender Descriptors from multiple incoming messages into a
         single outgoing PATH message.  For RESV messages, merging
         implies that only the essential (e.g., the largest) reservation
         requests need be forwarded, once per refresh period; redundant
         messages are "purged".  A successful reservation request will
         propagate as far as the closest point(s) along the sink tree to
         the sender(s) where a reservation level equal or greater than
         that being requested has been made.  At that point, the merging
         process will drop it in favor of another, equal or larger,
         reservation request.

         To allow merging, each node must save the state from received
         messages and then periodically generate cumulative PATH and
         RESV messages from the saved state, to be forwarded in place of
         the received messages.  Thus, new refresh messages are created
         hop-by-hop inside the network, at a rate determined by a
         "refresh period".  Since messages that modify the state in a
         node ("new" messages) are forwarded without delay, the refresh
         period does not affect the rate at which new state propagates
         from end to end (when packets are not lost).

         Although flowspecs are opaque to RSVP, merging requires the
         ability to determine which of two flowspecs is "larger", i.e.
         whether one represents a stricter request (and hence represents
         a larger resource commitment) than the other.  However, a
         flowspec may be a complex multi-dimensional vector, so the
         "larger-than" relationship may not be defined for a given pair
         of flowspecs.  For example, consider two flowspecs Fls1 and
         Fls2, where Fls2 asks for a lower throughput but shorter delay
         that Fls1.  It is not clear which is "larger", so we say they
         are "incompatible".

         There are several possible solutions to merging incompatible

              (1)  Compare on a single dimension, e.g., compare the
                   throughput requirement (average bit rate) only.

Zhang, Braden et al      Expires: January 1995                 [Page 12]

Internet Draft             RSVP Specification                  July 1994

              (2)  Construct a third flowspec that is greater than each
                   of the two being compared.  In the example above, we
                   could construct a third flowspec Fls3 by combining
                   the higher throughput from Fls1 with the lower delay
                   from Fls2.

              (3)  Treat the compatibility as an error that should be
                   avoided by applications.

         The choice of one of these approaches should be governed by
         flags in the flowspec itself, not by RSVP.

         Note that this problem cannot be avoided by refraining from
         merging flowspecs.  If incompatible flowspecs were not merged
         at a particular node A, then they would arrive at the next node
         upstream, say B, in separate RESV messages.  This may also
         happen if there are multiple next hops across the same outgoing
         interface.  Node B would have to make a reservation for the
         largest flowspec, if that is defined, or one that dominates all
         the given flowspecs; that is, it must merge the unmerged
         reservations.  Thus, failing to merge simply moves the problem
         one node upstream.

         This mechanism, reserving for the highest demand at each node,
         allows an application to increase an existing reservation
         request immediately (assuming admission control does not fail
         for the larger flowspec).  Decreasing a reservation has to be
         handled more cautiously, however.  The arrival of a RESV
         message with an apparently decreased reservation might be
         caused by the loss of a merged RESV message downstream.
         Therefore, an RSVP should not "believe" a reservation decrease
         until the cleanup timeout has passed.

         The refresh period and the cleanup timeout must obey the
         following general principles:

              A.   The refresh period must be long enough to keep RSVP
                   overhead at an acceptable level.

              B.   The refresh period should be short enough to allow
                   quick adaptation to route and multicast membership

                   Applications may differ in their sensitivity to
                   service outages, and therefore they should be able to
                   adjust the refresh period for their session state.
                   However, the technique of "local repair" (see Section
                   3.3.3) can provide rapid adaptation despite a long

Zhang, Braden et al      Expires: January 1995                 [Page 13]

Internet Draft             RSVP Specification                  July 1994

                   refresh period.

              C.   The timeout period must be long enough to allow for
                   loss of individual RSVP messages.

      2.3.4 Teardown

         As an optimization to release resources quickly, RSVP teardown
         messages remove path and reservation state without waiting for
         the cleanup timeout period.  RSVP messages are not delivered
         reliably, but the state will eventually time out even if a
         teardown message is lost.

         Teardown may be initiated either by an end system (sender or
         receiver), or by a router as the result of state timeout.  A
         router may also initiate a teardown message as the result of
         router or link failures detected by the routing protocol.  A
         teardown, once initiated, will be forwarded hop-by-hop without

         There are two types of RSVP Teardown message, PTEAR and RTEAR.
         A PTEAR message travels towards all receivers downstream from
         its point of initiation and tears down path state along the
         way, while an RTEAR message tears down reservation state and
         travels towards all senders upstream from its point of

         A particular reservation on a node may be shared among multiple
         senders and/or receivers, but it must apply to a unique next
         hop (and outgoing interface).  The receipt of an RTEAR message
         implies that the corresponding reservation state has been
         removed downstream, so that the reservation can safely be
         deleted locally.  Again, the local node will only forward the
         teardown message upstream when the state named in the message
         has been entirely removed locally.  As a result, an RTEAR
         message will prune the reservation state back (only) as far as
         possible.  Note that the RTEAR message will cease to be
         forwarded at the same node where merging suppresses forwarding
         of the corresponding RESV messages.

         Consider the router configuration shown in Figure 4 below.
         Assume that there are reservations for source S1 on both
         outgoing interfaces (c) and (d), and that the receiver R1 wants
         to tear down its reservation state for S1.  R1's RTEAR message
         arriving through interface (c) indicates that all reservation
         state for (this session and) sender S1 has been removed
         downstream.  The current node therefore removes the S1
         reservation state from interface (c).  However, since there

Zhang, Braden et al      Expires: January 1995                 [Page 14]

Internet Draft             RSVP Specification                  July 1994

         will still be an S1 reservation on interface (d), the RTEAR
         message will not be forwarded any further.

         However, if the outgoing interface connects to a shared medium
         or if there is a non-RSVP router immediately downstream, then
         there may be multiple next-hop RSVP nodes downstream that are
         reached through the same outgoing interface, say (c).  Then a
         single reservation may be shared among multiple next hops.
         RSVP must tag each reservation with the next hop(s) from which
         the RESV messages came, for use by teardown to avoid deleting
         shared state.

         Deletion of path state, whether as the result of a teardown
         message or because of timeout, may force adjustments in related
         reservation state to maintain consistency in the local node.
         Consider the path state for a sender S; the related reservation
         state would be as follows.

         o    Wildcard-Filter style: If S is the only sender to the
              session, delete the reservation.

         o    Fixed-Filter style: Delete reservations made for S.

         o    Dynamic-Filter style: Reduce total reservation if it now
              exceeds the total number of remaining senders.

   2.4 Examples

      We use the following notation for a RESV message:

      1.   Wildcard-Filter

           WF( *{r})

           Here "*{r}" represents a Flow Descriptor with a "wildcard"
           filter (choosing all senders) and a flowspec of quantity r.
           For simplicity we assume here that flowspecs are one-
           dimensional, defining for example the average throughput, and
           state them as a multiple of some unspecified base resource
           quantity B.

      2.   Fixed-Filter

           FF( S1{r1}, S2{r2}, ...)

           This message carries a list of (sender, flowspec) pairs,
           i.e., Flow Descriptors.

Zhang, Braden et al      Expires: January 1995                 [Page 15]

Internet Draft             RSVP Specification                  July 1994

      3.   Dynamic-Filter

           DF( n, {r} ; ) or DF( n, {r} ; S1, S2, ...)

           This message carries the count n of channels to be reserved,
           each using common flowspec r.  It also carries a list,
           perhaps empty, of filterspecs defining senders.

      Figure 4 shows schematically a router with two previous hops
      labeled (a) and (b) and two outgoing interfaces labeled (c) and
      (d).  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 and R2
      (R3) are routed via outgoing interface (c) ((d) respectively).

      In addition to the connectivity shown in 4, we must also specify
      the multicast routing within this node.  Assume first that data
      packets (hence, PATH messages) from each Si shown in Figure 4 is
      routed to both outgoing interfaces.  Under this assumption,
      Figures 5, 6, and 7 illustrate Wildcard-Filter reservations,
      Fixed-Filter reservations, and Dynamic-Filter reservations,

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

                        Figure 4: Router Configuration

      In Figure 5, the "Receive" column shows the RESV messages received
      over outgoing interfaces (c) and () and the "Reserve" column shows
      the resulting reservation state for each interface.   The "Send"
      column shows the RESV messages forwarded to previous hops (a) and
      (b).  In the "Reserve" column, each box represents one reservation
      "channel", with the corresponding filter.  As a result of merging,
      only the message with the largest flowspec is forwarded upstream
      to each previous hop.

Zhang, Braden et al      Expires: January 1995                 [Page 16]

Internet Draft             RSVP Specification                  July 1994

               Send          |       Reserve              Receive
                             |       _______
         WF( *{3B} ) <- (a)  |  (c) | * {3B}|    (c) <- WF( *{B} )
                             |      |_______|
                             |       _______
         WF( *{3B} ) <- (b)  |  (d) | * {B} |    (d) <- WF( *{3B} )
                             |      |_______|

               Figure 5: Wildcard-Filter Reservation Example 1

      Figure 6 shows Fixed-Filter style reservations.  Merging takes
      place among the flow descriptors (i.e., filter spec, flowspec
      pairs).  For example, the message forwarded to previous hop b,
      towards S2 and S3, contains flow descriptors received from
      outgoing interfaces (c) and (d).  Similarly, when FF( S1{B} ) and
      FF( S1{3B} ) are merged, the single message FF( S1{3B} ) is sent
      to previous hop (a), towards S1.

      For each outgoing interface, there is a private reservation for
      each source that has been requested, but this private reservation
      is shared among the receivers that made the request.

Zhang, Braden et al      Expires: January 1995                 [Page 17]

Internet Draft             RSVP Specification                  July 1994

         Send          |       Reserve              Receive
                       |       ________
  FF( S1{3B} ) <- (a)  |  (c) | S1{B}  |   (c) <- FF( S1{B}, S2{5B} )
                       |      |________|
                       |      | S2{5B} |
                       |      |________|
                       |       ________
               <- (b)  |  (d) | S1{3B} |   (d) <- FF( S1{3B}, S3{B} )
  FF( S2{5B}, S3{B} )  |      |________|
                       |      | S3{B}  |
                       |      |________|

               Figure 6: Fixed-Filter Reservation Example

      Figure 7 shows an example of Dynamic-Filter reservations.  The
      receivers downstream from interface (d) have requested two
      reserved channels, but selected only one sender, S1.  The node
      reserves min(2,3) = 2 channels of size B on interface (d), and it
      then applies any specified filters to these channels.  Since only
      one sender was specified, one channel has no corresponding filter,
      as shown by `?'.

      Similarly, the receivers downstream of interface (c) have
      requested two channels and selected senders S1 and S2.  The two
      channels might have been one channel each from R1 and R2, or two
      channels requested by one of them, for example.

Zhang, Braden et al      Expires: January 1995                 [Page 18]

Internet Draft             RSVP Specification                  July 1994

         Send           |      Reserve              Receive
                        |       ________
 DF( 1,{B}; S1) <- (a)  |  (c) |  S1{B} |  (c) <- DF( 2,{B}; S1, S2)
                        |      |________|
                        |      |  S2{B} |
                        |      |________|
                        |       ________
 DF( 2,{B}; S2) <- (b)  |  (d) |  S1{B} |   (d) <- DF( 2,{B}; S1)
                        |      |________|
                        |      |   ?{B} |
                        |      |________|

              Figure 7: Dynamic-Filter Reservation Example

      A router should not reserve more Dynamic-Filter channels than the
      number of upstream sources (three, in the router of Figure 7).
      Since there is only one source upstream from previous hop (a), the
      first parameter of the DF message (the count of channels to be
      reserved) was decreased to 1 in the forwarded reservations.
      However, this is unnecessary, because the routers upstream will
      reserve only one channel, regardless.

      When a DF reservation is received, it is labeled with the IP
      address of the next hop (RSVP-capable) router, downstream from the
      current node.  Since the outgoing interface may be directly
      connected to a shared medium network or to a non-RSVP-capable
      router, there may be more than one next-hop node downstream; if
      so, each sends independent DF RESV messages for a given session.
      The number N' of DF channels reserved on an outgoing interface is
      given by the formula:

      N' = min( D1+D2+...Dn, Ns),

      where Di is the D value (channel reservation count) in a RESV from
      the ith next-hop node.

      The three examples just shown assume full routing, i.e., data
      packets from S1, S2, and S3 are routed to both outgoing
      interfaces.  Assume the routing shown in Figure 8, in which data
      packets from S1 are not forwarded to interface (d) (because the
      mesh topology provides a shorter path for S1->R3 that does not

Zhang, Braden et al      Expires: January 1995                 [Page 19]

Internet Draft             RSVP Specification                  July 1994

      traverse this node).

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

                        Figure 8: Router Configuration

      Under this assumption, Figure 9 shows Wildcard-Filter
      reservations.  Since there is no route from (a) to (d), the
      reservation forwarded out interface (a) considers only the
      reservation on interface (c), so no merging takes place in this

               Send          |       Reserve              Receive
                             |       _______
          WF( *{B} ) <- (a)  |  (c) | * {3B}|    (c) <- WF( *{B} )
                             |      |_______|
                             |       _______
         WF( *{3B} ) <- (b)  |  (d) | * {B} |    (d) <- WF( * {3B} )
                             |      |_______|

       Figure 9: Wildcard-Filter Reservation Example -- Partial Routing

   2.5 Host Model

      Before a session can be created, the session socket, comprised of
      DestAddress and ResvID, must be assigned and communicated to all
      the senders and receivers by some out-of-band mechanism.  In order
      to join an RSVP session, the end systems perform the following

           H1   A receiver joins the multicast group specified by

Zhang, Braden et al      Expires: January 1995                 [Page 20]

Internet Draft             RSVP Specification                  July 1994


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

           H3   A receiver listens for PATH messages.

           H4   A receiver starts sending appropriate RESV messages,
                specifying the desired Flow Descriptors.

      There are several synchronization issues.

      o    Suppose that a new sender starts sending data but there are
           no receivers.  There will be no multicast routes beyond the
           host (or beyond the first RSVP-capable router) along the
           path; the data will be dropped at the first hop until
           receivers(s) do appear (assuming a multicast routing protocol
           that "prunes off" or otherwise avoids unnecessary paths).

      o    Suppose that a new sender starts sending PATH messages (H2)
           and immediately starts sending data, 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.

      o    If a receiver starts sending RESV messages (H4) before any
           PATH messages have reached it (and if path state is being
           used to route RESV messages), 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.6.2 discusses the general requirements and
      presents a generic API.

Zhang, Braden et al      Expires: January 1995                 [Page 21]

Internet Draft             RSVP Specification                  July 1994

3. Functional Specification

   There are currently 6 types of RSVP messages: PATH, RESV, PTEAR,

   3.1 Message Formats

      3.1.1 Path Message

                0             1              2             3
         | Vers | Type |    Flags    |       RSVP Checksum       |
         |                      DestAddress                      |
         |                        ResvID                         |
         |                    Refresh Period                     |
         |                    State TTL Time                     |
         |                Previous Hop Address                   |
         |       ///////////////     |         SD Count          |
         |                 Authentication Field                  |
         //                         ...                          //
         |               Sender Descriptor List                  |
         //                         ...                          //

         IP Fields:



              IP Source Address

                   The IP address of the host or router sending this

              IP Destination Address

                   The IP address of the data destination (DestAddress).

Zhang, Braden et al      Expires: January 1995                 [Page 22]

Internet Draft             RSVP Specification                  July 1994

         RSVP Fields:


                   Version number.  This is version 1.


                   1  = Path Message


                   8 = Drop

                        If this flag bit is on then data packets will be
                        dropped when they are destined to this session
                        but their sender is not currently selected by
                        any filter.  If this flag bit is off, such data
                        packets will still be forwarded but without a
                        reservation, i.e., using a best-effort class.

              RSVP Checksum

                   A standard TCP/UDP checksum, over the contents of the
                   RSVP message with the checksum field replaced by

              DestAddress, ResvID

                   The IP address and stream Id identifying the session,
                   i.e., the session socket.

              Previous Hop Address

                   The IP address of the interface through which the
                   host or router last forwarded this message.

                   The Previous Hop Address is used to support reverse-
                   path forwarding of RESV messages.  This field is
                   initialized by a sender to its IP address (see IP
                   Source Address above) and must be updated at each
                   router hop as the PATH message is forwarded.

              Refresh Period

                   This field specifies the refresh timeout period in
                   milliseconds.  See Section 3.3 below.

Zhang, Braden et al      Expires: January 1995                 [Page 23]

Internet Draft             RSVP Specification                  July 1994

              State TTL Time

                   This field specifies the time-to-live for soft state,
                   in milliseconds.  It determines the cleanup timeout
                   period; see Section 3.3 below.

              SD Count

                   Count of Sender Descriptors that follow.

              Authentication Field

                   A variable-length authentication field to identify
                   and perhaps authenticate the principal making this
                   reservation request.  The field has the following

             |  AuthLen    |   AuthType  |                           |
             +-------------+-------------+                           +
             //                  Authentication Info                 //

                   The AuthLen octet contains the integer length of the
                   field in fullwords, and AuthType specifies the format
                   of the field.  See Section 3.6.1 for currently
                   defined authentication field formats.  If there is no
                   authentication information, AuthLen will be zero, but
                   the Authentication Field will still occupy one
                   fullword in the message.

              Sender Descriptor List

                   A list of Sender Descriptors (see below).  The order
                   of entries in this list is irrelevant.

         Each sender must periodically send a PATH message containing a
         single Sender Descriptor describing its own data stream.  These
         messages are addressed to the uni-/multicast destination
         address for the session, and they are forwarded to all
         receivers, following the same paths as a data packet from the
         same sender.  PATH messages are received and processed locally
         to create path state at each intermediate router along the

Zhang, Braden et al      Expires: January 1995                 [Page 24]

Internet Draft             RSVP Specification                  July 1994

         If an error is encountered while processing a PATH message, an
         RSVP error message is sent to all the sender hosts listed in
         the Sender Descriptor List.

         PATH messages are distributed from senders to receivers along
         the exact paths that the data will traverse, using uni-
         /multicast routing.  This distribution actually takes place
         hop-by-hop, allowing RSVP in each router along the path to
         observe and modify the message.  Routing of PATH messages is
         based on the sender address(es) from the Sender Descriptor(s),
         not the IP source address.  This is necessary to prevent loops;
         see Section 3.2.

         Each Sender Descriptor consists of two variable-length fields:
         a sender template that defines the format of data packets and a
         corresponding Flowspec that describes the traffic
         characteristics.  The sender template has the form of a
         filterspec, and a Sender Descriptor has the form defined below
         for a Flow Descriptor (see also Section 3.6.1).  The flowspec
         may be omitted, in which case its length field will be zero
         (but it will still occupy one fullword in the Sender

         The Sender template is retained in the Path state in order to
         validate filterspecs in RESV messages.  Suppose that a
         filterspec consisted of a simple (value,mask) pair (Vf,Mf) to
         be applied to the headers of the data packets (the actual
         format is slightly more complex; see Section 3.6.1).  Then the
         corresponding template would be a (value,mask) pair defining
         those bits of the data packet headers that are fixed.  While
         processing a reservation using filterspec (Vf,Mf) for the
         sender with template (Vs,Ms), RSVP can then test whether
         Vf&(Mf&Ms) = Vs&(M&Ms).  If not, this filterspec cannot
         possibly match the data stream from this sender at any node
         upstream, and the reservation can be rejected with an error
         message back to the receiver.

Zhang, Braden et al      Expires: January 1995                 [Page 25]

Internet Draft             RSVP Specification                  July 1994

      3.1.2 Resv Message

         RESV messages are sent from receivers to senders along reverse
         paths established by PATH messages.

                0             1              2             3
         | Vers | Type |    Flags    |       RSVP Checksum       |
         |                      DestAddress                      |
         |                        ResvID                         |
         |                    Refresh Period                     |
         |                    State TTL Time                     |
         |                   Next Hop Address                    |
         |                     RecvAddress                       |
         | Dynamic Reservation Count |         FD Count          |
         |                 Authentication Field                  |
         //                         ...                          //
         |                Flow Descriptor List                   |
         //                         ...                          //

         The fields are the same as defined earlier for a PATH message,
         except for the following:

         IP Fields:

              IP Source Address

                   The IP address of the node sending this message.

              IP Destination Address

                   The IP address of the next-hop router or host to
                   which this message is being sent.

         RSVP Fields:

Zhang, Braden et al      Expires: January 1995                 [Page 26]

Internet Draft             RSVP Specification                  July 1994


                   2 = Resv Message


                   The following flag bit combinations define the
                   reservation style:

                   001xxxxx = Wildcard-Filter

                   010xxxxx = Fixed-Filter

                   011xxxxx = Dynamic-Filter

              Next Hop Address

                   The IP address of the interface through which the
                   last forwarded this message.

                   The Next Hop Address is used to support teardown.
                   This field is initialized by a receiver to its IP
                   address and must be updated at each router hop as the
                   RESV message is forwarded.


                   The IP address of (one of the) receiver(s) that
                   originated this message, or one of the RESV messages
                   that was merged to form this message.

              Dynamic Reservation Count

                   The number of channels to be reserved, for a
                   Dynamic-Filter style reservation.

                   If the ResvStyle is Dynamic-Filter, this integer
                   value must be constant and equal or greater than (FD
                   Count).  For other ResvStyles, this field must be

              FD Count

                   Count of Flow Descriptors in the Flow Descriptor

              Flow Descriptor List

Zhang, Braden et al      Expires: January 1995                 [Page 27]

Internet Draft             RSVP Specification                  July 1994

                   A list of Flow Descriptors, i.e., (Filterspec,
                   flowspec) pairs, to define individual reservation
                   requests.  The first entry in the list may have
                   special meaning (see below); the order of later
                   entries is irrelevant.

                   Each Flow Descriptor has the following form:

             |  FiltSLen   |  FiltSType  |                           |
             +-------------+-------------+                           +
             //                    Filter Spec ...                   //
             |  FlowSLen   |  FlowSType  |                           |
             +-------------+-------------+                           +
             //                    Flow Spec ...                     //

                   Here FiltSLen and FlowSLen are one-octet fields
                   specifying the lengths in fullwords (including the
                   length byte) of the filterspec and flowspec,
                   respectively, and FiltSType and FlowSType are one-
                   octet fields defining the corresponding field
                   formats.  See Section 3.6.1 for currently defined

         The following specific rules hold for different reservation

         o    Wildcard-Filter

              To obtain Wildcard-Filter service, set FD Count = 1 and
              include a single Flow Descriptor whose Filterspec part is
              a wild card, i.e., selects all senders.  and whose
              flowspec part defines the desired flow parameters.

         o    Fixed-Filter

              Include a list of FD Count >= 1 Flow Descriptors, each
              defining a sender Filterspec and a corresponding flowspec.

         o    Dynamic-Filter

              Include max(1, FD Count) Flow Descriptors in the message.
              Here the FD Count specifies the number of sender
              Filterspecs that are included.  If DC is the Dynamic

Zhang, Braden et al      Expires: January 1995                 [Page 28]

Internet Draft             RSVP Specification                  July 1994

              Reservation Count, then DC >= FD Count >= 0.

              The Flowspec part of the first Flow Descriptor defines the
              desired size of all the DC channels that are reserved.
              The Flowspec parts of later Flow Descriptors (if any) are

Zhang, Braden et al      Expires: January 1995                 [Page 29]

Internet Draft             RSVP Specification                  July 1994

      3.1.3 Error Messages

         There are two types of RSVP error messages: PERR messages
         result from PATH messages and travel towards senders, while
         RERR messages result from RESV messages and travel towards
         receivers.  RSVP error messages are triggered only by
         processing of PATH and RESV messages; errors encountered while
         processing error or teardown messages must not create error

         A PERR message has the following form:

                0             1              2             3
         | Vers | Type |    Flags    |       RSVP Checksum       |
         |                      DestAddress                      |
         |                        ResvID                         |
         |  Error Code | Error Index |        Error Value        |
         |       ////////////// (ignored) //////////////////     |
         |       ////////////// (ignored) //////////////////     |
         |     /// Reserved ///      |         SD Count          |
         |                 Authentication Field                  |
         //                         ...                          //
         |                Sender Descriptor List                 |
         //                         ...                          //

         The fields are the same as in a PATH message, defined earlier,
         except for the following:

         RSVP Fields:


                   3 = PERR message

              Error Code

Zhang, Braden et al      Expires: January 1995                 [Page 30]

Internet Draft             RSVP Specification                  July 1994

                   A one-octet error description.

                        01 = Insufficient memory

                        02 = Count Wrong

                             The SD Count field does not match length of

              Error Index

                   Position of Sender Descriptor that caused the error
                        Sender Descriptor List.  An integer between zero
                        and SD Count - 1.

              Error Value


         A RERR message has the following form:

Zhang, Braden et al      Expires: January 1995                 [Page 31]

Internet Draft             RSVP Specification                  July 1994

                0             1              2             3
         | Vers | Type |    Flags    |       RSVP Checksum       |
         |                      DestAddress                      |
         |                        ResvID                         |
         |  Error Code | Error Index |        Error Value        |
         |       ////////////// (ignored) //////////////////     |
         |       ////////////// (ignored) //////////////////     |
         |                     RecvAddress                       |
         | Dynamic Reservation Count |         FD Count          |
         |                 Authentication Field                  |
         //                         ...                          //
         |                Flow Descriptor List                   |
         //                         ...                          //

         The fields are the same as in a RESV message, defined earlier,
         except for the following:

         RSVP Fields:


                   4 = RERR message

              Error Code

                   A one-octet error description.

                        DEFINE THESE VALUES IN AN APPENDIX??

                        01 = Insufficient memory

                        02 = Count Wrong

                             The FD Count field does not match length of

Zhang, Braden et al      Expires: January 1995                 [Page 32]

Internet Draft             RSVP Specification                  July 1994

                        03 = No path information for this Resv

                        04 = No Sender information for this Resv

                             There is path information, but it does not
                             include the sender specified in any of the
                             Filterspecs listed in the Resv messager.

                        05 = Incorrect Dynamic Reservation Count

                             Dynamic Reservation Count is zero or less
                             than FD Count.

                        06 = Filterspec error

                        07 = Flowspec syntax error

                        08 = Flowspec value error

                             Internal inconsistency of values.

                             [What should be done with Flowspec Feature
                             Not Supported?]

                        09 = Resources unavailable

                             [Sub-reasons?  Depend upon traffic control
                             and admission control algorithms?]

              Error Index

                   Position of Flow Descriptor that caused the error
                        Flow Descriptor List.  An integer between zero
                        and FD Count - 1.

              Error Value

                   Specific cause of the error described by the Error

                        DEFINE THESE VALUES IN AN APPENDIX??

Zhang, Braden et al      Expires: January 1995                 [Page 33]

Internet Draft             RSVP Specification                  July 1994

         An error message may be duplicated and forwarded unchanged.
         Since PATH and RESV messages may be merged, an error condition
         must be disseminated to all RSVP client applications whose
         requests may have contributed to the error situation.
         Therefore, RSVP error messages must be propagated and perhaps
         duplicated hop-by-hop.  For this purpose, an error message must
         include all the information used to route the original message
         that caused the error: the Sender Descriptor List, Flags,
         RecvAddress, and Flow Descriptor List fields, as appropriate.
         In particular, a RERR message carries the same style flags as
         the RESV message that caused the error.

         To ease implementation, the error message formats are chosen to
         match the formats of the messages whose processing caused the
         error.  In particular, a PATH or RESV message that encounters
         an error can be simply converted to the corresponding error
         message by overwriting the Type and the Refresh Period fields.

         A PERR message is forwarded to all previous hops for all
         senders listed in the Sender Descriptor List.  The routing of a
         RERR message is more complex.

         o    An error in a filterspec should be detected at the first
              RSVP hop from the receiver application, normally within
              the receiver host.  However, an error caused by a
              flowspec, normally an admission control failure, may be
              detected somewhere along the path(s) to the sender(s).

         o    The router that creates a RERR message as the result of
              processing a RESV message should send the RERR message out
              the interface through which the RESV arrived.

         o    In succeeding hops, the routing of a RERR message depends
              upon its style.  In general, a RERR message is sent on a
              pruned version of the multicast distribution tree for the
              session; those branches that do not have reservations for
              any of the specified senders are pruned off.

              A DF-style or WF-style RERR message is forwarded on all
              outgoing interfaces for which there is already a
              reservation of the corresponding style.

              A FF-style RERR message is forwarded on all outgoing
              interfaces for which there is already a FF-style
              reservation for the sender (filterspec) corresponding to
              the error.

         At the end host, RSVP delivers a copy of every relevant error

Zhang, Braden et al      Expires: January 1995                 [Page 34]

Internet Draft             RSVP Specification                  July 1994

         message to its local application clients.  It examines the set
         of RSVP requests that local clients have made through the API,
         and notifies every client that contributed to the error
         message.  A match is required between the session, filters
         (senders), and reservation styles of the error message and the
         corresponding state in the latest API requests.  A particular
         notification should include only the information (e.g.,
         filters) relevant to that application.

      3.1.4 Teardown Messages

         There are two types of RSVP Teardown message, PTEAR and RTEAR.
         A PTEAR message tears down path state and travels towards all
         receivers downstream from its point of initiation.  A RTEAR
         message tears down reservation state and travels towards all
         senders upstream from its point of initiation.

         A PTEAR message has the same format as a PATH message, except
         that in a PTEAR message:

         o    Type field = 5

         o    Refresh Period and State TTL Time fields are ignored.

         A RTEAR message has the same format as a RESV message, except
         that in a RTEAR message:

         o    Type field = 6

         o    Refresh Period and State TTL Time fields are ignored.

         Any Flowspec components of Flow Descriptors in a RTEAR or PTEAR
         message are ignored.

         Teardown messages are processed in the following way.

         o    PTEAR

              Processing a PTEAR  message is straightforward.  For each
              sender S in the message, the node removes path state for S
              and also deletes all related reservations.  Finally, the
              node forwards the original PTEAR message to all outgoing
              interfaces through which data packets from some S in the
              packet would be routed.  That is, PTEAR forwarding rules
              are the same as those for PATH messages.

         o    RTEAR

Zhang, Braden et al      Expires: January 1995                 [Page 35]

Internet Draft             RSVP Specification                  July 1994

              Processing an RTEAR  message is more complex.  Suppose a
              RTEAR message arrives through outgoing interface OI from
              next hop NH.  For each sender S listed in the RTEAR
              message, the node checks the reservation, if any, for S on
              OI.  If there is a reservation and if this reservation is
              shared among more than one next hop, then the only action
              is to remove NH from the list of next hops sharing this
              reservation.  If there is only a single next hop, then the
              reservation is deleted.  Finally, the node forwards the
              original RTEAR message to all incoming interfaces for
              senders listed in the message.  That is, RTEAR forwarding
              rules are the same as those for RESV messages.

   3.2 Avoiding Message Loops

      RSVP routes its control messages, and every routing procedure must
      avoid looping packets.  The merging of RSVP messages delays
      forwarding at each node for up to one refresh period.  This may
      avoid high-speed loop, but there can still be "slow" loops,
      clocked by the refresh period; the effect of such slow loops is to
      keep state active forever, even if the end nodes have ceased
      refreshing it.  RSVP uses the following rules to prevent looping

           L1:  When an RSVP message is received through a particular
                incoming interface F, the message must not be forwarded
                out F as an outgoing interface.  This implies that RSVP
                must keep track of the interface through which each
                message is received, to avoid forwarding it out that
                interface.  Note that, although RSVP distinguishes
                incoming from outgoing interfaces, in many cases the
                same physical interface will play both roles.

           L2:  Upon receipt of a PATH message in particular, a route
                must be computed for each of its sender Flow
                Descriptors.  These routes, obtained from the
                uni/multicast routing table, generally depend upon the
                (sender host address, DestAddress) pairs.  Each route
                consists of a list of outgoing interfaces; these lists
                (with the incoming interfaces deleted by rule L1) are
                used to create merged PATH messages to be forwarded
                through the outgoing interfaces.

      Assuming that multicast routing is free of loops, PATH messages
      cannot loop even in a topology with cycles.

Zhang, Braden et al      Expires: January 1995                 [Page 36]

Internet Draft             RSVP Specification                  July 1994

      Since PATH messages don't loop, they create path state defining a
      loop-free path to each sender.  Similarly, RESV messages directed
      to particular senders cannot loop.  However, rules L1 and L2
      cannot protect against looping RESV messages that are directed
      towards all senders (WF or DF styles).  The following three rules
      are needed for this purpose.

           L3:  Each RESV message carries a receiver address in the
                RecvAddress field.  When the choice of address to place
                in a merged RESV message is otherwise arbitrary, RSVP
                must use the IP address that is numerically largest.

           L4:  When a RESV message is received, the Reverse Path
                Forwarding rule is applied to the receiver address in
                the message; that is, the message must be discarded
                unless it arrives on the interface that is the preferred
                route to the receiver.

           L5:  A RESV message whose RecvAddress matches one of the IP
                addresses of the local node must be discarded without

      Figure 10 illustrates the effect of the rule L1 applied to RESV
      messages.  It shows a transit router, with one sender and one
      receiver on each side; interfaces a and c therefore are both
      outgoing interfaces and physical previous hops.  Both receivers
      are making a Wildcard-Filter style reservation, in which the RESV
      message is to be forwarded to all previous hops for senders in the
      group, with the exception of the interface through which it

Zhang, Braden et al      Expires: January 1995                 [Page 37]

Internet Draft             RSVP Specification                  July 1994

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

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

              Figure 10: Example: Rule (1) for Preventing Loops.

      The loop-suppression rules for RESV messages also prevent looping
      of RTEAR messages.  Note that RTEAR messages are otherwise subject
      to fast loops, since they are not delayed by a refresh timeout

      PERR messages are routed upstream by the same rules used for FF
      and DF RESV messages (there is no equivalent of wildcard-filter
      for routing a PERR message).  Similarly, RERR messages are routed
      by the rules for PATH messages.  For reasons explained above, no
      special loop-suppression rules are required in either case.

   3.3 Soft State Management

      The RSVP state associated with a session in a particular node is
      divided into atomic elements that are created, refreshed, and
      timed out independently.  The atomicity is determined by the
      requirement that any sender or receiver may enter or leave the
      session at any time, and its state should be created and timed out

      Management of RSVP state is complex because there is not generally
      a one-to-one correspondence between state carried in RSVP control
      messages and the resulting state in nodes.  Due to merging, a
      single message contain state referring to multiple stored
      elements.  Conversely, due to reservation sharing, a single stored
      state element may depend upon (typically, the maximum of) state

Zhang, Braden et al      Expires: January 1995                 [Page 38]

Internet Draft             RSVP Specification                  July 1994

      values received in multiple control messages.

      3.3.1 Time Parameters

         For each element, there are two time parameters controlling the
         maintenance of soft state: the refresh period R and the TTL
         (time-to-live) value T.  R specifies the period between
         successive refresh messages over the same link.  T controls how
         long state will be retained after refreshes stop appearing.

         PATH and RESV messages specify both R and T.  When messages are
         merged and forwarded to the next hop, R should be the minimum R
         that has been received, and T should be the maximum T that has
         been received.   Thus, the largest T determines how long state
         is retained, and the smallest R determines the responsiveness
         of RSVP to route changes.  In the first hop, they are expected
         to be equal.  The RSVP API should set a configurable default
         value, which can be overridden by an application for a
         particular session.

         To avoid gaps in user service due to lost RSVP messages, RSVP
         should be forgiving about missing refresh messages.  A node
         should not discard an RSVP state element until K * Tmax has
         elapsed without a refresh message, where Tmax is the maximum of
         the T values it has received.  K is some small integer; K-1
         successive messages may be lost before state is deleted.
         Currently K = 3 is suggested.

         Let X indicate a particular message type (either "Path" or
         "Resv") and a particular session.  Then each X message from
         node a to node b carries refresh period Rab and TTL time Tab.

         o    As X messages arrive at node b, the node computes and
              saves both the min over the Rab values (min(Rab)) and the
              max over the Tab values (max(Tab)) from these messages.

         o    The node uses K * max(Tab) as its cleanup timeout

         o    The node uses min(Rab's) as the refresh period.

         o    Each refresh message forwarded by node b to node c has Tbc
              = max(Tab) and Rbc = min(Rab)

         o    A node may impose an upper bound Tmax and a lower bound
              Rmin, set by configuration information, and enforce: Rmin
              <= R <= T <= Tmax.

Zhang, Braden et al      Expires: January 1995                 [Page 39]

Internet Draft             RSVP Specification                  July 1994

         The receiver should be conservative about reacting to certain
         error messages.  For example, during a route change a receiver
         may get back "No Path" error messages until Path messages have
         propagated along the new route.

      3.3.2 Teardown

         Teardown messages, like other RSVP messages, are sent as
         datagrams and may be lost (although a QoS is used that should
         minimize the chances of congestive loss of RSVP messages).  To
         increase the reliability of teardown, Q copies of any given
         teardown message can be sent.  Note that if the iteration count
         Q on initiating teardown messages is > 1, then the state cannot
         actually be deleted until Q teardowns have been sent.  The
         state would be placed in a "moribund" status meanwhile.

         The appropriate value of Q is an engineering issue.  Q = 1
         would be the simplest and may be adequate, since unrefreshed
         state will time out anyway; teardown is an optimization.  Note
         that if one or more teardown hops are lost, the router that
         failed to receive a teardown message will time out its state
         and initiate a new teardown message beyond the loss point.
         Assuming that RSVP message loss probability is small (but non-
         zero), the longest time to delete state will seldom exceed one
         state timeout time K*Tab.

         Here is an example.  Here G1, G2, G3, and G4 are routers
         between a sender S and a receiver R.  S initiates a PTEAR
         message (denoted by "PT"), but this message is lost between
         routers G2 and G3.  Since G2 has deleted its state for S, G2
         will cease refreshing G3 (though G3 is still refreshing G4,

                   PT      PT      PT
                 S ---> G1 ---> G2 -->x   G3       G4        R

         After a time K*Tab, G3's state will time out, and G3 will
         initiate a teardown for S path state:

                                             PT       PT
                                          G3 ----> G4 ---->  R

         If some hop of this chain is lost, there will again be state
         timeout to continue the teardown.  This process should
         terminate in a few timeout periods.

Zhang, Braden et al      Expires: January 1995                 [Page 40]

Internet Draft             RSVP Specification                  July 1994

      3.3.3 Local Repair

         To accommodate merging, RSVP uses hop-by-hop refreshing of
         state, where each node sends refreshes to its next/previous
         hops periodically.  However, as an optimization, local events
         could be used to trigger the RSVP module to send such refreshes
         to any time.  For example, suppose that the local routing
         protocol module were able to notify the RSVP module that a
         route has changed for particular destinations.  The RSVP module
         could use this information to trigger an immediate refresh of
         state for these destinations along the new route.  This would
         allow fast adaptation to routing changes without the overhead
         of a short refresh period.

   3.4 Sending RSVP Messages

      Under overload conditions, lost RSVP control messages could cause
      the loss of resource reservations.  It recommended that routers be
      configured to give a preferred class of service to RSVP packets.
      RSVP should not use significant bandwidth, but the delay of RSVP
      packets needs to be controlled.

      An RSVP PATH or RESV message consists of a small root segment (24
      or 28 bytes) followed by a list of descriptors.  The descriptors
      are bulky and there could be a large number of them, resulting in
      potentially very large messages.  IP fragmentation is inadvisable,
      since it has bad error characteristics.  Instead, RSVP-level
      fragmentation should be used.  That is, a message with a long list
      of descriptors will be divided into segments that will fit into
      individual datagrams, each carrying the same root fields.  Each of
      these messages will be processed at the receiving node, with a
      cumulative effect on the local state.  No explicit reassembly is

      The largest RSVP message is 556 bytes.

   3.5 Automatic Tunneling

      It is impractical to deploy RSVP (or any protocol) at the same
      moment throughout the Internet, and 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.

      RSVP will automatically tunnel 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

Zhang, Braden et al      Expires: January 1995                 [Page 41]

Internet Draft             RSVP Specification                  July 1994

      unaffected by non-RSVP routers in the path.  When a PATH message
      traverses a non-RSVP cloud, the copies that emerge will carry as a
      Previous Hop address the IP address of the last RSVP-capable
      router before entering the cloud.  This will cause effectively
      construct a tunnel through the cloud for RESV messages, which will
      be forwarded directly to the next RSVP-capable router on the
      path(s) back towards the source.

      This automatic tunneling capability of RSVP has a cost: a PATH
      message must carry the session DestAddress as its IP destination
      address; it cannot be addressed hop-by-hop.  As a result, each
      RSVP router must have a small change in its multicast forwarding
      path to recognize RSVP messages (by the IP protocol number) and
      intercept them for local processing.  See Section 3.6.5 below.

      (There is a potential defect in tunneling.  Merged PATH messages
      can carry information for a list of senders, and since multicast
      routing depends in general upon the sender, it is not possible to
      ensure that all the non-RSVP routers along the tunnel will be able
      to route the packet properly.  The effect turns out to be that
      tunnels may distribute path information to RSVP routers where it
      should not go, which may in turn lead to unused reservations at
      these routers.  This is hoped to be an acceptable defect.)

      Of course, if an intermediate cloud does not support RSVP, it is
      unable to perform resource reservation.  In this case, firm end-
      to-end service guarantees cannot be made.  However, if there is
      sufficient excess capacity through such a cloud, acceptable and
      useful realtime service may still be possible.

   3.6 Interfaces

      3.6.1 Reservation Parameters

         All variable-length RSVP parameters use the same general
         format.  They begin with a length octet followed by a type
         octet, and occupy an integral number of fullwords.  The length
         octet specifies the total length of the parameter in fullwords
         or zero to indicate no parameter.  An RSVP implementation can
         store and pass such parameters as opaque objects.

         o    Flowspec Format

              Flowspec type 1 is specific to the CSZ packet scheduler
              [CSZ92].  It has the following format:

Zhang, Braden et al      Expires: January 1995                 [Page 42]

Internet Draft             RSVP Specification                  July 1994

               | FlowSLen=6|FlowSType=1|      VFoffset         |
               |    QoS Type (Guaranteed, Predictive, ...)     |
               |           Max end-to-end delay (ms)           |
               |           Average data rate (bits/ms)         |
               |           Token Bucket Depth (bits)           |
               |           Global Share Handle                 |

              Flowspec format 2 is defined in RFC-1363 [Partridge92].

         o    Filterspec Format

              For compactness and simplicity of processing, this version
              of the RSVP specification defines an RSVP Filterspec to be
              composed of an explicit IP address plus an optional
              variable-length mask-and-value pair VF, in the following

               |  FiltSLen |FiltSType=1|      VFoffset         |
               |                Sender IP Address              |
               +-----------+-----------+-----------+-----------+  ---
               |                   V: VF Value Part            |   Nf
               /                                               / octets
               /                                               /
               +-----------+-----------+-----------+-----------+  ---
               |                   M: VF Mask Part             |   Nf
               /                                               / octets
               /                                               /
               +-----------+-----------+-----------+-----------+  ---

              The value M and the mask V each have length:

                 Nf = (4*FiltSLen - 8)/2 octets.

              M and V define a filter that uses a mask-and-match
              algorithm applied to the packet at VFoffset octets from
              the beginning of the IP header.  The minimum length of

Zhang, Braden et al      Expires: January 1995                 [Page 43]

Internet Draft             RSVP Specification                  July 1994

              this format of sender template is 7 octets (FiltSLen = 2).

              A wildcard Filterspec, which will match any sender host,
              has zero for the Sender IP Address [If VM part zero also,
              could shorten to FiltSLen = 2].

              To speed RSVP processing, a filterspec that appears in an
              RSVP message use the following "canonical form".

              o    The high-order octet of the mask M must be non-zero
                   (this can always be achieved by adjusting VFoffset).

              o    The (V,M) part must not include either the sender or
                   receiver address of the IP header; these are carried


                 There are many possible filter rules that cannot be
                 expressed using a simple mask and value pair.  A
                 compact and general filter encoding is for further

         o    Authenticator Format

              The following simple form of authenticator is defined:

               |   AuthLen | AuthType=1|                       |
               +-----------+-----------+                       +
               |               Mailbox name: user@domain       |
               //                                              //

              The rules for merging and interpreting this field require
              further study.

      3.6.2 Application/RSVP Interface

         This section describes a generic API from an application to an
         RSVP control process.  The details of a real interface may be
         operating-system dependent; the following can only suggest the
         basic functions to be performed.  Some of these calls cause
         information to be returned asynchronously.

         An application could directly send and receive RSVP messages,
         just as an application can do file transfer using UDP.

Zhang, Braden et al      Expires: January 1995                 [Page 44]

Internet Draft             RSVP Specification                  July 1994

         However, we envision that many applications will not want to
         know the details of RSVP operation, nor to provide the timing
         services necessary to keep the state refreshed, any more than
         an application wants to handle TCP retransmission timeouts.
         Therefore, a host using RSVP may have an RSVP control process
         to handle these functions.  Using local IPC, applications will
         register or modify resource requests with this process and
         receive notifications of success or change of conditions.


              Call: REGISTER( DestAddress, ResvID, SND-flag, RCV-flag,
                          [, DROP-flag] [, rsvpTTL] [, SenderTemplate] [, flowspec]
                                      [, UserCredentials] )  -> session-id

              This call initiates RSVP processing for the session
              (DestAddress, ResvID).  If successful, the call returns
              immediately with a local session identifier "session-id",
              which may be used in subsequent calls.  Following this
              call, an asynchronous ERROR or EVENT call (see below) may
              occur at any time.

              SND-flag should be set true if the host will send data,
              and RCV-flag should be set true if the host will receive
              data.  Setting neither true is an error.  The optional
              parameters DROP-flag, rsvpTTL, SenderTemplate, and
              Flowspec should be supplied only if SND-flag is true.

              DROP-flag indicates that session data packets that do not
              match any active filter in some node should be dropped at
              that node; otherwise, such packets will be forwarded using
              a best-effort QoS.  The rsvp-TTL parameter specifies the
              IP Time-to-Live field that will be used in PATH messages.
              The value of rsvp-TTL should match the TTL field to be
              sent in data packets, so they will have the same multicast

              A REGISTER call with SND-flag equals TRUE will initiate
              the transmission of PATH messages.


              Call: RESERVE( session-id, style [, DF-chan-count]
                               Flowspec-list, Filterspec-list)

              A receiver uses this call to make a resource reservation
              for the session registered as `session-id'.  The style

Zhang, Braden et al      Expires: January 1995                 [Page 45]

Internet Draft             RSVP Specification                  July 1994

              parameter is an integer index indicating the reservation
              style.  The DF-chan-count parameter, indicating the number
              of Dynamic Filter channels to be reserved, should only be
              included if the style is DF.

              The first RESERVE call will initiate the periodic
              transmission of RESV messages.  A later RESERVE call may
              be given to modify the parameters of the earlier call (but
              note that changing the reservations may result in
              admission control failure, depending upon the style).

              The RESERVE call returns immediately.  Following this
              call, an asynchronous ERROR or EVENT call may come at any


              Call: RELEASE( session-id )

              This call will terminate RSVP state for the session
              specified by session-id.  It will send appropriate
              "Teardown" messages and cease sending refreshes.

         Error Upcall

              Call: ERROR( ) -> session-id, error-type, error-code
                                      [, flowspec] [, filterspec]

              This upcall may occur asynchronously at any time after a
              REGISTER call and before a RELEASE call, to indicate an
              error.  The allowed values of error-type and error-code
              depend on whether the node is sending, receiving, or both.

              The ERROR upcall reporting an admission control failure to
              a receiver will specify in `flowspec' the flowspec that
              actually failed.  This may differ from the flowspec
              specified by this application in a RESERVE call, due to
              upstream merging with reservation requests from other

         Event Upcall

              Call: EVENT( ) -> session-id, info-type,
                                [, flowspec-list] [, filterspec-list]

              This upcall may occur asynchronously at any time after a
              REGISTER call and before a RELEASE call, to signal an
              event and to pass information to the application.

Zhang, Braden et al      Expires: January 1995                 [Page 46]

Internet Draft             RSVP Specification                  July 1994

              The `info-type' field indicates one of two possible event
              types.  A Path event indicates the receipt of a PATH
              message, indicating to the application that there is at
              least one active sender.  A Reservation event indicates
              the receipt of a RESV message, indicating to the
              application that there is at least one receiver.  Although
              these messages are repeatedly received, the API should
              make the corresponding asynchronous upcall to the
              application only on the first event, or when the
              information to be reported changes.


                 The precise form and function of the flowspec-list and
                 filterspec-list parameters are to be determined.

      3.6.3 RSVP/Traffic Control Interface

         In each router and host, enhanced QoS is achieved by a group of
         inter-related functions:  a packet Classifier, an admission
         control module, and a packet scheduler.  We group these
         functions together under the heading traffic control.  RSVP
         uses the interfaces in this section to invoke the traffic
         control functions.

         1.   Make a Reservation

              Call: Rhandle =  TCAddFlow( Flowspec, DropFlag,
              [SessionFilterspec [, SenderFilterspec]] )

              Returns an internal handle Rhandle for subsequent
              references to this reservation.

              This call passes Flowspec to admission control and returns
              an error code if Flowspec is malformed or if the requested
              resources are unavailable.  Otherwise, it establishes a
              new reservation channel corresponding to Rhandle, and if
              Filterspecs are supplied, installs a corresponding filter
              in the classifier.

              For FF reservation requests, RSVP knows about sharing and
              calls AddFlow only for distinct source pipes.

              For DF reservation requests: suppose that the RESV message
              specifies a Dynamic Reservation Count = D, and F flow
              descriptors, where 0 <= F <= D.  Then RSVP calls AddFlow D

Zhang, Braden et al      Expires: January 1995                 [Page 47]

Internet Draft             RSVP Specification                  July 1994

              times, and D - F of those calls have null filterspecs.

         2.   Switch a Channel

              Call: TCModFilter( Rhandle, [new Filterspec])

              This call replaces the filter without calling admission
              control.  It may replace an existing filter with no
              filter, modify an existing filter, or replace no filter by
              a filter.

         3.   Modify Flowspec

              Call: TCModFlowspec( Rhandle, oldFlowspec, newFlowspec)

              Here newFlowspec may be larger or smaller than

         4.   Delete Flow

              Call:  TCDeleteFlow( Rhandle )

              This call kills the reservation and reduces the reference
              count of, and deletes if the count is zero, any filter
              associated with this handle.

         5.   Initialize

              Call: TCInitialize( )

              This call is used when RSVP initializes its state, to
              clear out all existing classifier and/or packet scheduler

      3.6.4 RSVP/Routing Interface

         An RSVP implementation needs the following support from the
         packet forwarding and routing mechanism of the node.

         o    Promiscuous receive mode for RSVP messages

              Any datagram received for IP protocol 46 is to be diverted
              to the RSVP program for processing, without being

         o    Route discovery

Zhang, Braden et al      Expires: January 1995                 [Page 48]

Internet Draft             RSVP Specification                  July 1994

              RSVP must be able to discover the route(s) that the
              routing algorithm would have used for forwarding a
              specific datagram.

              GetUCRoute( DestAddress ) -> NextHop, Interface

              GetMCRoute( SrcAddress, DestAddress ) -> Interface

         o    Outgoing Link Specification

              RSVP must be able to force a (multicast) datagram to be
              sent on a specific outgoing virtual link, bypassing the
              normal routing mechanism.  A virtual link may be a real
              outgoing link or a multicast tunnel.

              This is necessary because RSVP may send different versions
              of outgoing PATH messages on different interfaces, for the
              same source and destination addresses.

         o    Discover (Virtual) Interface List

              RSVP must be able to learn what real and virtual
              interfaces exist.


   Lixia Zhang, Scott Shenker, Deborah Estrin, Dave Clark, Sugih Jamin,
   Shai Herzog, Steve Berson, Steve Deering, Bob Braden, and Daniel
   Zappala have all made contributions to the design of RSVP.  We are
   grateful to Jamin, Herzog, and Berson for prototype implementations.
   The original protocol concepts for RSVP arose out of discussions in
   meetings of the End-to-End Research Group.


[CSZ92]  Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time
    Applications in an Integrated Services Packet Network: Architecture
    and Mechanisms", Proc. SIGCOMM '92, Baltimore, MD, August 1992.

[ISInt93]  Braden, R., Clark, D., and S. Shenker, "Integrated Services
    in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and
    PARC, June 1994.

[IServ93]  Shenker, S., Clark, D., and L. Zhang, "A Service Model for an
    Integrated Services Internet", Work in Progress, October 1993.

[Partridge92]  Partridge, C., "A Proposed Flow Specification", RFC 1363,

Zhang, Braden et al      Expires: January 1995                 [Page 49]

Internet Draft             RSVP Specification                  July 1994

    BBN, September 1992.

[RSVP93]  Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.
    Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network,
    September 1993.

Security Considerations

   As noted in Section 2.1, the ability to reserve resources will create
   a requirement for authentication of users who request reservations.
   An authentication field has been included in this version of the
   protocol spec, but further study on its format and usage will be

Authors' Addresses

   Lixia Zhang
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304

   Phone: (415) 812-4415
   EMail: Lixia@PARC.XEROX.COM

   Bob Braden
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone: (310) 822-1511
   EMail: Braden@ISI.EDU

   Deborah Estrin
   Computer Science Department
   University of Southern California
   Los Angeles, CA 90089-0871

   Phone: (213) 740-4524
   EMail: estrin@USC.EDU

Zhang, Braden et al      Expires: January 1995                 [Page 50]

Internet Draft             RSVP Specification                  July 1994

   Shai Herzog

   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292
   Palo Alto, CA 94304

   Phone: (310) 822 1511
   EMail: Herzog@ISI.EDU

   Sugih Jamin
   Computer Science Department
   University of Southern California
   Los Angeles, CA 90089-0871

   Phone: (213) 740-6578
   EMail: jamin@catarina.usc.edu

Zhang, Braden et al      Expires: January 1995                 [Page 51]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/