[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                                            R. Braden, Ed.
Expiration: September 1995                                           ISI
File: draft-ietf-rsvp-spec-05.txt                                L.Zhang
                                                                    PARC
                                                               D. Estrin
                                                                     ISI
                                                               S. Herzog
                                                                     ISI
                                                                S. Jamin
                                                                     USC



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

                           March 24, 1995


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
   linebreak "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 Rim).

Abstract

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






Braden, Zhang, et al.  Expiration: September 1995               [Page 1]


Internet Draft             RSVP Specification                 March 1995


What's Changed Since Toronto IETF

This version of the document incorporates many of the protocol changes
agreed to at the December 1994 IETF meeting in San Jose.  The most major
changes are:


   o    The RSVP packet format has been reorganized to carry most data
        as typed variable-length objects.

   o    This generality includes provision for 16-byte IP6 addresses.

   o    Filter specs have been simplified.

   o    DF style has been moved to an Appendix, as experimental.

   o    UDP encapsulation has been included.

   o    OPWA has been included.

   o    The Drop flag has been eliminated.

   o    Session groups have been added.

   o    The routing of RERR messages has been changed.


1. Introduction

   This document defines RSVP, a resource reservation setup protocol
   designed for an integrated services Internet [RSVP93,ISInt93].

   A host uses the RSVP protocol to request a specific quality of
   service (QoS) from the network, on behalf of an application data
   stream.  RSVP is also used to deliver QoS requests to routers along
   the path(s) of the data stream and to maintain router and host state
   to provide the requested service.  This will generally (but not
   necessarily) require reserving resources along the data path.

   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.  RSVP operates on top of IP,
   occupying the place of a transport protocol in the protocol stack.
   However, like ICMP, IGMP, and routing protocols, RSVP does not
   transport application data but is rather an Internet control
   protocol.  As shown in Figure 1, an implementation of RSVP, like the
   implementations of routing and management protocols, will typically



Braden, Zhang, et al.  Expiration: September 1995               [Page 2]


Internet Draft             RSVP Specification                 March 1995


   execute in the background, not in the data forwarding path.

   RSVP is not itself a routing protocol; the RSVP daemon consults the
   local routing protocol(s) to obtain routes.  Thus, a host sends IGMP
   messages to join a multicast group, and it sends RSVP messages to
   reserve resources along the delivery path(s) from that group.  RSVP
   is designed to operate with existing and future unicast and multicast
   routing protocols.


               HOST                             ROUTER

    _________________________    RSVP   ______________________
   |                         |    .---------------.           |
   |  _______       ______   |   .     | ________  .   ______ |
   | |       |     |      |  |  .      ||        |  . |      ||  RSVP
   | |Applic-|     | RSVP <-----       ||Routing |   -> RSVP <------>
   | |  App  <----->daemon|  |         ||Protocol|    |daemon||
   | |       |     |      |  |         || daemon <---->      ||
   | |_______|     |___.__|  |         ||_ ._____|    |__.___||
   |===|===============v=====|         |===v=============v====|
   | data     ..........     |         |   .  ............    |
   |   |  ____v_   ____v____ |         |  _v__v_    _____v___ |
   |   | |Class-| |         ||   data  | |Class-|  |         ||  data
   |   |=> ifier|=> Packet  =============> ifier|==> Packet  |======>
   |     |______| |Scheduler||         | |______|  |Scheduler||
   |              |_________||         |           |_________||
   |_________________________|         |______________________|

                   Figure 1: RSVP in Hosts and Routers


   Each router that is capable of resource reservation passes incoming
   data packets to a packet classifier and then queues them as necessary
   in a packet scheduler.  The packet classifier determines the route
   and the QoS class for each packet.  The scheduler allocates a
   particular outgoing link for packet transmission, and it may also
   allocate other system resources such as CPU time or buffers.

   In order to efficiently accommodate heterogeneous receivers and
   dynamic group membership and to be consistent with IP multicast, RSVP
   makes receivers responsible for requesting resource reservations
   [RSVP93].  A QoS request, typically originating in a receiver host
   application, will be passed to the local RSVP implementation, shown
   as a user daemon in Figure 1.  The RSVP protocol is then used to pass
   the request to all the nodes (routers and hosts) along the reverse
   data path(s) to the data source(s).




Braden, Zhang, et al.  Expiration: September 1995               [Page 3]


Internet Draft             RSVP Specification                 March 1995


   At each node, the RSVP program applies a local decision procedure,
   called "admission control", to determine if it can supply the
   requested QoS.  If admission control succeeds, the RSVP program sets
   parameters to the packet classifier and scheduler to obtain the
   desired QoS.  If admission control fails at any node, the RSVP
   program returns an error indication to the application that
   originated the request.  We refer to the packet classifier, packet
   scheduler, and admission control components as "traffic control".

   RSVP is designed to scale well for very large multicast groups.
   Since the membership of a large group will be constantly changing,
   the RSVP design assumes that router state for traffic control will be
   built and destroyed incrementally.  For this purpose, RSVP uses "soft
   state" in the routers, in addition to receiver-initiation.

   RSVP protocol mechanisms provide a general facility for creating and
   maintaining distributed reservation state across a mesh of multicast
   or unicast delivery paths.  RSVP transfers reservation parameters as
   opaque data (except for certain well-defined operations on the data),
   which it simply passes to traffic control 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 Appendix
   A).

   In summary, RSVP has the following attributes:

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

   o    RSVP is simplex.

   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.

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



Braden, Zhang, et al.  Expiration: September 1995               [Page 4]


Internet Draft             RSVP Specification                 March 1995


   The remainder of this section describes the RSVP reservation
   services.  Section 2 presents an overview of the RSVP protocol
   mechanisms, while Section 3 gives examples of the services and
   mechanism.  Section 4 contains the functional specification of RSVP.
   Section 5 presents explicit message processing rules.

   1.1 Data Flows

      The set of data flows with the same unicast or multicast
      destination constitute a session. RSVP treats each session
      independently.  All data packets in a particular session are
      directed to the same IP destination address DestAddress, and
      perhaps to some further demultiplexing point defined in a higher
      layer (transport or application).  We refer to the latter as a
      "generalized destination port".

      DestAddress is the group address for multicast delivery, or the
      unicast address of a single receiver.  A generalized destination
      port could be defined by a UDP/TCP destination port field, by an
      equivalent field in another transport protocol, or by some
      application-specific information.  Although the RSVP protocol is
      designed to be easily extendible for greater generality, the
      present version uses only UDP/TCP ports as generalized ports.

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

















Braden, Zhang, et al.  Expiration: September 1995               [Page 5]


Internet Draft             RSVP Specification                 March 1995



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

                 Figure 2: Multicast Distribution Session



   1.2 Reservation Model

      An elementary RSVP reservation request consists of a "flowspec"
      together with a "filter spec"; this pair is called a "flow
      descriptor".  The flowspec specifies a desired QoS.  The filter
      spec (together with the DestAddress and the generalized
      destination port defining the session) defines the set of data
      packets -- the "flow" -- to receive the QoS defined by the
      flowspec.  The flowspec is used to set parameters to the packet
      scheduler in the node (assuming that admission control succeeds),
      while the filter spec is used to set parameters in the packet
      classifier.

      The flowspec in a reservation request will generally include a
      service type and two sets of numeric parameters: (1) an " Rspec"
      (R for `reserve'), which defines the desired per-hop reservation,
      and (2) a "Tspec" (T for `traffic'), which defines the parameters
      that may be used to police the data flow, i.e., to ensure it does
      not exceed its promised traffic level.

      The general RSVP reservation model allows filter specs to select
      arbitrary subsets of the packets in a given session.  Such subsets
      might be defined in terms of senders (i.e., sender IP address and
      generalized source port), in terms of a higher-level protocol, or
      generally in terms of any fields in any protocol headers in the
      packet.  For example, filter specs might be used to select
      different subflows in a hierarchically-encoded signal, by
      selecting on fields in an application-layer header.  However,
      considerations of both architectural purity and practical
      requirements have led to the decision that RSVP should use
      separate sessions for distinct subflows of hierarchically-encoded
      signals.  For multicast sessions, subflows can be distinguished by
      multicast destination address; for unicast sessions, they must be



Braden, Zhang, et al.  Expiration: September 1995               [Page 6]


Internet Draft             RSVP Specification                 March 1995


      distinguished by destination port.  As a result of these
      considerations, the present RSVP version includes a quite
      restricted definition of filter specs, selecting only on sender IP
      address and UDP/TCP port number, and on protocol id.  However, the
      design of the protocol would easily handle a more general
      definition in future versions.

      Any packets that are addressed to a particular session but do not
      match any of the filter specs for that session will be sent as
      best-effort traffic.  Under congested conditions, such packets are
      likely to experience long delays and may be dropped.  A receiver
      may wish to conserve network resources by explicitly asking the
      network to drop those data packets for which there is no
      reservation; however, such dropping should be performed by
      routing, not by RSVP.  Determining where packets get delivered
      should be a routing function; RSVP is concerned only with the QoS
      of those packets that are delivered by routing.

      RSVP reservation request messages originate at receivers and are
      passed upstream towards the sender(s).  (Note that this document
      always uses the directional terms "upstream" vs. "downstream",
      "previous hop" vs.  "next hop", and "incoming interface" vs
      "outgoing interface" with respect to the data flow direction).
      When an elementary reservation request is received at a node, the
      RSVP daemon takes two primary actions.

      1.   Make a reservation

           The flowspec and the filter spec are passed to traffic
           control.  Admission Control determines the admissibility of
           the request (if it's new); if it fails this test, the
           reservation is rejected and RSVP sends back an error message
           towards the responsible receiver(s).  If it passes, the
           flowspec is used to set up the packet scheduler for the
           desired QoS and the filter spec is used to set the packet
           classifier to select the appropriate data packets.

      2.   Forward reservation upstream.

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

      The reservation request that a node forwards upstream may differ
      from the request that it received, for two reasons.  First, it is
      possible (at least in theory) for the kernel to modify the
      flowspec hop-by-hop (although currently no realtime services do



Braden, Zhang, et al.  Expiration: September 1995               [Page 7]


Internet Draft             RSVP Specification                 March 1995


      this).  Second, reservations from different downstream branches of
      the multicast distribution tree(s) must be "merged" as
      reservations travel upstream.  Merging reservations is a necessary
      consequence of multicast distribution, which creates a single
      stream of data packets in a particular router from any Si,
      regardless of the set of receivers downstream.  The reservation
      for Si on a particular outgoing link L should be the "maximum" of
      the individual flowspecs from the receivers Rj that are downstream
      via link L.  Merging is discussed further in Section 2.3.

      For both of these primary actions, there are options controlled by
      the receiver making the reservation. These options are combined
      into a control variable called the reservation "style", which is
      discussed in section 1.3.  One option concerns the treatment of
      reservations for different senders within the same session:
      establish a "distinct" reservation for each upstream sender, or
      else "mix" all senders' packets into a single reservation.
      Another option controls the scope of the request: "unitary" (i.e.,
      a single specified sender), an explicit sender list, or a
      "wildcard" that implicitly selects all senders upstream of the
      given node.

      The basic RSVP reservation model is "one pass": a receiver sends a
      reservation request upstream, and each node in the path can only
      accept or reject the request.  This scheme provides no way to make
      end-to-end service guarantees; the QoS request is applied
      independently at each hop.  RSVP also supports an optional
      reservation model, known as " One Pass With Advertising" (OPWA)
      [Shenker94].  In OPWA, RSVP control packets sent downstream,
      following the data paths, are used to gather information on the
      end-to-end service that would result from a variety of possible
      reservation requests.  The results ("advertisements") are
      delivered by RSVP to the receiver host, and perhaps to the
      receiver application.  The information may then be used by the
      receiver to construct an appropriate reservation request.

   1.3 Reservation Styles

      Each RSVP reservation request specifies a "reservation style".
      The following reservation styles are defined in this version of
      the protocol.

      1.   Wildcard-Filter (WF) Style

           The WF style specifies the options: "mixing" reservation and
           " wildcard" reservation scope.  Thus, a WF-style reservation
           creates a single reservation into which flows from all
           upstream senders are mixed.  This reservation may be thought



Braden, Zhang, et al.  Expiration: September 1995               [Page 8]


Internet Draft             RSVP Specification                 March 1995


           of a shared "pipe", whose "size" is the largest of the
           resource requests for that link from all receivers,
           independent of the number of senders using it.  A WF-style
           reservation has wildcard scope, i.e., the reservation is
           propagated upstream towards all senders.  A WF-style
           reservation automatically extends to new senders to the
           session as they appear.

      2.   Fixed-Filter (FF) Style

           The FF style specifies the options: "distinct" reservation
           and a "unitary" reservation scope.  Thus, an elementary FF-
           style reservation request creates a distinct reservation for
           data packets from a particular sender, not mixing them with
           other senders' packets for the same session.

           The total reservation on a link for a given session is the
           total of the FF reservations for all requested senders.  On
           the other hand, FF reservations requested by different
           receivers Rj but selecting the same sender Si must
           necessarily be merged to share a single reservation in a
           given node.

      WF reservations are appropriate for those multicast applications
      whose application-specific constraints make it unlikely that
      multiple data sources will transmit simultaneously. One example is
      audio conferencing, where a limited number of people talk at once;
      each receiver might issue a WF reservation request for twice one
      audio channel (to allow some over-speaking).  On the other hand,
      the FF style, which creates independent reservations for the flows
      from different senders, is appropriate for video signals.

      The WF and FF styles are incompatible and cannot be combined
      within a session.  Other reservation styles may be defined in the
      future (see Appendix C).

2. RSVP Protocol Mechanisms

   2.1 RSVP Messages

      There are two fundamental RSVP message types, RESV messages and
      PATH messages.

      Each receiver host sends RSVP reservation request (RESV) messages
      towards the senders.  These reservation messages must follow in
      reverse the routes the data packets will use, all the way upstream
      to the senders within the scope.  RESV messages are delivered to
      the sender hosts, so that the hosts can set up appropriate traffic



Braden, Zhang, et al.  Expiration: September 1995               [Page 9]


Internet Draft             RSVP Specification                 March 1995


      control parameters for the first hop.  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.


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

                           Figure 3: RSVP Messages


      Each sender transmits RSVP PATH messages forward along the uni-
      /multicast routes provided by the routing protocol(s); see Figure
      3.  These "Path" messages store path state in each node.  Path
      state is used by RSVP to route the RESV messages hop-by-hop in the
      reverse direction.  (In the future, some routing protocols may
      supply reverse path forwarding information directly, without path
      state).

      PATH messages may also carry the following information:

      o    Sender Template

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

      o    Tspec

           The PATH message may optionally carry a flowspec containing
           only a Tspec, defining an upper bound on the traffic level
           that the sender will generate.  This Tspec can be used by
           RSVP to prevent over-reservation (and perhaps unnecessary
           Admission Control failure) on the non-shared links starting
           at the sender.

      o    Adspec

           The PATH message may carry a package of OPWA advertising
           information, known as an "Adspec".




Braden, Zhang, et al.  Expiration: September 1995              [Page 10]


Internet Draft             RSVP Specification                 March 1995



       Previous       Incoming           Outgoing             Next
       Hops           Interfaces         Interfaces           Hops

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

                         Figure 4: Router Using RSVP



      Figure 4 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).  The same physical interface may act in both the
      incoming and outgoing roles (for different data flows but the same
      session).

      As illustrated in Figure 4, there may be multiple previous hops
      and/or next hops through a given physical interface.  This may
      result from the connected network being a shared medium or from
      the existence of non-RSVP routers in the path to the next RSVP hop
      (see Section 2.6).  An RSVP daemon must preserve the next and
      previous hop addresses in its reservation and path state,
      respectively.  A RESV message is sent with a unicast destination
      address, the address of a previous hop.   PATH messages, on the
      other hand, are sent with the session destination address, unicast
      or multicast.

      Although multiple next hops may send reservation requests through
      the same physical interface, the final effect should be to install
      a reservation on that interface, which is defined by an effective
      flowspec.  This effective flowspec will be the "maximum" of the
      flowspecs requested by the different next hops.  In turn, a RESV
      message forwarded to a particular previous hop carries a flowspec
      that is the "maximum" over the effective reservations on the



Braden, Zhang, et al.  Expiration: September 1995              [Page 11]


Internet Draft             RSVP Specification                 March 1995


      corresponding outgoing interfaces.  Both cases represent merging,
      which is discussed further below.

      There are a number of ways for a new reservation request to fail
      in a given node.

      1.   There may be no matching path state (i.e., the scope may
           empty), which would prevent the reservation being propagated
           upstream.

      2.   Its style may be incompatible with the style(s) of existing
           reservations for the same session on the same outgoing
           interface, so an effective flowspec cannot be computed.

      3.   Its style may be incompatible with the style(s) of
           reservations that exist on other outgoing interfaces but will
           be merged with this reservation when a refresh message to
           create a refresh message for the previous hop.

      4.   The effective flowspec may fail admission control.

      In any of these cases, an error message is returned to the
      receiver(s) responsible for the message, but any existing
      reservation is left in place.  This prevents a new, very large,
      reservation from disrupting the existing QoS by merging with an
      existing reservation and then failing admission control.

   2.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.  The state is deleted if no
      refreshes arrive before the expiration of a "cleanup timeout"
      interval; it may also be deleted as the result of an explicit
      "Teardown" message.  It is not necessary (although it may be
      desirable, since the resources being consumed may be "valuable"),
      to explicitly tear down an old reservation.

      When a route changes, the next PATH message will initialize the
      path state on the new route, and future RESV messages will
      establish reservation state, while the state on the now-unused
      segment of the route will time out.  Thus, whether a message is
      "new" or a "refresh" is determined separately at each node,
      depending upon the existence of state at that node.  (This
      document uses 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.)




Braden, Zhang, et al.  Expiration: September 1995              [Page 12]


Internet Draft             RSVP Specification                 March 1995


      In addition to the cleanup timeout, there is a "refresh timeout"
      period.  As messages arrive, the RSVP daemon checks them against
      the existing state; if it matches, the cleanup timeout timer on
      the state is reset and the message is dropped.  At the expiration
      of each refresh timeout period, RSVP scans its state to build and
      forward PATH and RESV refresh messages to succeeding hops.

      RSVP sends its messages as IP datagrams without reliability
      enhancement.  Periodic transmission of refresh messages by hosts
      and routers is expected to replace any lost RSVP messages.  To
      tolerate K successive packet losses, the effective cleanup timeout
      must be at least K times the refresh timeout.  In addition, the
      traffic control mechanism in the network should be statically
      configured to grant high-reliability service to RSVP messages, to
      protect RSVP messages from congestion losses.

      In steady state, refreshing is performed hop-by-hop, which allows
      merging and packing as described in the next section.  However, if
      the received state differs from the stored state, the stored state
      is updated.  Furthermore, if the result will be to modify the
      refresh messages to be generated, these refresh messages must be
      generated and forwarded immediately.  This will result in changes
      propagating end-to-end without delay.  However, propagation of a
      change stops when and if it reaches a point where merging causes
      no resulting state change; this minimizes RSVP control traffic due
      to changes, and is essential for scaling to large multicast
      groups.

      The "soft" router state maintained by RSVP is dynamic; to change
      the set of senders Si or receivers Rj or to change any QoS
      request, a host simply starts sending revised PATH and/or RESV
      messages.  The result should be the appropriate adjustment in the
      distributed RSVP state, and immediate propagation to the
      succeeding nodes.

      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
      independently.  Management of RSVP state is complex because there
      may not be 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 values received in multiple control messages.




Braden, Zhang, et al.  Expiration: September 1995              [Page 13]


Internet Draft             RSVP Specification                 March 1995


   2.3 Merging and Packing

      A previous section explained that reservation requests in RESV
      messages are necessarily merged, to match the multicast
      distribution tree.  As a result, only the essential (i.e., the
      "largest") reservation requests are forwarded, once per refresh
      period.  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.


      Although flowspecs are opaque to RSVP, an RSVP daemon must be able
      to calculate the "largest" of a set of flowspecs.  This is
      required both to calculate the effective flowspec to install on a
      given physical interface (see the discussion in connection with
      Figure 4), and to merge flowspecs when sending a refresh message
      upstream.  Since flowspecs are generally multi-dimensional vectors
      (they contain both Tspec and Rspec components, each of which may
      itself be multi-dimensional), they are not strictly ordered.  When
      it cannot take the larger of two flowspecs, RSVP must compute and
      use a third flowspec that is at least as large as each, i.e., a
      "least upper bound" (LUB).  It is also possible for two flowspecs
      to be incomparable, which is treated as an error.  The definition
      and implementation of the rules for comparing flowspecs are
      outside RSVP proper, but they are defined as part of the service
      templates.

      For protocol efficiency, RSVP also allows multiple sets of path
      (or reservation) information for the same session to be "packed"
      into a single PATH (or RESV) message, respectively.  (For
      simplicity, the protocol prohibits packing different sessions into
      the same RSVP message).

   2.4 Teardown

      RSVP teardown messages remove path and reservation state without
      waiting for the cleanup timeout period, as an optimization to
      release resources quickly.  Although teardown messages (like other
      RSVP messages) are not delivered reliably, the state will time out
      even if it is not explicitly deleted.

      A teardown request may be initiated either by an application in an
      end system (sender or receiver), or by a router as the result of
      state timeout.  A router may also initiate a teardown message as
      the result of router or link failures detected by the routing
      protocol.  Once initiated, a teardown request should be forwarded



Braden, Zhang, et al.  Expiration: September 1995              [Page 14]


Internet Draft             RSVP Specification                 March 1995


      hop-by-hop without delay.

      To increase the reliability of teardown, Q copies of any given
      teardown message can be sent.  Note that a node cannot actually
      delete the state being torn down until it has sent Q Teardown
      messages; it must place the state 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.  If one
      or more Teardown message 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, the longest time to delete
      state will seldom exceed one refresh timeout period.

      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.  A
      RTEAR message tears down reservation state and travels towards all
      senders upstream from its point of initiation.  A PTEAR (RTEAR)
      message may be conceptualized as a reversed-sense Path message
      (Resv message, respectively).

      A teardown message deletes the specified state in the node where
      it is received.  Like any other state change, this will be
      propagated immediately to the next node, but only if it represents
      a change.  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.
      The change will be propagated as a new teardown message if the
      result has been to remove all state for this session at this node.
      However, the result may simply be to change the propagated
      information; thus, the receipt of a RTEAR message may result in
      the immediate forwarding of a modified RESV refresh message.

      Deletion of path state, whether as the result of a teardown
      message or because of timeout, may force adjustments in order in
      related reservation state to maintain consistency in the local
      node.  For example, when a PTEAR deletes the path state for a
      sender S, the adjustment in reservation depends upon the style: if
      the style is WF and S is the only sender to the session, delete
      the reservation; if the style is FF, delete only reservations for
      sender S.  These reservation changes should not trigger an
      immediate RESV refresh message, since the teardown message will
      have already made the required changes upstream.  However, at the
      node in which an RTEAR message stops, the change of reservation
      state may trigger a RESV refresh starting at that node.



Braden, Zhang, et al.  Expiration: September 1995              [Page 15]


Internet Draft             RSVP Specification                 March 1995


   2.5 Security

      There are two distinct types of security concerns in RSVP.

      1.   Protecting RSVP Message Integrity

           It may be necessary to ensure the integrity of RSVP messages
           against corruption or spoofing, hop by hop.  RSVP messages
           have an optional integrity field that can be created and
           verified by neighboring RSVP nodes.

      2.   Authenticating Reservation Requests

           RSVP-mediated resource reservations may reserve network
           resources, providing special treatment for a particular set
           of users.  Administrative mechanisms will be necessary to
           control who gets privileged service and to collect billing
           information.  These mechanisms may require secure
           authentication of senders and/or receivers responsible for
           the reservation.  RSVP messages may contain credential
           information to verify user identity.

      The RSVP packet formats provide for both; see Section 4.

   2.6 Automatic RSVP Tunneling

      It is impossible to deploy RSVP (or any new protocol) at the same
      moment throughout the entire Internet.  Furthermore, RSVP may
      never be deployed everywhere.  RSVP must therefore provide correct
      protocol operation even when two RSVP-capable routers are joined
      by an arbitrary "cloud" of non-RSVP routers.  Of course, an
      intermediate cloud that does not support RSVP is unable to perform
      resource reservation, so 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.

      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
      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 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.



Braden, Zhang, et al.  Expiration: September 1995              [Page 16]


Internet Draft             RSVP Specification                 March 1995


      Automatic tunneling is not perfect; in some circumstances it may
      distribute path information to RSVP-capable routers not included
      in the data distribution paths, which may create unused
      reservations at these routers.  This is because PATH messages
      carry the IP source address of the previous hop, not of the
      original sender, and multicast routing may depend upon the source
      as well as the destination address.  This can be overcome by
      manual configuration of the neighboring RSVP programs, when
      necessary.

   2.7 Session Groups

      Section 1.2 explained that a distinct destination address, and
      therefore a distinct session, will be used for each of the
      subflows in a hierarchically encoded flow.  However, these
      separate sessions are logically related.  For example it may be
      necessary to pass reservations for all subflows to Admission
      Control at the same time (since it would be nonsense to admit high
      frequency components but reject the baseband component of the
      session data).  Such a logical grouping is indicated in RSVP by
      defining a "session group", an ordered set of sessions.

      To declare that a set of sessions form a session group, a receiver
      includes a data structure we call a SESSION_GROUP object in the
      RESV message for each of the sessions.  A SESSION_GROUP object
      contains four fields: a reference address, a session group ID, a
      count, and a rank.

      o    The reference address is an agreed-upon choice from among the
           DestAddress values of the sessions in the group, for example
           the smallest numerically.

      o    The session group ID is used to distinguish different groups
           with the same reference address.

      o    The count is the number of members in the group.

      o    The rank, an integer between 1 and count, is different in
           each session of the session group.

      The SESSION_GROUP objects for all sessions in the group will
      contain the same values of the reference address, the session
      group ID, and the count value.  The rank values establishes the
      desired order among them.

      If RSVP at a given node receives a RESV message containing a
      SESSION_GROUP object, it should wait until RESV messages for all
      `count' sessions have appeared (or until the end of the refresh



Braden, Zhang, et al.  Expiration: September 1995              [Page 17]


Internet Draft             RSVP Specification                 March 1995


      cycle) and then pass the RESV requests to Admission Control as a
      group.  It is normally expected that all sessions in the group
      will be routed through the same nodes.  However, if not, only a
      subset of the session group reservations may appear at a given
      node; in this case, the RSVP should wait until the end of the
      refresh cycle and then perform Admission Control on the subset of
      the session group that it has received.  The rank values will
      identify which are missing.

      Note that routing different sessions of the session group
      differently will generally result in delays in establishing or
      rejecting the desired QoS.  A "bundling" facility could be added
      to multicast routing, to force all sessions in a session group to
      be routed along the same path.

   2.8 Host Model

      Before a session can be created, the session identification,
      comprised of DestAddress and perhaps the generalized destination
      port, 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 following events happen at the end systems.

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

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

      H3   A receiver listens for PATH messages.

      H4   A receiver starts sending appropriate RESV messages,
           specifying the desired flow descriptors, using RSVP.

      H5   A sender starts sending data packets.

      There are several synchronization considerations.

      o    Suppose that a new sender starts sending data (H5) but no
           receivers have joined the group (H1).  Then 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 (H5), and there are



Braden, Zhang, et al.  Expiration: September 1995              [Page 18]


Internet Draft             RSVP Specification                 March 1995


           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 (H5) (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 4.6.1 discusses the general requirements and
      presents a generic API.

3. Examples

   We use the following notation for a RESV message:

   1.   Wildcard-Filter

        WF( *{Q})

        Here "*{Q}" represents a Flow Descriptor with a "wildcard" scope
        (choosing all senders) and a flowspec of quantity Q.

   2.   Fixed-Filter

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

        A list of (sender, flowspec) pairs, i.e., flow descriptors,
        packed into a single RESV message.

   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.

   Figure 5 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 5, we must also specify the



Braden, Zhang, et al.  Expiration: September 1995              [Page 19]


Internet Draft             RSVP Specification                 March 1995


   multicast routing within this node.  Assume first that data packets
   (hence, PATH messages) from each Si shown in Figure 5 is routed to
   both outgoing interfaces.  Under this assumption, Figures 6 and 7
   illustrate Wildcard-Filter reservations and Fixed-Filter
   reservations, respectively.

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

                      Figure 5: Router Configuration


   In Figure 6, 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 largest flowspec is forwarded upstream to each previous hop.


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

              Figure 6: Wildcard-Filter Reservation Example 1



   Figure 7 shows Fixed-Filter style reservations.  The flow descriptors
   for senders S2 and S3, received from outgoing interfaces (c) and (d),
   are packed into the message forwarded to previous hop b.  On the
   other hand, the two different flow descriptors for sender S1 are
   merged into the single message FF( S1{3B} ), which is sent to
   previous hop (a), For each outgoing interface, there is a private



Braden, Zhang, et al.  Expiration: September 1995              [Page 20]


Internet Draft             RSVP Specification                 March 1995


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


                       |
         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 7: Fixed-Filter Reservation Example



   The two 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 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 case.





Braden, Zhang, et al.  Expiration: September 1995              [Page 21]


Internet Draft             RSVP Specification                 March 1995



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

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





































Braden, Zhang, et al.  Expiration: September 1995              [Page 22]


Internet Draft             RSVP Specification                 March 1995


4. RSVP Functional Specification

   4.1 RSVP Message Formats

      All RSVP messages consist of a common header followed by a
      variable number of variable-length typed "objects" using a common
      structure.  The subsections that follow define the formats of the
      common header, the object structures, and each of the RSVP message
      types.  For each RSVP message type, there is a set of rules for
      the permissible ordering and choice of object types.  These rules
      are specified using Backus-Naur Form (BNF) augmented with square
      brackets surrounding optional sub-sequences.

      4.1.1 Common Header

                0             1              2             3
         +-------------+-------------+-------------+-------------+
         | Vers | Type |    Flags    |       Message Length      |
         +-------------+-------------+-------------+-------------+
         |       RSVP Checksum       |        Object Count       |
         +-------------+-------------+-------------+-------------+



         The common header fields are as follows:

         Vers

              Protocol version number.  This is version 2.

         Type

              1 = PATH

              2 = RESV

              3 = PERR

              4 = RERR

              5 = PTEAR

              6 = RTEAR

         Flags

              0x01 = Entry-Police




Braden, Zhang, et al.  Expiration: September 1995              [Page 23]


Internet Draft             RSVP Specification                 March 1995


                   This flag should be on in a PATH message sent by an
                   RSVP daemon in a sender host.  The first RSVP node
                   that finds the flag on in a PATH message (i.e., the
                   first-[RSVP-]hop router) should institute policing
                   for the flow(s) described in this message.  This flag
                   should never be forwarded in PATH refresh messages.

              0x02 = LUB-Used

                   This flag is described below in the section on Error
                   Messages.

         Message Length

              The total length of this RSVP message, including this
              common header and the objects included in Object Count.

         RSVP Checksum

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

         Object Count

              Count of variable-length objects that follow.

      4.1.2 Object Formats

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

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


         An object header has the following fields:

         Length

              Total length in bytes.  Must always be a multiple of 4,
              and at least 4.




Braden, Zhang, et al.  Expiration: September 1995              [Page 24]


Internet Draft             RSVP Specification                 March 1995


         Class

              Object class.  In this document, the names of object
              classes are capitalized.

              0 = NULL

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

              1 = SESSION

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

              2 = SESSION_GROUP

                   When present, defines a session group, a set of
                   related sessions whose reservation requests should be
                   passed collectively to Admission Control.

              3 = RSVP_HOP

                   Carries the IP address of the RSVP-capable node that
                   sent this message.  This document refers to a
                   RSVP_HOP object as a PHOP ("previous hop") object for
                   downstream messages or as a NHOP ("next hop") object
                   for upstream messages.

              4 = STYLE

                   Defines the reservation style plus style-specific
                   information that is not a FLOWSPEC or FILTER_SPEC
                   object, in a RESV message.

              5 = FLOWSPEC

                   Defines a desired QoS, in a RESV message.

              6 = FILTER_SPEC

                   Defines a subset of session data packets that should
                   receive the desired QoS (specified by an FLOWSPEC



Braden, Zhang, et al.  Expiration: September 1995              [Page 25]


Internet Draft             RSVP Specification                 March 1995


                   object), in a RESV message.

              7 = SENDER_TEMPLATE

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

              8 = SENDER_TSPEC

                   Defines the traffic characteristics of a sender's
                   data stream, in a PATH message.

              9 = ADVERT

                   Carries an Adspec containing OPWA data, in a PATH
                   message.

              10 = TIME_VALUES

                   If present, contains values for the refresh period R
                   and the state time-to-live T (see section 4.5), to
                   override the default values of R and T.

              11 = ERROR_SPEC

                   Specifies an error, in a PERR or RERR message.

              12 = CREDENTIAL

                   Contains user credential and/or information for
                   policy control and/or accounting.

              13 = INTEGRITY

                   Contains a cryptographic data to authenticate the
                   originating node, and perhaps verify the contents, of
                   this RSVP message.

         C-Type

              Object type; unique within Class.  Values defined in
              Appendix A.

         The Class and C-Type fields may be used together as a 16-bit
         number to define a unique type for each object.

         The formats of specific object types are defined in Appendix A.



Braden, Zhang, et al.  Expiration: September 1995              [Page 26]


Internet Draft             RSVP Specification                 March 1995


      4.1.3 Path Message

         PATH messages carry information from senders to receivers along
         the same paths, and using the same uni-/multicast routes, as
         the data packets.  The IP destination address of a PATH message
         is the DestAddress for the session, and the source address is
         an address of the node that sent the message (if possible, the
         address of the particular interface through which it was sent).

         The format of a PATH message is as follows:

             <Path Message> ::= <Common Header> <SESSION> <RSVP_HOP>

                                     [ <INTEGRITY> ]  [ <TIME_VALUES> ]

                                     <sender descriptor list>

             <sender descriptor list> ::= <empty > |

                               <sender descriptor list> <sender descriptor>

             <sender descriptor> ::= [ <CREDENTIAL> ]  <SENDER_TEMPLATE>

                                     [ <SENDER_TSPEC> ]  [ <ADVERT> ]


         Each sender descriptor defines a sender, and the sender
         descriptor list allows multiple sender descriptors to be packed
         into a PATH message.  For each sender in the list, the
         SENDER_TEMPLATE object defines the format of data packets, the
         SENDER_TSPEC object may specify the traffic flow, and the
         CREDENTIAL object may specify the user credentials.  There may
         also be an ADVERT object carrying advertising (OPWA) data.

         Each sender host must periodically send a PATH message
         containing the sender descriptor(s) describing its own data
         stream(s), for a given session.  Each sender descriptor is
         forwarded and replicated as necessary to follow the delivery
         path(s) for a data packet from the same sender, finally
         reaching the applications on all receivers (except not a
         receiver included in the sender process).

         At each node, a route must be computed independently for each
         sender descriptors being forwarded.  These routes, obtained
         from the uni/multicast routing table, generally depend upon the
         (sender host address, DestAddress) pairs, and consist of a list
         of outgoing interfaces.  Then the descriptors being forwarded
         through the same outgoing interface can be packed into as few



Braden, Zhang, et al.  Expiration: September 1995              [Page 27]


Internet Draft             RSVP Specification                 March 1995


         PATH messages as possible.  Note that multicast routing of path
         information is based on the sender address(es) from the sender
         descriptors, not the IP source address; this is necessary to
         prevent routing loops; see Section 4.3.  PHOP (i.e., the
         RSVP_HOP object) of each PATH message should contain the IP
         source address, the interface address through which the message
         is sent.

         PATH messages are processed at each node they reach to create
         path state, which includes SENDER_TEMPLATE object and possibly
         CREDENTIAL, SENDER_TSPEC, and ADVERT objects.  If an error is
         encountered while processing a PATH message, a PERR message is
         sent to all senders implied by the SENDER_TEMPLATEs in the
         sender descriptor list.

      4.1.4 Resv Messages

         RESV messages carry reservation requests hop-by-hop from
         receivers to senders, along the reverse paths of data flow for
         the session.  The IP destination address of a RESV message is
         the unicast address of a previous-hop node, obtained from the
         path state.  The Next Hop address (in the RSVP_HOP object)
         should be the IP address of the (incoming) interface through
         which the RESV message is sent. The IP source address is an
         address of the node that sent the message (if possible, the
         address of the particular interface through which it was sent).

         The permissible sequence of objects in a RESV message depends
         upon the reservation style specified in the STYLE object.
         Currently, object types Style-WF and Style-FF of class STYLE
         are defined (see Appendix A).

         The RESV message format is as follows:

             <Resv Message> ::= <Common Header> <SESSION>

                                     [ <SESSION_GROUP> ]  <RSVP_HOP>

                                     [ <INTEGRITY> ] [ <TIME_VALUES> ]

                                     [ <CREDENTIAL> ]

                                     <style-specific tail>

             <style-specific-tail> ::=

                         <Style-WF> [ <FILTER_SPEC> ]  <FLOWSPEC> |




Braden, Zhang, et al.  Expiration: September 1995              [Page 28]


Internet Draft             RSVP Specification                 March 1995


                         <Style-FF> <flow descriptor list>

             <flow descriptor list> ::= <empty> |

                         <flow descriptor list> <FILTER_SPEC> <FLOWSPEC>


         The reservation scope, i.e., the set of senders towards which a
         particular reservation is to be forwarded, is determined by
         matching FILTER_SPEC objects against the path state created
         from SENDER_TEMPLATE objects, considering any wildcards that
         may be present.

      4.1.5 Error Messages

         There are two types of RSVP error messages:

         o    PERR messages result from PATH messages and travel towards
              senders.  PERR messages are routed hop-by-hop like RESV
              messages; at each hop, the IP destination address is the
              unicast address of a previous hop.

         o    RERR messages result from RESV messages and travel hop-
              by-hop towards the appropriate receivers, routed by the
              reservation state.  At each hop, the IP destination
              address is the unicast address of a next-hop node.
              Routing is discussed below.

         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 messages.


             <PathErr message> ::= <Common Header> <SESSION> <RSVP_HOP>

                                       [ <INTEGRITY> ]  <ERROR_SPEC>

                                       <sender descriptor>

             <sender descriptor list> ::= (see earlier definition)


             <ResvErr Message> ::= <Common Header> <SESSION> <RSVP_HOP>

                                       [ <INTEGRITY> ]  <ERROR_SPEC>

                                       [ <CREDENTIAL> ] <style-specific tail>




Braden, Zhang, et al.  Expiration: September 1995              [Page 29]


Internet Draft             RSVP Specification                 March 1995


             <style-specific tail> ::= (see earlier definition)



         The ERROR_SPEC specifies the error.  It includes the IP address
         of the node that detected the error, called the Error Node
         Address.

         When a PATH or RESV message has been "packed" with multiple
         sets of elementary parameters, the RSVP implementation should
         process each set independently and return a separate error
         message for each that is in error.

         An error message may be duplicated and forwarded unchanged.  In
         general, error messages should be delivered to the applications
         on all the session nodes that (may have) contributed to this
         error.

         o    A PERR message is forwarded to all previous hops for all
              senders listed in the Sender Descriptor List.

         o    The node 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.

              In succeeding hops, the routing of a RERR message depends
              upon its style and upon routing.  In general, a RERR
              message is sent out some subset of the outgoing interfaces
              specified for multicast routing, using Error Node Address
              as the source address and DestAddress as the destination.
              (This rule is necessary to prevent packet loops; see
              Section 4.3 below).  Within this set of outgoing
              interfaces, a RERR message is sent only to next hop(s)
              whose RESV message(s) created the error; this in turn
              depends upon the merging of flowspecs.  Assume that a
              reservation whose error is being reported was formed by
              merging two flowspecs Q1 and Q2 from different next hops.

              -    If Q1 = Q2, the error message should be forwarded to
                   both next hops.

              -    If Q1 < Q2, the error message should be forwarded
                   only to the next hop for Q2.

              -    If Q1 and Q2 are incomparable, the error message
                   should be forwarded to both next hops, and the LUB
                   flag should be turned on.




Braden, Zhang, et al.  Expiration: September 1995              [Page 30]


Internet Draft             RSVP Specification                 March 1995


              The ERROR_SPEC and the LUB-flag should be delivered to the
              receiver application.  In the case of an Admission Control
              error, the style-specific tail will contain the FLOWSPEC
              object that failed.  If the LUB-flag is off, this should
              be the same as a FLOWSPEC in a RESV message sent by this
              application; otherwise, they may differ.

              An error in a FILTER_SPEC object in a RESV message will
              normally be detected at the first RSVP hop from the
              receiver application, i.e., within the receiver host.
              However, an admission control failure caused by a FLOWSPEC
              or a CREDENTIAL object may be detected anywhere along the
              path(s) to the sender(s).

      4.1.6 Teardown Messages

         There are two types of RSVP Teardown message, PTEAR and RTEAR.

         o    PTEAR messages delete path state (which in turn may delete
              reservations state) and travel towards all receivers that
              are downstream from the point of initiation.  PTEAR
              messages are routed like PATH messages, and their IP
              destination address is DestAddress for the session.

         o    RTEAR messages delete reservation state and travel towards
              all matching senders upstream from the point of teardown
              initiation.  RTEAR message are routed like RESV messages,
              and their IP destination address is the unicast address of
              a previous hop.

             <PathTear Message> ::= <Common Header> <SESSION> <RSVP HOP>

                                         [ <INTEGRITY> ]

                                         <sender descriptor list>

             <sender descriptor list> ::= (see earlier definition)

             <ResvTear Message> ::= <Common Header> <SESSION> <RSVP HOP>

                                         [ <INTEGRITY> ]  [ <CREDENTIAL> ]

                                         <style-specific tail>

             <style-specific tail> ::= (see earlier definition)


         Flowspec objects in the style-specific tail of a RTEAR message



Braden, Zhang, et al.  Expiration: September 1995              [Page 31]


Internet Draft             RSVP Specification                 March 1995


         will be ignored and may be omitted.

         If the state being deleted was created with user credentials
         from a CREDENTIAL field, then the matching PTEAR or RTEAR
         message must include matching CREDENTIAL field(s).

         [There is a problem here: tearing down path state may
         implicitly delete reservation state.  But a PTEAR message does
         not have credentials for the reservation state, only for the
         path state.  Some argue that a CREDENTIAL may not be needed in
         teardown messages, on the assumption that false teardown
         messages can be injected only with the collusion of routers
         along the data path, and in that case, the colluding router can
         just as well stop delivering the RESV messages, which will have
         the same effect.]

   4.2 Sending RSVP Messages

      RSVP messages are sent hop-by-hop between RSVP-capable routers as
      "raw" IP datagrams, protocol number 46.  Raw IP datagrams are
      similarly intended to be used between an end system and the
      first/last hop router; however, it is also possible to encapsulate
      RSVP messages as UDP datagrams for end-system communication, as
      described in Appendix C.  UDP encapsulation will simplify
      installation of RSVP on current end systems, particularly when
      firewalls are in use.

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

      An RSVP PATH or RESV message consists of a small root segment
      followed by a variable-length list of objects, which may overflow
      the capacity of one datagram.  IP fragmentation is inadvisable,
      since it has bad error characteristics; 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
      needed.

      Since RSVP messages are normally expected to be generated and sent
      hop-by-hop, their MTU should be determined by the MTU of each
      interface.




Braden, Zhang, et al.  Expiration: September 1995              [Page 32]


Internet Draft             RSVP Specification                 March 1995


      [There may be rare instances in which this does not work very
      well, and in which manual configuration would not help.  The
      problem case is an interface connected to a non-RSVP cloud in
      which some particular link far away has a smaller MTU.  This would
      affect only those sessions that happened to use that link.
      Proper solution to this case would require MTU discovery
      separately for each interface and each session, which is a very
      large amount of machinery and some overhead for a rare (?) case.
      Best approach seems to be to rely on IP fragmentation and
      reassembly for this case.]

   4.3 Avoiding RSVP Message Loops

      We must ensure that the rules for forwarding RSVP control messages
      avoid looping.  In steady state, PATH and RESV messages are
      forwarded on each hop only once per refresh period.  This avoids
      directly looping packets, but there is still the possibility of an
      " auto-refresh" loop, clocked by the refresh period.  The effect
      of such a loop is to keep state active "forever", even if the end
      nodes have ceased refreshing it (but the state will be deleted
      when the receivers leave the multicast group and/or the senders
      stop sending PATH messages).

      In addition, error and teardown messages are forwarded immediately
      and are therefore subject to direct looping.

      PATH messages are forwarded using routes determined by the
      appropriate routing protocol.  For routing that is source-
      dependent (e.g., some multicast routing algorithms), the RSVP
      daemon must route each sender descriptor separately using the
      source addresses found in the SENDER_TEMPLATE objects.  This
      should ensure that there will be no auto-refresh loops of PATH
      information, even in a topology with cycles.

      Since PATH messages don't loop, they create path state defining a
      loop-free reverse path to each sender.  As a result, RESV and
      RTEAR messages directed to particular senders cannot loop.  PERR
      messages are always directed to particular senders and therefore
      cannot loop.  However, there is a potential auto-refresh problem
      for RESV, RTEAR, and RERR messages with wildcard scope, as we now
      discuss.

      If the topology has no loops, then auto-refresh can be avoided,
      even for wildcard scope, with the following rule:


         A reservation request received from next hop N must not be
         forwarded to N.



Braden, Zhang, et al.  Expiration: September 1995              [Page 33]


Internet Draft             RSVP Specification                 March 1995


      This rule is illustrated in Figure 10, which shows a transit
      router with one sender and one receiver on each interface (and
      assumes one next/previous hop per interface).  Interfaces a and c
      are both outgoing and incoming interfaces for this session.  Both
      receivers are making wildcard-scope reservations, in which the
      RESV messages are forwarded to all previous hops for senders in
      the group, with the exception of the next hop from which they
      came.  These result in independent reservation requests in the two
      directions, without an auto-refresh loop.

                         ________________
                      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: Avoiding Auto-Refresh in Non-Looping Topology


      However, further effort is needed to prevent auto-refresh loops
      from wildcard-scope reservations in the presence of cycles in the
      topology.  [TBD!!].

      We treat routing of RERR messages as a special case.  They are
      sent with unicast addresses of next hops, but the multicast
      routing is used to prevent loops.  As explained above, RERR
      messages are forwarded to a subset of the multicast tree to
      DestAddress, rooted at the node on which the error was discovered.
      Since multicast routing cannot create loops, this will prevent
      loops for RERR messages.

      [Open question about Figure 10: should it be possible to have
      incompatible reservation styles on the two interfaces?  For
      example, if R1 requests a WF reservation and R2 requests a FF
      reservation, it is logically possible to make the corresponding
      reservations on the two different interfaces.  The current



Braden, Zhang, et al.  Expiration: September 1995              [Page 34]


Internet Draft             RSVP Specification                 March 1995


      implementation does NOT allow this; instead, it prevents mixing of
      incompatible styles in the same session on a node, even if they
      are on different interfaces.]

   4.4 Local Repair

      Each RSVP daemon periodically sends refreshes to its next/previous
      hops.  An important optimization would allow the local routing
      protocol module to notify the RSVP daemon of route changes for
      particular destinations.  The RSVP daemon should use this
      information to trigger an immediate refresh of state for these
      destinations, using the new route.  This allows fast adaptation to
      routing changes without the overhead of a short refresh period.

   4.5 Time Parameters

      For each element of state, there are two time parameters: the
      refresh period R and the time-to-live value T.  R specifies the
      period between sending successive refreshes of this data.  T
      controls how long state will be retained after refreshes stop
      appearing, and depends upon period between receiving successive
      refreshes.  Specifically, R <= T, and the "cleanout time" is K *
      T.  Here K is a small integer; K-1 successive messages may be lost
      before state is deleted.  Currently K = 3 is suggested.

      Clearly, a smaller T means increased RSVP overhead.  If the router
      does not implement local repair, a smaller T improves the speed of
      adapting to routing changes.  With local repair, a router can be
      more relaxed about T, since the periodic refresh becomes only a
      backstop robustness mechanism.

      There are three possible ways for a router to determine R and T.

      o    Default values are configured in the router.  Current
           defaults are 30 seconds for T and R.

      o    A router may adjust the value of T dynamically to keep a
           constant total overhead due to refresh traffic; as more
           sessions appear, the period would be lengthened.  In this
           case, R = T could be used.

      o    R and T can be specified by the end systems.  For this
           purpose, PATH and RESV messages may contain the optional
           TIM_VALUES object.  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



Braden, Zhang, et al.  Expiration: September 1995              [Page 35]


Internet Draft             RSVP Specification                 March 1995


           RSVP to route changes.  In the first hop, they are expected
           to be equal.  The RSVP API might allow an application to
           override the default value for a particular session.
















































Braden, Zhang, et al.  Expiration: September 1995              [Page 36]


Internet Draft             RSVP Specification                 March 1995


   4.6 RSVP Interfaces

      RSVP on a router has interfaces to routing and to traffic control
      in the kernel.  RSVP on a host has an interface to applications
      (i.e, an API) and also an interface to traffic control (if it
      exists on the host).

      4.6.1 Application/RSVP Interface

         This section describes a generic interface between an
         application and 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.

         o    Register

              Call: REGISTER( DestAddress , DestPort

                         [ , SESSION_object ]  , SND_flag , RCV_flag

                         [ , Source_Address ]  [ , Source_Port ]

                         [ , Sender_Template ]  [ , Sender_Tspec ]

                         [ , Data_TTL ]  [ , UserCredential ]

                         [ , Upcall_Proc_addr ] )  -> Session-id


              This call initiates RSVP processing for a session, defined
              by DestAddress together with the TCP/UDP port number
              DestPort.  If successful, the REGISTER call returns
              immediately with a local session identifier Session-id,
              which may be used in subsequent calls.

              The SESSION_object parameter is included as an escape
              mechanism to support some more general definition of the
              session ("generalized destination port"), should that be
              necessary in the future.  Normally SESSION_object will be
              omitted; if it is supplied, it should be an
              appropriately-formatted representation of a SESSION
              object.

              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 Source_Address, Source_Port, Sender_Template,



Braden, Zhang, et al.  Expiration: September 1995              [Page 37]


Internet Draft             RSVP Specification                 March 1995


              Sender_Tspec, and Data_TTL are all concerned with a data
              source, and they will be ignored unless SND_flag is true.

              If SND_FLAG is true, a successful REGISTER call will cause
              RSVP to begin sending PATH messages for this session using
              these parameters, which are interpreted as follows:

              -    Source_Address

                   This is the address of the interface from which the
                   data will be sent.  If it is omitted, a default
                   interface will be used.

              -    Source_Port

                   This is the UDP/TCP port from which the data will be
                   sent.  If it is omitted or zero, the port is "wild"
                   and can match any port in a FILTERSPEC.

              -    Sender_Template

                   This parameter is included as an escape mechanism to
                   support a more general definition of the sender
                   ("generalized source port").  Normally this parameter
                   may be omitted; if it is supplied, it should be an
                   appropriately formatted representation of a
                   SENDER_TEMPLATE object.

              -    Sender_Tspec

                   This parameter is a Tspec describing the traffic flow
                   to be sent.  It may be included to prevent over-
                   reservation on the initial hops.

              -    Data_TTL

                   This is the (non-default) IP Time-To-Live parameter
                   that is being supplied on the data packets.  It is
                   needed to ensure that Path messages do not have a
                   scope larger than multicast data packets.

              Finally, Upcall_Proc_addr is the address of an upcall
              procedure to receive asynchronous error or event
              notification; see below.

         o    Reserve

              Call: RESERVE( session-id, style, style-dependent-parms )



Braden, Zhang, et al.  Expiration: September 1995              [Page 38]


Internet Draft             RSVP Specification                 March 1995


              A receiver uses this call to make a resource reservation
              for the session registered as `session-id'.  The style
              parameter indicates the reservation style.  The rest of
              the parameters depend upon the style, but generally these
              will include appropriate flowspecs and filter specs.

              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 a RESERVE
              call, an asynchronous ERROR/EVENT upcall may occur at any
              time.

         o    Release

              Call: RELEASE( session-id )

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

         o    Error/Event Upcalls

              Call: <Upcall_Proc> (session-id, Info_type, List_count

                            [ ,Error_code ,Error_value ,LUB-flag ]

                            [ ,Filter_spec_list ]  [ ,Flowspec_list ]

                            [ ,Advert_list ] )


              Here "Upcall_Proc" represents the upcall procedure whose
              address was supplied in the REGISTER call.

              This upcall may occur asynchronously at any time after a
              REGISTER call and before a RELEASE call, to indicate an
              error or an event.  Currently there are three upcall
              types, distinguished by the Info_type parameter:

              1.   Info_type = Path Event

                   A Path Event upcall indicates the receipt of a PATH
                   message, indicating to the application that there is



Braden, Zhang, et al.  Expiration: September 1995              [Page 39]


Internet Draft             RSVP Specification                 March 1995


                   at least one active sender.  This upcall provides
                   synchronizing information to the receiver
                   application, and it may also provide parallel lists
                   of senders (in Filter_spec_list), traffic
                   descriptions (in Flowspec_list), and service
                   advertisements (in Advert_list).  'List_count' is the
                   number in each list;  where these objects are
                   missing, corresponding null objects must appear.

                   Error_code and Error_value, and LUB-flag should be
                   ignored in a Path Event upcall.

              2.   Info_type = Path Error

                   An Path Error event indicates an error in processing
                   a sender descriptor originated by this sender.  The
                   Error_code parameter will define the error, and
                   Error_value may supply some additional (perhaps
                   system-specific) data about the error.  `List_count'
                   will be 1, and Filter_spec_list and Flowspec_list
                   will contain the Sender_Template and the Sender_Tspec
                   supplied in the REGISTER call; Advert_list will
                   contain one NULL object.

              3.   Info_type = Resv Error

                   An Resv Error event indicates an error in processing
                   a RESV message to which this application contributed.
                   The Error_code parameter will define the error, and
                   Error_value may supply some additional (perhaps
                   system-specific) data on the error.

                   `List_count' will be 1, and Filter_spec_list and
                   Flowspec_list will contain one FILTER_SPEC and one
                   FLOWSPEC object.  These objects are taken from the
                   RESV message that caused the error (unless the LUB-
                   flag is on, in which case FLOWSPEC may differ).

              Although RSVP messages indicating path events or errors
              may be received periodically, the API should make the
              corresponding asynchronous upcall to the application only
              on the first occurrence, or when the information to be
              reported changes.

      4.6.2 RSVP/Traffic Control Interface

         In each router and host, enhanced QoS is achieved by a group of
         inter-related traffic control functions:  a packet classifier,



Braden, Zhang, et al.  Expiration: September 1995              [Page 40]


Internet Draft             RSVP Specification                 March 1995


         an admission control module, and a packet scheduler.  This
         section describes a generic RSVP interface to traffic control.

         1.   Make a Reservation

              Call: Rhandle =  TC_AddFlowspec( Flowspec, Police_Flag

                                     [ , Sender_Tspec]

                                     [ , SD_rank , SD_end_flag ] )


              This call passes a Flowspec defining a desired QoS to
              admission control.  It may also pass Sender_Tspec, the
              maximum traffic characteristics computed over the
              SENDER_TSPECs of senders that will contribute data packets
              to this reservation.  Police_Flag is a Boolean parameter
              that indicates whether traffic policing should be applied
              at this point.

              The SD_rank and SD_end_flag fields are used for a member
              of a session group.  SD_rank is the rank value from the
              SESSION_GROUP object.  The call is made with each of the
              sessions in the group, and SD_end_flag is set true for the
              last one.

              This call 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.  It returns the opaque number Rhandle for
              subsequent references to this reservation.

         2.   Add Filter

              Call: TC_AddFilter( Rhandle, Session, Filterspec )


              This call is used to define a filter corresponding to the
              given handle, following a successful TC_AddFlowspec call.

         3.   Modify or Delete Filter

              Call: TC_ModFilter( Rhandle, Session,

                                             [ new_Filterspec] )


              This call can modify an existing filter or replace an



Braden, Zhang, et al.  Expiration: September 1995              [Page 41]


Internet Draft             RSVP Specification                 March 1995


              existing filter with no filter (i.e., delete the filter).

         4.   Modify or Delete Flowspec

              Call: TC_ModFlowspec( Rhandle

                             [, new_Flowspec [ ,Sender_Tspec]] )


              This call can modify an existing reservation or delete the
              reservation.  If new_Flowspec is included, it is passed to
              Admission Control; if it is rejected, the current flowspec
              is left in force.  If new_Flowspec is omitted, the
              reservation is deleted and Rhandle is invalidated.

         5.   OPWA Update

              Call: TC_Advertise( interface, Adspec

                              [ ,Sender_TSpec ] ) -> New_Adspec


              This call is used for OPWA to compute the outgoing
              advertisement New_Adspec for a specified interface.

         6.   Initialize Traffic Control

              Call: TC_Initialize(interface )


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

      4.6.3 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
              forwarded.  The identity of the interface on which it is
              received should also be available to the RSVP daemon.

         o    Route discovery




Braden, Zhang, et al.  Expiration: September 1995              [Page 42]


Internet Draft             RSVP Specification                 March 1995


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

                 GetUcastRoute( DestAddress ) -> OutInterface

                 GetMcastRoute( SrcAddress, DestAddress )

                                              -> OutInterface_list


         o    Route Change Notification

              Routing may provide an asynchronous notification to RSVP
              that a specified route has changed.

                 New_Ucast_Route( DestAddress ) -> new_OutInterface

                 New_Mcast_Route( SrcAddress, DestAddress )

                                                -> new_OutInterface_list


         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.  Outgoing link
              specification is necessary because RSVP may send different
              versions of outgoing PATH messages on different
              interfaces, for the same source and destination addresses,
              and to avoid loops.

         o    Discover Interface List

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













Braden, Zhang, et al.  Expiration: September 1995              [Page 43]


Internet Draft             RSVP Specification                 March 1995


5. Message Processing Rules

   This generic description of RSVP operation assumes the following data
   structures.  An actual implementation may use additional or different
   structures to optimize processing.

   o    PSB -- Path State Block

        Each PSB holds path state for a particular (session, sender)
        pair, defined by SESSION and SENDER_TEMPLATE objects,
        respectively.  PSB contents include a PHOP object and possibly
        SENDER_TSPEC, CREDENTIAL, and/or ADVERT objects from PATH
        messages.

   o    RSB -- Reservation State Block

        RSB's are used to hold reservation state.  Each RSB holds
        reservation state for the 4-tuple: (session, next hop, style,
        filterspec), defined in SESSION, NHOP (i.e., RSVP_HOP), STYLE,
        and FILTER_SPEC objects, respectively.  We assume that RSB
        contents include the outgoing interface OI that is implied by
        NHOP.  RSB contents also include a FLOWSPEC object and may
        include a CERTIFICATE object.

   MESSAGE ARRIVES

   Verify version number, checksum, and length fields of common header,
   and discard message if it fails.

   Further processing depends upon message type.

   PATH MESSAGE ARRIVES

        Start with the Refresh_Needed flag off.

        Each sender descriptor object sequence in the message defines a
        sender.  Process each sender as follows.

        1.   If there is a CREDENTIAL object, verify it; if it is
             unacceptable, build and send a PERR message, drop the PATH
             message, and return.

        2.   If there is no path state block (PSB) for the (session,
             sender) pair then:

             o    Create a new PSB.

             o    Set a cleanup timer for the PSB.  If this is the first



Braden, Zhang, et al.  Expiration: September 1995              [Page 44]


Internet Draft             RSVP Specification                 March 1995


                  PSB for the session, set a refresh timer for the
                  session.

             o    Copy PHOP into the PSB.  Copy into the PSB any of the
                  following objects that are present in the message:
                  CREDENTIAL, SENDER_TSPEC, and/or ADVERT.  Copy the
                  EntryPolice flag from the common header into the PSB.

             o    Call the appropriate route discovery routine, using
                  DestAddress from SESSION and (for multicast routing)
                  SrcAddress from SENDER_TEMPLATE.  Store the resulting
                  routing bit mask ROUTE_MASK in the PSB.

        3.   Otherwise (there is a matching PSB):

             o    If CREDENTIAL differs between message and PSB, verify
                  new CREDENTIAL.  If it is acceptable, copy it into
                  PSB.  Otherwise, build and send a PERR message for
                  "Bad Credential", drop the PATH message, and return.

             o    Restart cleanup timer.

             o    Update the PSB with values from the message, as
                  follows.  Copy the ADVERT object, if any, into the
                  PSB.  Copy the EntryPolice flag into the PSB.

                  If the values of PHOP or SEND_TSPEC differ between the
                  message and the PSB, copy the new values into the PSB
                  and turn on the Refresh_Needed flag.  If SEND_TSPEC
                  has changed, reservations matching S may also change;
                  this may be deferred until a RESV refresh arrives.

             o    Call the appropriate route discovery routine and
                  compare the route mask with the ROUTE_MASK value
                  already in the PSB; if a new bit (interface) has been
                  added, turn on the Refresh_Needed flag.  Store new
                  ROUTE_MASK in the PSB.

        4.   If the Refresh_Needed flag is now set, execute the PATH
             REFRESH event sequence (below).


   PATH TEAR MESSAGE ARRIVES

        o    If there is no path state for this destination, drop the
             message and return.

        o    Forward a copy of the PTEAR message using the same rules as



Braden, Zhang, et al.  Expiration: September 1995              [Page 45]


Internet Draft             RSVP Specification                 March 1995


             for a PATH message (see PATH REFRESH).

        o    Each sender descriptor in the PTEAR message contains a
             SENDER_TEMPLATE object defines a sender S; process it as
             follows.

             1.   Locate the PSB for the pair: (session, S).  If none
                  exists, continue with next sender descriptor.

             2.   Examine the RSB's for this session and delete any
                  reservation state associated with sender S, depending
                  upon the reservation style.  For example:


                  Delete a WF reservation for which S is the only
                       sender.


                  Delete an FF reservation for S.

             3.   Delete the PSB.


   PATH ERROR MESSAGE ARRIVES

        o    If there are no existing PSB's for SESSION then drop the
             PERR message and return.

        o    Look up the PSB for (session, sender); sender is defined by
             SENDER_TEMPLATE.  If no PSB is found, drop PERR message and
             return.

        o    If PHOP in PSB is local API, deliver error to application
             via an upcall:

                 Call: <Upcall_Proc>( session-id, Path Error, 1,
                               Error_code, Error_value, 0,
                               SENDER_TEMPLATE, NULL, NULL)


             Note that CREDENTIAL, SENDER_TSPEC, and ADVERT objects in
             the message is ignored.

             Otherwise (PHOP is not local API), forward a copy of the
             PERR message to the PHOP node.


   RESV MESSAGE ARRIVES



Braden, Zhang, et al.  Expiration: September 1995              [Page 46]


Internet Draft             RSVP Specification                 March 1995


        A RESV message arrives through outgoing interface OI.

        o    Check the SESSION object.

             If there are no existing PSB's for SESSION then build and
             send a RERR message (as described later) specifying "No
             Path Information", drop the RESV message, and return.
             However, do not send the RERR message if the style has
             wildcard reservation scope and this is not the receiver
             host itself.

        o    Check the STYLE object.

             If style in the message conflicts with the style of any
             reservation for this session in place on any interface,
             reject the RESV message by building and sending a RERR
             message specifying "Bad Style", drop the RESV message, and
             return.

        o    Check the CREDENTIAL object.

             Verify the CREDENTIAL field (if any) to check permission to
             create a reservation.  [This check may also involve the
             CREDENTIAL fields from the PSB's in the scope of this
             reservation; in that case, it would better fit below in
             processing the individual flow descriptors.]

        o    Check for path state

             If there are no PSB's matching the scope of this
             reservation, build and send a RERR message specifying "No
             Sender Information", drop the RESV message, and return.

        o    Make reservations

             Process the style-specific tail sequence.

             For FF style, execute the following steps for each b flow
             descriptor, i.e., each (FLOWSPEC, FILTERSPEC) pair.  For WF
             style execute the following once, using some internal
             placeholder "WILD_FILTER" for FILTERSPEC to indicate
             wildcard scope.

             1.   Find or create a reservation state block (RSB) for the
                  4-tuple:  (SESSION, NHOP, style, FILTERSPEC).

             2.   Start or restart the cleanout timer on the RSB.




Braden, Zhang, et al.  Expiration: September 1995              [Page 47]


Internet Draft             RSVP Specification                 March 1995


             3.   Start a refresh timer for this session if none was
                  started.

             4.   If the RSB existed and if FLOWSPEC and the
                  SENDER_TSPEC objects are unchanged, drop the RESV
                  message and return.

             5.   Compute Sender_Tspec as the maximum over the
                  SENDER_TSPEC objects of the PSB's within the scope of
                  the reservation.

             6.   Set Police_flag on if any PSB's in the scope have the
                  EntryPolice flag on, or if the style is WF and there
                  is more than one PSB in the scope, otherwise off.

             7.   Computer K_Flowspec, the effective kernel flowspec, as
                  the maximum of the FLOWSPEC values in all RSB's for
                  the same (SESSION, OI, FILTERSPEC) triple.  Similarly,
                  the kernel filter spec K_filter is either the
                  FILTER_SPEC object under consideration (unitary
                  scope), or it is WILD_FILTER (wildcard scope).

                  If there was no previous kernel reservation in place
                  for (SESSION, OI, FILTERSPEC), call the kernel
                  interface module:

                     TC_AddFlowspec( Sender_Tspec, K_flowspec, Police_Flag )

                  If this call fails, build and send a RERR message
                  specifying "Admission control failed", drop the RESV
                  message, and return.  Otherwise, record the kernel
                  handle K_handle returned by the call in the RSB(s).
                  Then call:

                     TC_AddFilter( K_handle, K_Filter)

                  to set the filter, drop the RESV message and return.

                  /item However, if there was a previous kernel
                  reservation with handle K_handle, call the kernel
                  interface module:

                     TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec)

                  If this call fails, build and send a RERR message
                  specifying "Admission control failed".  In any case,
                  drop the RESV message and return.




Braden, Zhang, et al.  Expiration: September 1995              [Page 48]


Internet Draft             RSVP Specification                 March 1995


        If processing a RESV message finds an error, a RERR message is
        created containing flow descriptor and an ERRORS object.  The
        Error Node field of the ERRORS object (see Appendix A) is set to
        the IP address of OI, and the message is sent unicast to NHOP.

        created

   RESV TEAR MESSAGE ARRIVES

        A RTEAR message arrives on outgoing interface OI.

        o    If there are no existing PSB's for SESSION then drop the
             RTEAR message and return.

        o    Process the style-specific tail sequence to tear down
             reservations.

             For FF style, execute the following steps for each b flow
             descriptor, i.e., each (FLOWSPEC, FILTERSPEC) pair.  For WF
             style execute the following once, using some internal
             placeholder "WILD_FILTER" for FILTERSPEC to indicate
             wildcard scope.

             1.   Find matching RSB(s) for the 4-tuple: (SESSION, NHOP,
                  style, FILTERSPEC).  If no RSB is found, continue with
                  next flow descriptor, if any.

             2.   Delete the RSB(s).

             3.   If there are no more RSBs for the same (SESSION, OI,
                  FILTERSPEC/) triple, call the kernel interface module:

                     TC_ModFlowspec( K_handle )

                  to delete the reservation.  Then build and forward a
                  new RERR message.

                  -    WF style: send a copy to each PHOP among all
                       matching senders.

                  -    FF style: Send to PHOP of matching PSB.

             4.   Otherwise (there are other RSB's for the same
                  reservation), recompute K_Flowspec and call the kernel
                  interface module:

                     TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec)




Braden, Zhang, et al.  Expiration: September 1995              [Page 49]


Internet Draft             RSVP Specification                 March 1995


                  to update the reservation, and then execute the RESV
                  REFRESH sequence (below).  If this kernel call fails,
                  return; the prior reservation will remain in place.


   RESV ERROR MESSAGE ARRIVES

        o    Call the appropriate route discovery routine, using
             DestAddress from SESSION and (for multicast routing)
             SrcAddress from the Error Node field in the ERRORS object.
             Let the resulting routing bit mask be M.

        o    Determine the set of RSBs matching the triple: (SESSION,
             style, FILTERSPEC).  If no RSB is found, drop RERR message
             and return.

             Recompute the maximum over the FLOWSPEC objects of this set
             of RSB's.  If the LUB was used in this computation, turn on
             the LUB-flag in the received RESV message.

        o    Delete from the set of RSVs any whose OI does not appear in
             the bit mask M and whose NHOP is not the local API.  If
             none remain, drop RERR message and return.

             For each PSB in the resulting set, do the following step.

        o    If NHOP in PSB is local API, deliver error to application
             via an upcall:

                 Call: <Upcall_Proc>( session-id, Resv Error, 1,
                               Error_code, Error_value, LUB-flag,
                               FILTER_SPEC, FLOWSPEC, NULL)


             Here LUB-flag is taken from the received packet, as
             possibly modified above.

             Otherwise (NHOP is not local API), forward a copy of the
             RERR message to the PHOP node.


   PATH REFRESH

   This sequence may be entered by either the expiration of the path
   refresh timer for a particular session, or immediately as the result
   of processing a PATH message turning on the Refresh_Needed flag.

   For each virtual outgoing interface ("vif") V, build a PATH message



Braden, Zhang, et al.  Expiration: September 1995              [Page 50]


Internet Draft             RSVP Specification                 March 1995


   and send it to V.  To build the message, consider each PSB whose
   ROUTE_MASK includes V, and do the following:

   o    Pass the ADVERT and SENDER_TSPEC objects present in the PSB to
        the kernel call TC_Advertise, and get back a modified ADVERT
        object.  Pack this modified object into the PATH message being
        built.

   o    Create a sender descriptor sequence containing the
        SENDER_TEMPLATE, CREDENTIAL, and SENDER_TSPEC objects, if
        present in the PSB.  Pack the sender descriptor into the PATH
        message being built.

   o    If the PSB has the EntryPolice flag on and if interface V is not
        capable of policing, turn the EntryPolice flag on in the PATH
        message being built.

   o    If the maximum size of the PATH message is reached, send the
        packet out interface V and start packing a new one.

   RESV REFRESH

   This sequence may be entered by either the expiration of the
   reservation refresh timer for a particular session, or immediately as
   the result of processing a RESV message.

   Each PSB for this session is considered in turn, to compute a style-
   dependent tail sequence.  These sequences for a given PHOP are then
   packed into the same message(s) and sent to that PHOP.  The logic is
   somewhat different depending upon whether the scope of the
   reservations is wildcard or not (they may not be mixed).

   For each PSB that does not correspond to the API, do the following.

   o    Compute (FLOWSPEC, FILTER_SPEC) Pair

        Select each RSB in whose reservation scope the PSB falls, and
        compute the maximum over the FLOWSPEC objects of this set of
        RSB's.  Also, select an appropriate FILTER_SPEC.  The scope
        depends upon the style and the filter spec of the RSB:

        1.   WF: Select every RSB whose OI matches a bit in the
             ROUTE_MASK of the PSB.

             In this case, FILTER_SPEC is the standard WILD_FILTER.

        2.   FF: Select every RSB whose FILTER_SPEC matches
             SENDER_TEMPLATE in the RSB.  This matching process should



Braden, Zhang, et al.  Expiration: September 1995              [Page 51]


Internet Draft             RSVP Specification                 March 1995


             consider wildcards.

             In this case, FILTER_SPEC is taken from any of the matching
             RSB's. [?? Need to either 'merge' filter specs, which
             probably means to remove gratuitous wildcards??]

        This computation also yields a style (since style must be
        consistent across RSB's for given session).  [??Again, need
        merging rules]]

   o    Build RESV packets

        Append this (FLOWSPEC, FILTER_SPEC pair) to the RESV message
        being built for destination PHOP (from the PSB).  When the
        packet fills, or upon completion of all PSB's with the same
        PHOP, set the NHOP address in the message to the interface
        address and send the packet out that interface to the PHOP
        address.

































Braden, Zhang, et al.  Expiration: September 1995              [Page 52]


Internet Draft             RSVP Specification                 March 1995


   appendix
6. Object Type Definitions

   C-types are defined for the two Internet address families IPv4 and
   IP6.  To accomodate other address families, additional C-types could
   easily be defined.  These definitions are contained as an Appendix to
   ease updating.

   6.1 SESSION Class

      Currently, SESSION objects contain the pair: (DestAddress,
      DestPort), where DestAddress is the data destination address and
      DestPort is the UDP/TCP destination port.  Other SESSION C-Types
      could be defined in the future to support other demultiplexing
      conventions in the transport-layer or application layer.

      o    IPv4/UDP SESSION object: Class = 1, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |             IPv4 DestAddress (4 bytes)                |
           +-------------+-------------+-------------+-------------+
           |        ////////////       |         DestPort          |
           +-------------+-------------+-------------+-------------+


      o    IP6/UDP SESSION object: Class = 1, C-Type = 129

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +               IP6 DestAddress (16 bytes)              +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |        ////////////       |         DestPort          |
           +-------------+-------------+-------------+-------------+













Braden, Zhang, et al.  Expiration: September 1995              [Page 53]


Internet Draft             RSVP Specification                 March 1995


   6.2 SESSION_GROUP Class

      o    IPv4 SESSION_GROUP Object: Class = 2, C-Type = 1:


           +-------------+-------------+-------------+-------------+
           |               IPv4 Reference DestAddress              |
           +-------------+-------------+-------------+-------------+
           |      Session_Group ID     |    Count    |     Rank    |
           +-------------+-------------+-------------+-------------+


      o    IP6 SESSION_GROUP Object: Class = 2, C-Type = 129:


           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +               IP6 Reference DestAddress               +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |      Session-Group ID     |    Count    |     Rank    |
           +-------------+-------------+-------------+-------------+

























Braden, Zhang, et al.  Expiration: September 1995              [Page 54]


Internet Draft             RSVP Specification                 March 1995


   6.3 RSVP_HOP Class

      o    IPv4 RSVP_HOP object: Class = 3, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |             IPv4 Next/Previous Hop Address            |
           +-------------+-------------+-------------+-------------+












































Braden, Zhang, et al.  Expiration: September 1995              [Page 55]


Internet Draft             RSVP Specification                 March 1995


      o    IP6 RSVP_HOP object: Class = 3, C-Type = 129

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +             IP6 Next/Previous Hop Address             +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+


      This object provides the IP address of the interface through which
      the last RSVP-knowledgeable hop forwarded this message.




































Braden, Zhang, et al.  Expiration: September 1995              [Page 56]


Internet Draft             RSVP Specification                 March 1995


   6.4 STYLE Class

      o    STYLE-WF object: Class = 4, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |   Style=1   |   ////////  |   ////////  |  /////////  |
           +-------------+-------------+-------------+-------------+


      o    STYLE-FF object: Class = 4, C-Type = 2

           +-------------+-------------+-------------+-------------+
           |   Style=2   |   ////////  |   ////////  |  FD Count   |
           +-------------+-------------+-------------+-------------+

           FD Count

                The count of elements in the variable-length object list
                that follows.  See the RESV message format definition
                earlier.































Braden, Zhang, et al.  Expiration: September 1995              [Page 57]


Internet Draft             RSVP Specification                 March 1995


   6.5 Flowspec Class

      o    CSZ FLOWSPEC object: Class = 5, C-Type = 1


            +-----------+-----------+-----------+-----------+
            |                QoS Service Code               |
            +-----------+-----------+-----------+-----------+
            |        b: Token Bucket Depth (bits)           |
            +-----------+-----------+-----------+-----------+
            |        r: Average data rate (bits/sec)        |
            +-----------+-----------+-----------+-----------+
            |        d: Max end-to-end delay (ms)           |
            +-----------+-----------+-----------+-----------+
            |              (For Future Use)                 |
            +-----------+-----------+-----------+-----------+


           QoS Service Code

                Integer value defining what service is being requested.
                The values currently defined for this code are:

                1 = Guaranteed Service

                     The Tspec is (b, r), while the Rspec is (r).  (d)
                     is ignored.

                2 = Bounded-Delay Predictive Service

                     The Tspec is (b, r), while the Rspec is (d).




















Braden, Zhang, et al.  Expiration: September 1995              [Page 58]


Internet Draft             RSVP Specification                 March 1995


   6.6 FILTER_SPEC Class

      o    IPv4/UDP FILTER_SPEC object: Class = 6, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |               IPv4 SrcAddress (4 bytes)               |
           +-------------+-------------+-------------+-------------+
           | Protocol Id |    //////   |          SrcPort          |
           +-------------+-------------+-------------+-------------+


      o    IP6/UDP FILTER_SPEC object: Class = 6, C-Type = 129

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +               IP6 SrcAddress (16 bytes)               +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           | Protocol Id |    //////   |          SrcPort          |
           +-------------+-------------+-------------+-------------+


      SrcAddress is an IP address for a host, and SrcPort is a UDP/TCP
      source port, defining a sender.























Braden, Zhang, et al.  Expiration: September 1995              [Page 59]


Internet Draft             RSVP Specification                 March 1995


   6.7 SENDER_TEMPLATE Class

      o    IPv4/UDP SENDER_TEMPLATE object: Class = 7, C-Type = 1

           Definition same as IPv4/UDP FILTER_SPEC object.

      o    IP6/UDP SENDER_TEMPLATE object: Class = 7, C-Type = 129

           Definition same as IP6/UDP FILTER_SPEC object.

   6.8 SENDER_TSPEC Class

      The most common form of Tspec is a token bucket.

      o    Token Bucket SENDER_TSPEC object: Class = 8, C-Type = 1


            +-----------+-----------+-----------+-----------+
            |        b: Token Bucket Depth (bits)           |
            +-----------+-----------+-----------+-----------+
            |        r: Average data rate (bits/sec)        |
            +-----------+-----------+-----------+-----------+





























Braden, Zhang, et al.  Expiration: September 1995              [Page 60]


Internet Draft             RSVP Specification                 March 1995


   6.9 ADVERT Class

      [TBD]

   6.10 TIME_VALUES Class

      o    TIME_VALUES Object: Class = 10, C-Type = 1


           +-------------+-------------+-------------+-------------+
           |                    Refresh Period                     |
           +-------------+-------------+-------------+-------------+
           |                    State TTL Time                     |
           +-------------+-------------+-------------+-------------+





































Braden, Zhang, et al.  Expiration: September 1995              [Page 61]


Internet Draft             RSVP Specification                 March 1995


   6.11 ERROR_SPEC Class

      o    IPv4 ERROR_SPEC object: Class = 11, C-Type = 1


           +-------------+-------------+-------------+-------------+
           |            IP4 Error Node Address (4 bytes)           |
           +-------------+-------------+-------------+-------------+
           |  Error Code |  ////////// |        Error Value        |
           +-------------+-------------+-------------+-------------+


      o    IP6 ERROR_SPEC object: Class = 11, C-Type = 129


           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +           IP6 Error Node Address (16 bytes)           +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |  Error Code |  ////////// |        Error Value        |
           +-------------+-------------+-------------+-------------+



      Errnor Node

           The IP address

      Error Code

           A one-octet error description.

                01 = Insufficient memory

                02 = Count Wrong

                     The FD Count field does not match length of
                     message.

                03 = No path information for this Resv

                04 = No Sender information for this Resv




Braden, Zhang, et al.  Expiration: September 1995              [Page 62]


Internet Draft             RSVP Specification                 March 1995


                     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?]

                10 = Illegal style

      Error Value

           Specific cause of the error described by the Error Code.























Braden, Zhang, et al.  Expiration: September 1995              [Page 63]


Internet Draft             RSVP Specification                 March 1995


   6.12 CREDENTIAL Class

      [TBD]

   6.13 INTEGRITY Class

      [TBD]












































Braden, Zhang, et al.  Expiration: September 1995              [Page 64]


Internet Draft             RSVP Specification                 March 1995


7. UDP Encapsulation

   As described earlier, RSVP control messages are intended to be
   carried as "raw packets", directly within IP datagrams.  Implementing
   RSVP in a node will typically require an intercept in the packet
   forwarding path for protocol 46, which means a kernel change.
   However, for ease of installing RSVP on host systems in the short
   term, it may be desirable to avoid host kernel changes by supporting
   UDP encapsulation of RSVP messages.  This encapsulation would be used
   between hosts and the last- (or first-) hop router(s).  This scheme
   will also support the case of an intermediate RSVP router whose
   kernel supports multicast but does not have the RSVP intercept, by
   allowing UDP encapsulation on each interface.

   The UDP encapsulation approach must support a domain that contains a
   mix of "UDP-only" hosts, which require UDP encapsulation, and "raw-
   capable" host, which can use raw RSVP packets.  Raw-capable hosts and
   first-hop router(s) must send each RSVP message twice in the local
   domain, once as a raw packet and once with UDP encapsulation; these
   nodes will also receive some local RSVP packets in both formats.  We
   assume that the only negative impact of this duplication will be
   (negligible) additional packet processing overhead in the raw-capable
   hosts and first-hop routers.

   [REST TBD]

8. DF Style (Experimental)

   In addition to the WF and FF styles defined in this specification, a
   Dynamic Filter (DF) style has also been proposed.  The following
   describes this style and gives examples of its usage.  At this time,
   DF style is experimental.

   8.1 Reservation Styles

      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, and
      these reservations have a wildcard reservation scope, so they go
      everywhere.  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.  Like a FF style request, a DF
      style request causes distinct reservations for different senders.

      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



Braden, Zhang, et al.  Expiration: September 1995              [Page 65]


Internet Draft             RSVP Specification                 March 1995


      <= D'.  These filterspecs define particular senders to use the D'
      reservations, and this list establishes the scope for the filter
      specs.

      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 may fail.

      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.  This in
      turn implies that the DF style creates reservations that may not
      be in use at any given time.

      The DF style is compatible with the FF style but not the WF style.

   8.2 Examples

      To give an example of the DF style, we use the following notation:

      o    DF Style

           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 11 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 `?'.




Braden, Zhang, et al.  Expiration: September 1995              [Page 66]


Internet Draft             RSVP Specification                 March 1995


      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.

                        |
         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 11: 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 11).
      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.

      For a DF reservation request with a Dynamic Reservation Count = C,



Braden, Zhang, et al.  Expiration: September 1995              [Page 67]


Internet Draft             RSVP Specification                 March 1995


      RSVP should call TC_AddFlowspec C times.

   8.3 Resv Messages

      Add the following sequence:

          <style-specific-tail> ::=

                      <Style-DF> <FLOWSPEC> <filter spec list>

          <filter spec list> ::=  <empty>  |  <filter spec list> <FILTER_SPEC>


   8.4 STYLE Class

      o    STYLE-DF object: Class = 4, C-Type = 3

           +-------------+-------------+-------------+-------------+
           |   Style=3   |   ////////  | Dyn Resv Cnt|  FD Count   |
           +-------------+-------------+-------------+-------------+

           Style

                3 = Dynamic-Filter

           Dyn Resv Count

                The number of channels to be reserved for a Dynamic
                Filter style reservation.  This integer value must not
                less than FD Count.


REFERENCES

[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,
    BBN, September 1992.




Braden, Zhang, et al.  Expiration: September 1995              [Page 68]


Internet Draft             RSVP Specification                 March 1995


[Shenker94]  Shenker, S., "Two-Pass or Not Two-Pass", Current Meeting
    Report, RSVP Working Group, Proceedings of the Thirtieth Internet
    Engineering Task Force, Toronto, Canada, July 1994.

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



Security Considerations

   See Section 2.5.

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










Braden, Zhang, et al.  Expiration: September 1995              [Page 69]


Internet Draft             RSVP Specification                 March 1995


   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

































Braden, Zhang, et al.  Expiration: September 1995              [Page 70]


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