Internet Draft                                            R. Braden, Ed.
Expiration: September December 1995                                            ISI
File: draft-ietf-rsvp-spec-05.txt                                L.Zhang draft-ietf-rsvp-spec-06.txt                               L. Zhang
                                                                    PARC
                                                               D. Estrin
                                                                     ISI
                                                               S. Herzog
                                                                     ISI
                                                                S. Jamin
                                                                     USC

                Resource ReSerVation Protocol (RSVP) --

                   Version 1 Functional Specification

                           March 24,

                             June 21, 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.

What's Changed Since Toronto Boston IETF

This version of the

The most important changes in this document incorporates many of from the protocol changes
agreed rsvp-spec-05 draft
are:

   o    Added SE (Shared Explicit) style to at all parts of the December 1994 IETF meeting document.

   o    Further clarified reservation options and added table in San Jose.  The most major
changes are: Figure
        3.  Defined option vector in STYLE object.

   o    The RSVP packet format has been reorganized    Renamed CREDENTIAL object class to carry most data POLICY_DATA object class, and
        rewrote section 2.5 to more fully express its intended usage.

   o    Clarified the relationship between the wildcard scope
        reservation option and wildcards in individual FILTER_SPEC
        objects: wildcard is as typed variable-length objects. wildcard does.

   o    This generality includes provision    Added SCOPE object definition and define the rules for 16-byte IP6 addresses.

   o    Filter specs have been simplified.

   o    DF style has been moved its use
        to an Appendix, as experimental. prevent looping of wildcard-scope messages.

   o    UDP encapsulation    Added TAG object.  This is needed to do semantic fragmentation
        in certain cases; however, the rules for its use are not yet
        written down.  Furthermore, there has been included. some debate about
        semantic fragmentation.

   o    OPWA has been included.    Added some mechanisms for handling backwards compatibility for
        future protocol extensions: (1) High bit of object class number;
        (2) unmerged FLOWSPEC C-Type; (3) unmerged POLICY_DATA C-Type.

   o    The Drop flag has been eliminated.    Rewrote Section 4.3 on preventing looping.  Included rules for
        SCOPE object.

   o    Session groups have been added.    Specified rules for local repair upon route change notification
        (Section 4.4).

   o    The routing of RERR messages has been changed.

1. Introduction

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

   A host uses each error type whether or not the RSVP protocol to request a specific quality of
   service (QoS) from state
        information in the network, on behalf of an application data
   stream.  RSVP erroneous packet is also used to deliver QoS requests to routers along be stored and
        forwarded.

   o    Deleted the path(s) discussion of the data stream and retransmitting a Teardown message Q
        times; assume Q=1 is sufficient.

   o    Moved Session Groups to maintain router Appendix D, "Experimental and host state
   to provide Open
        Issues".  Session Groups should be revisited as part of a larger
        context of cross-session reservations.

   o    Changed common header format, removing Object Count (which was
        redundant) and rearranging the requested service.  This will generally (but not
   necessarily) require reserving resources along remaining fields.  Moved 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, two
        common header flags into objects: Entry-Police into SESSION
        object and LUB-used into ERROR_SPEC object.

   o    Revised the same application
   may act as both sender rules for state timeout (Section 4.5) and receiver.  RSVP operates on top of IP,
   occupying redefined
        the place of a transport protocol in TIME_VALUES object format.

   o    Changed the protocol stack.
   However, like ICMP, IGMP, error message format: (1) removed required RSVP_HOP
        object from PERR and routing protocols, RSVP does not
   transport application data but is rather an Internet control
   protocol.  As shown RERR messages; (2) removed CREDENTIAL
        (i.e., POLICY_DATA) object from RERR messages; (3) specified
        more carefully what may appear in Figure 1, an implementation flow descriptor list of RSVP, like RERR
        messages.

   o    Revised the
   implementations definitions of routing error codes and management protocols, will typically
   execute in the background, not in the data forwarding path.

   RSVP is not itself error values, and
        moved them into a separate Appendix B.

   o    No longer require CREDENTIAL (i.e., POLICY_DATA) match for
        teardown.

   o    Revised routing protocol; the RSVP daemon consults the
   local routing protocol(s) to obtain routes.  Thus, a host sends IGMP of RERR messages to join a multicast group, and it sends RSVP messages use SCOPE objects to
   reserve resources along the delivery path(s) from that group.  RSVP
   is designed avoid
        wildcard-induced looping.

   o    Added LIH (logical interface handle) to operate with existing and future unicast and RSVP_HOP object, for IP
        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 tunnels.

   o    Added two new upcall event types in Hosts and Routers

   Each router that is capable of resource the API: reservation passes incoming event
        and policy data packets event.

   o    Generalized the generic traffic control calls slightly to allow
        multiple filter specs per flowspec, for SE style.  This
        introduced a packet classifier and then queues them as necessary
   in new set of handles, called FHandle.  Also added a packet scheduler.  The packet classifier determines the
        preemption upcall.

   o    Added 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 change notification to efficiently accommodate heterogeneous receivers and
   dynamic group membership and the generic interface to be consistent with IP multicast, RSVP
   makes receivers responsible for requesting
        routing.

   o    Updated the message processing rules (Section 5).

   o    Rewrote Appendix C on UDP encapsulation.

   o    Removed specification of FLOWSPEC object format (but int-serv
        working group has since reneged on promise to specify it).

1. Introduction

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

   A QoS request, typically originating in a receiver host
   application, will be passed to uses the local RSVP implementation, shown
   as protocol to request a user daemon in Figure 1.  The specific quality of
   service (QoS) from the network, on behalf of an application data
   stream.  RSVP protocol is then also used to pass
   the request deliver QoS requests to all the nodes (routers and hosts) routers along
   the reverse
   data path(s) to of the data source(s).

   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 stream and to the packet classifier maintain router and scheduler host state
   to obtain provide the
   desired QoS.  If admission control fails at any node, requested service.  This will generally (but not
   necessarily) require reserving resources along the data path.

   RSVP
   program returns an error indication to the application reserves resources for simplex data streams, i.e., it reserves
   resources in only one direction on a link, so that
   originated the request.  We refer to a sender is
   logically distinct from a receiver.  However, the packet classifier, packet
   scheduler, and admission control components same application
   may act as "traffic control". both sender and receiver.  RSVP is designed to scale well for very large multicast groups.
   Since operates on top of IP,
   occupying the membership place 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" transport protocol in the routers, in addition to receiver-initiation.

   RSVP protocol mechanisms provide a general facility for creating stack.
   However, like ICMP, IGMP, and
   maintaining distributed reservation state across a mesh of multicast
   or unicast delivery paths. routing protocols, RSVP transfers reservation parameters as
   opaque does not
   transport application data (except for certain well-defined operations on the data),
   which it simply passes to traffic but is rather an Internet control for interpretation.
   Although the RSVP protocol mechanisms are largely independent
   protocol.  As shown in Figure 1, an implementation of RSVP, like the
   encoding
   implementations of these parameters, the encodings must be defined routing and management protocols, will typically
   execute in the
   reservation model that is presented to an application (see Appendix
   A).

   In summary, RSVP has background, not in the following attributes:

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

   o forwarding path.

   RSVP is simplex.

   o not itself a routing protocol; the RSVP is receiver-oriented, i.e., daemon consults the receiver of
   local routing protocol(s) to obtain routes.  Thus, a data flow is
        responsible for the initiation host sends IGMP
   messages to join a multicast group, and maintenance of it sends RSVP messages to
   reserve resources along the resource
        reservation used for delivery path(s) from that flow.

   o group.  RSVP maintains "soft state" in the routers, enabling it
   is designed to
        gracefully support dynamic membership changes operate with existing and automatically
        adapt to future unicast and multicast
   routing changes.

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

   o protocols.

               HOST                             ROUTER

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

   The remainder of this section describes the
   | |Applic-|     | RSVP reservation
   services.  Section 2 presents an overview of the <-----       ||Routing |   -> 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 <------>
   | |  App  <----->daemon|  |         ||Protocol|    |daemon||
   | |       |     |      |  |         || daemon <---->      ||
   | |_______|     |___.__|  |         ||_ ._____|    |__.___||
   |===|===============v=====|         |===v=============v====|
   | data flows with the same unicast or multicast
      destination constitute a session.     ..........     |         |   .  ............    |
   |   |  ____v_   ____v____ |         |  _v__v_    _____v___ |
   |   | |Class-| |         ||   data  | |Class-|  |         ||  data
   |   |=> ifier|=> Packet  =============> ifier|==> Packet  |======>
   |     |______| |Scheduler||         | |______|  |Scheduler||
   |              |_________||         |           |_________||
   |_________________________|         |______________________|

                   Figure 1: RSVP treats each session
      independently.  All 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 particular session are
      directed to packet scheduler.  The packet classifier determines the same IP destination address DestAddress, route
   and
      perhaps to some further demultiplexing point defined in a higher the QoS class for each packet.  The scheduler allocates resources
   for transmission on the particular link-layer medium used by each
   interface.  If the link-layer medium is QoS-active, i.e., if it has
   its own QoS management capability, then the packet scheduler is
   responsible for negotiation with the link layer (transport or application).  We refer to obtain the latter QoS
   requested by RSVP.  There are many possible ways this might be
   accomplished, and the details will be medium-dependent.  The
   scheduler itself allocates packet transmission capacity on a QoS-
   passive medium such as a
      "generalized destination port".

      DestAddress is the leased line.  The scheduler may also
   allocate other system resources such as CPU time or buffers.

   In order to efficiently accommodate heterogeneous receivers and
   dynamic group address membership and to be consistent with IP multicast, RSVP
   makes receivers responsible for multicast delivery, or the
      unicast address of a single receiver. requesting resource reservations
   [RSVP93].  A generalized destination
      port could QoS request, typically originating in a receiver host
   application, will be defined by passed to the local RSVP implementation, shown
   as a UDP/TCP destination port field, by an
      equivalent field user daemon in another transport protocol, or by some
      application-specific information.  Although the Figure 1.  The RSVP protocol is
      designed then used to be easily extendible for greater generality, the
      present version uses only UDP/TCP ports as generalized ports.

      Figure 2 illustrates pass
   the flow of data packets in a single RSVP
      session, assuming multicast data distribution.  The arrows
      indicate data flowing from senders S1 and S2 request to receivers R1, R2,
      and R3, all the nodes (routers and hosts) along the cloud represents reverse
   data path(s) to 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 source(s).

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

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

                 Figure 2: Multicast Distribution Session

   1.2 Reservation Model

      An elementary node, the RSVP reservation request consists of a "flowspec"
      together with program applies a "filter spec"; this pair is local decision procedure,
   called a "flow
      descriptor".  The flowspec specifies a desired QoS.  The filter
      spec (together with "admission control", to determine if it can supply the DestAddress and
   requested QoS.  If admission control succeeds, the generalized
      destination port defining RSVP program sets
   parameters to the session) defines packet classifier and scheduler to obtain the set of data
      packets --
   desired QoS.  If admission control fails at any node, the "flow" -- RSVP
   program returns an error indication to receive the QoS defined by application that
   originated the
      flowspec.  The flowspec is used to set parameters request.  We refer to the packet
      scheduler in the node (assuming that classifier, packet
   scheduler, and admission control succeeds),
      while the filter spec components as "traffic control".

   RSVP is used designed to set parameters in scale well for very large multicast groups.
   Since the packet
      classifier.

      The flowspec in membership of a reservation request large group 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 be constantly changing,
   the parameters RSVP design assumes that may router state for traffic control will be used to police
   built and destroyed incrementally.  For this purpose, RSVP uses "soft
   state" in the data flow, i.e., routers, in addition to ensure it does
      not exceed its promised traffic level.

      The 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 model allows filter specs parameters as
   opaque data (except for certain well-defined operations on the data),
   which it simply passes to select
      arbitrary subsets traffic control for interpretation.
   Although the RSVP protocol mechanisms are largely independent of the packets in a given session.  Such subsets
      might
   encoding of these parameters, the encodings must 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
   reservation model that is presented 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 application (see Appendix
   A).

   In summary, RSVP has the decision that following attributes:

   o    RSVP should use
      separate sessions for distinct subflows of hierarchically-encoded
      signals.  For multicast sessions, subflows can be distinguished by supports multicast destination address; for or unicast sessions, they must be
      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, data delivery and on protocol id.  However, adapts to
        changing group membership as well as changing routes.

   o    RSVP is simplex.

   o    RSVP is receiver-oriented, i.e., the
      design receiver 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 data flow is
        responsible for the initiation and maintenance of the filter specs resource
        reservation used for that session will be sent as
      best-effort traffic.  Under congested conditions, such packets are
      likely flow.

   o    RSVP maintains "soft state" in the routers, enabling it to experience long delays
        gracefully support dynamic membership changes and may be dropped.  A receiver
      may wish to conserve network resources by explicitly asking the
      network automatically
        adapt 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; changes.

   o    RSVP is concerned only with the QoS provides several reservation models or "styles" (defined
        below) to fit a variety of those packets 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 delivered by routing. presented in [RSVP93,ISInt93].

   The remainder of this section describes the RSVP reservation request messages originate at receivers
   services.  Section 2 presents an overview of the RSVP protocol
   mechanisms, while Section 3 gives examples of the services and are
      passed upstream towards
   mechanism.  Section 4 contains 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" functional specification of RSVP.
   Section 5 presents explicit message processing rules.

   1.1 Data Flows

      The set of data flows with respect to the data flow direction).
      When an elementary reservation request is received at same unicast or multicast
      destination constitute a node, the session. RSVP daemon takes two primary actions.

      1.   Make treats each session
      independently.  All data packets in a reservation

           The flowspec and the filter spec particular session are passed
      directed to traffic
           control.  Admission Control determines the admissibility of
           the request (if it's new); if it fails this test, the
           reservation is rejected same IP destination address DestAddress, and RSVP sends back an error message
           towards the responsible receiver(s).  If it passes,
      perhaps to some further demultiplexing point defined in a higher
      layer (transport or application).  We refer to the
           flowspec latter as a
      "generalized destination port".

      DestAddress is used to set up the packet scheduler group address for multicast delivery, or the
           desired QoS and
      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 filter spec RSVP protocol is used to set the packet
           classifier
      designed to select be easily extendible for greater generality, the appropriate data packets.

      2.   Forward reservation upstream.

           The reservation request is propagated upstream towards
      present version uses only UDP/TCP ports as generalized ports.

      Figure 2 illustrates the
           appropriate senders.  The set flow of senders to which data packets in a given
           reservation request is propagated is called the "scope" of
           that request. single RSVP
      session, assuming multicast data distribution.  The reservation request that a node forwards upstream may differ arrows
      indicate data flowing from the request that it received, for two reasons.  First, it is
      possible (at least in theory) for the kernel senders S1 and S2 to modify receivers R1, R2,
      and R3, and the
      flowspec hop-by-hop (although currently no realtime services do
      this).  Second, reservations from different downstream branches of cloud represents the multicast distribution tree(s) must be "merged" as
      reservations travel upstream.  Merging reservations is a necessary
      consequence of mesh created by
      the multicast distribution, which creates routing protocol.  Multicast distribution forwards a single
      stream
      copy of each data packets in a particular router packet 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 sender Si to every 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 Rj; a single reservation.
      Another option controls the scope of the request: "unitary" (i.e.,
      unicast distribution session has a single specified sender), an explicit receiver R.  Each sender list,
      Si and each receiver Rj may correspond to a unique Internet host,
      or a
      "wildcard" that implicitly selects all single host may contain multiple logical senders upstream of and/or
      receivers, distinguished by generalized ports.

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

                 Figure 2: Multicast Distribution Session
      Even if the
      given node.

      The basic destination address is unicast, there may be multiple
      receivers, distinguished by the generalized port.  There may also
      be multiple senders for a unicast destination, i.e., RSVP can set
      up reservations for multipoint-to-point transmission.

   1.2 Reservation Model

      An elementary RSVP reservation model request consists of a "flowspec"
      together with a "filter spec"; this pair is "one pass": called a receiver sends "flow
      descriptor".  The flowspec specifies a
      reservation request upstream, desired QoS.  The filter
      spec (together with the DestAddress and each node in the path can only
      accept or reject generalized
      destination port defining the request.  This scheme provides no way session) defines the set of data
      packets -- the "flow" -- to make
      end-to-end service guarantees; receive the QoS request defined by the
      flowspec.  The flowspec is applied
      independently at each hop.  RSVP also supports an optional
      reservation model, known as " One Pass With Advertising" (OPWA)
      [Shenker94].  In OPWA, RSVP used to set parameters to the node's
      packet scheduler (assuming that admission control packets sent downstream,
      following succeeds), while
      the data paths, are filter spec is used to gather information on set parameters in the
      end-to-end service packet
      classifier.  Note that would result from a variety of possible
      reservation requests.  The results ("advertisements") are
      delivered by RSVP to the receiver host, and perhaps action to control the
      receiver application.  The information may then be used by QoS occurs at the
      place where the data enters the medium, i.e., at the upstream end
      of the link, although the
      receiver to construct an appropriate reservation request.

   1.3 Reservation Styles

      Each RSVP reservation request specifies a "reservation style". originates from
      receiver(s) downstream.

      The following reservation styles are defined flowspec in this version a reservation request will generally include a
      service type and two sets of numeric parameters: (1) an "Rspec" (R
      for `reserve'), which defines the protocol.

      1.   Wildcard-Filter (WF) Style

           The WF style specifies the options: "mixing" reservation desired per-hop reservation, and
           " wildcard" reservation scope.  Thus, a WF-style reservation
           creates
      (2) a single reservation into "Tspec" (T for `traffic'), which flows from all
           upstream senders are mixed.  This reservation defines the parameters that
      may be thought used to police the data flow, i.e., to ensure it does not
      exceed its promised traffic level.

      The form and contents of a shared "pipe", whose "size" Tspecs and Rspecs are determined by the
      integrated service model [ServTempl95a], and are generally opaque
      to RSVP.  RSVP delivers the Tspec and Rspec, together with an
      indication whether traffic policing is needed to the largest admission
      control and packet scheduling components of the
           resource requests for traffic control.  A
      service that link from all receivers,
           independent of requires traffic policing might for example apply it
      at the number edge 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 network and at data merge points; RSVP knows
      when these occur and must so indicate to the
           session as they appear.

      2.   Fixed-Filter (FF) Style

           The FF style specifies traffic control
      mechanism.  On the options: "distinct" reservation other hand, RSVP cannot interpret the service
      embodied in the flowspec and a "unitary" reservation scope.  Thus, an elementary FF-
           style reservation request creates a distinct reservation for
           data packets from therefore does not know whether
      policing will actually be applied in a particular sender, not mixing them with
           other senders' packets for case.

      In the same session.

           The total general RSVP reservation on a link for model [RSVP93], filter specs may
      select arbitrary subsets of the packets in a given session is the
           total 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 FF reservations for all requested senders.  On
           the other hand, FF reservations requested by packet.  For example, filter specs might be used to
      select different
           receivers Rj but subflows in a hierarchically-encoded signal by
      selecting on fields in an application-layer header.  However, in
      the same sender Si must
           necessarily be merged interest of simplicity (and to share minimize layer violation), the
      present RSVP version uses a single reservation in much more restricted form of filter
      spec: select only on sender IP address, on UDP/TCP port number,
      and perhaps on IP protocol id.

      RSVP can distinguish subflows of a
           given node.

      WF reservations hierarchically-encoded signal
      if they are appropriate for those assigned distinct multicast applications
      whose application-specific constraints make it unlikely destination addresses, or,
      for a unicast destination, distinct destination ports.  Data
      packets that
      multiple data sources will transmit simultaneously. One example is
      audio conferencing, where are addressed to a limited number particular session but do not
      match any 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 filter specs for video signals.

      The WF that session are expected to be
      sent as best-effort traffic, and FF styles under congested conditions, such
      packets are incompatible likely to experience long delays, and cannot be combined
      within a session.  Other reservation styles they may be defined in
      dropped.  When a receiver does not wish to receive a particular
      (sub-)flow, it can economize on network resources by explicitly
      asking the
      future (see Appendix C).

2. RSVP Protocol Mechanisms

   2.1 RSVP Messages

      There network to drop unneeded the data packets; it does so
      by leaving the multicast group(s) to which these packets are two fundamental
      addressed.  Thus, determining where packets get delivered should
      be a routing function; RSVP message types, RESV messages and
      PATH messages.

      Each receiver host sends is concerned only with the QoS of
      those packets that are delivered by routing.

      RSVP reservation request (RESV) messages originate at receivers and are
      passed upstream towards the senders.  These reservation messages must follow in
      reverse sender(s).  (This document defines the routes
      directional terms "upstream" vs. "downstream", "previous hop" vs.
      "next hop", and "incoming interface" vs "outgoing interface" with
      respect to the data packets will use, all the way upstream
      to flow direction.)  When an elementary
      reservation request is received at a node, the senders within RSVP daemon takes
      two primary actions:

      1.   Daemon makes a reservation

           The flowspec and the scope.  RESV messages filter spec are delivered passed to
      the sender hosts, so that the hosts can set up appropriate traffic
           control.  Admission control parameters for determines the admissibility of
           the first hop.  If a reservation request
      fails at any node, an RSVP error message (if it's new); if this test fails, the
           reservation is returned to the
      receiver; however, rejected and RSVP sends no positive acknowledgment messages returns an error message 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 appropriate receiver(s).  If admission control succeeds,
           the routing protocol(s); see Figure
      3.  These "Path" messages store path state in each node.  Path
      state is used by RSVP node uses the flowspec to route set up the RESV messages hop-by-hop in packet scheduler for
           the
      reverse direction.  (In desired QoS and the future, some routing protocols may
      supply reverse path forwarding information directly, without path
      state).

      PATH messages may also carry filter spec to set the following information:

      o    Sender Template

           The Sender Template describes packet
           classifier to select the format of appropriate data packets that packets.

      2.   Daemon forwards the sender will originate.  This template reservation upstream

           The reservation request is in propagated upstream towards the form
           appropriate senders.  The set of a
           filter spec that could be used sender hosts to select this sender's
           packets from others in the same session on which a
           given reservation request is propagated is called the same link.

      o    Tspec "scope"
           of that request.

      The PATH message may optionally carry a flowspec containing
           only reservation request that a Tspec, defining an upper bound on node forwards upstream may differ
      from the traffic level request that it received, for two reasons.  First, it is
      possible (in theory) for the sender will generate.  This Tspec can be used by
           RSVP kernel to prevent over-reservation (and perhaps unnecessary
           Admission Control failure) on modify the non-shared links starting
           at flowspec hop-
      by-hop, although currently no realtime services do this.  Second,
      reservations from different downstream branches of the sender.

      o    Adspec

           The PATH message may carry multicast
      distribution tree(s) must be "merged" as reservations travel
      upstream.  Merging reservations is a package necessary consequence of OPWA advertising
           information, known as an "Adspec".

       Previous       Incoming           Outgoing             Next
       Hops           Interfaces         Interfaces           Hops

       _____             _____________________                _____
      |     | data -->  |                     |  data -->    |     |
      |  A  |-----------|
      multicast distribution, which creates 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 single stream of data
      packets in a particular router node.  Each data
      stream arrives from any Si, regardless of the set
      of receivers downstream.  The reservation for Si on a previous hop through a corresponding
      incoming interface and departs through one or more particular
      outgoing
      interface(s).  The same physical interface may act in both link L should be the
      incoming and outgoing roles (for different data flows but "maximum" of the same
      session).

      As illustrated individual
      flowspecs from the receivers Rj that are downstream via link L.
      Merging is discussed further in Figure 4, there may be multiple previous hops
      and/or next hops through Section 2.2.

      The basic RSVP reservation model is "one pass": a given physical interface.  This may
      result from the connected network being receiver sends a shared medium or from
      the existence of non-RSVP routers
      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, since the next RSVP hop
      (see Section 2.6).  An RSVP daemon QoS request must preserve the next and
      previous hop addresses in its be
      applied independently at each hop.  RSVP also supports an optional
      reservation and path state,
      respectively.  A RESV message is model, known as "One Pass With Advertising" (OPWA)
      [Shenker94].  In OPWA, RSVP control packets sent with a unicast destination
      address, the address of a previous hop.   PATH messages, on downstream,
      following the
      other hand, data paths, 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 used to install
      a reservation gather information on the
      end-to-end service that interface, which is defined would result from a variety of possible
      reservation requests.  The results ("advertisements") are
      delivered by an effective
      flowspec.  This effective flowspec will be RSVP to the "maximum" of receiver host, and perhaps to the
      flowspecs requested
      receiver application.  The information may then be used by the different next hops.  In turn, a RESV
      message forwarded
      receiver to construct an appropriate reservation request.

   1.3 Reservation Styles

      A reservation request includes a particular previous hop carries a flowspec
      that is the "maximum" over set of control options.  One
      option concerns the effective treatment of reservations on for different
      senders within the
      corresponding outgoing interfaces.  Both cases represent merging,
      which is discussed further below.

      There are same session: establish a number of ways "distinct"
      reservation for each upstream sender, or else make a new single
      reservation request to fail
      in that is "shared" all senders' packets.  A distinct
      reservation requires that the filter spec match exactly one
      sender, a given node.

      1.   There may be no matching path state (i.e., wildcard reservation must match at least one.  Another
      option controls the scope may
           empty), which would prevent the reservation being propagated
           upstream.

      2.   Its style may be incompatible with of the style(s) request: an " explicit" sender
      specification, or a "wildcard" that implicitly selects all sender
      hosts upstream of existing
           reservations for the same session on given node.

      These control options are collectively called the same outgoing
           interface, so an effective flowspec cannot be computed. reservation
      "style", as shown in Figure 3.   Its

                 ||             Reservations:
        Scope    ||     Distinct     |        Shared
        _________||__________________|____________________
                 ||                  |                    |
       Explicit  ||  Fixed-Filter    |  Shared-Explicit   |
                 ||  (FF) style may be incompatible with      |  (SE) Style        |
       __________||__________________|____________________|
                 ||                  |                    |
       Wildcard  ||  (None defined)  |  Wildcard-Filter   |
                 ||                  |  (WF) Style        |
       __________||__________________|____________________|

                Figure 3: Reservation Attributes and Styles

      The styles currently defined are as follows:

      1.   Wildcard-Filter (WF) Style

           The WF style implies the style(s) of
           reservations that exist on other outgoing interfaces but will
           be merged with this options: "shared" reservation when and "
           wildcard" reservation scope.  Thus, a refresh message to
           create WF-style reservation
           creates a refresh message for the previous hop.

      4.   The effective flowspec single reservation into which flows from all
           upstream senders are mixed; this reservation may fail admission control.

      In any be thought
           of these cases, an error message as a shared "pipe", whose "size" is returned to the
      receiver(s) responsible 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 message, but any existing reservation is left in place.  This prevents a new, very large,
           propagated upstream towards all sender hosts.  A WF-style
           reservation from disrupting automatically extends to new senders as they
           appear.

      2.   Fixed-Filter (FF) Style

           The FF style implies the existing QoS by merging with options: "distinct" reservations and
           "explicit" reservation scope.  Thus, an
      existing elementary FF-style
           reservation and then failing admission control.

   2.2 Soft State

      To maintain request creates a distinct reservation state, RSVP keeps "soft state" in router
      and host nodes.  RSVP soft state for data
           packets from a particular sender, not sharing them with other
           senders' packets for the same session.  It scope is created and periodically
      refreshed
           determined by PATH and RESV messages. an explicit list of senders.

           The state total reservation on a link for a given session is deleted if no
      refreshes arrive before the expiration
           total 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 FF reservations for all requested senders.  On
           the resources being consumed may other hand, FF reservations requested by different
           receivers Rj but selecting the same sender Si must
           necessarily be "valuable"), merged to explicitly tear down an old reservation.

      When share a route changes, the next PATH message will initialize the
      path state on single reservation in a
           given node.

      3.   Shared Explicit (SE) Style

           The SE style implies the new route, options: "shared" reservation and future RESV messages will
      establish "
           explicit" reservation state, while the state on the now-unused
      segment of the route will time out. scope.  Thus, whether an SE-style reservation
           creates a message is
      "new" or single reservation into which flows from all
           upstream senders are mixed.  However, like a "refresh" is determined separately at each node,
      depending upon FF reservation
           the existence set 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 senders (and therefore its scope (and therefore
           the existing
      state at scope) is specified explicitly by the node in question.)
      In addition to receiver making the cleanup timeout, there
           reservation.

      WF and SE are both shared reservations, 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 "refresh timeout"
      period.  As messages arrive, the RSVP daemon checks them against limited
      number of people talk at once; each receiver might issue a WF or
      SE reservation request for twice one audio channel (to allow some
      over-speaking).  On the existing state; if it matches, other hand, the cleanup timeout timer on FF style, which creates
      independent reservations for the state flows from different senders, is reset and the message
      appropriate for video signals.

      It is dropped.  At the expiration
      of each refresh timeout period, RSVP scans its state to build and
      forward PATH and RESV refresh messages not possible to succeeding hops.

      RSVP sends its messages as IP datagrams without reliability
      enhancement.  Periodic transmission of refresh messages by hosts merge shared reservations with distinct
      reservations.  Therefore,  WF and routers is expected to replace any lost RSVP messages.  To
      tolerate K successive packet losses, the effective cleanup timeout
      must SE styles are incompatible with
      FF, but are compatible with each other.  Merging a WF style
      reservation with an SE style reservation results in a WF
      reservation.

      Other reservation options and styles may be at least K times the refresh timeout.  In addition, the
      traffic control mechanism defined in the network should be statically
      configured to grant high-reliability service to future
      (see Appendix D.4, for example).

2. RSVP messages, to
      protect Protocol Mechanisms

   2.1 RSVP messages from congestion losses.

      In steady state, refreshing is performed hop-by-hop, which allows
      merging Messages

      There are two fundamental RSVP message types: RESV and packing as described PATH .

      Each receiver host sends RSVP reservation request (RESV) messages
      towards the senders.  These reservation messages must follow in
      reverse the next section.  However, if routes the received state differs from data packets will use, all the stored state, way upstream
      to the stored state
      is updated.  Furthermore, if sender hosts included in the result will scope.  RESV messages must be
      delivered to modify the
      refresh sender hosts so that the hosts can set up
      appropriate traffic control parameters for the first hop.

      Also note that RSVP sends no positive acknowledgment 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
      indicate success (although the delivery of a
      change stops when and if it reaches a point where merging causes
      no resulting state change; this minimizes RSVP control traffic due reservation request
      to changes, and is essential for scaling a sender could be used to large multicast
      groups.

      The "soft" router trigger an acknowledgement at a
      higher level of protocol.)
            Sender                                       Receiver
                          _____________________
               Path -->  (                     )
             Si =======> (    Multicast        ) Path -->
               <-- Resv  (                     ) =========> Rj
                         (    distribution     ) <-- Resv
                         (_____________________)

                           Figure 4: RSVP Messages

      Each sender transmits RSVP PATH messages forward along the uni-
      /multicast routes provided by the routing protocol(s); see Figure
      4.  These "Path" messages store path state maintained in each node.  Path
      state is used by RSVP is dynamic; to change route the set RESV messages hop-by-hop in the
      reverse direction.  (In the future, some routing protocols may
      supply reverse path forwarding information directly, replacing the
      reverse-routing function of senders Si or receivers Rj or to change any QoS
      request, a host simply starts sending revised path state).

      PATH and/or RESV
      messages. messages may also carry the following information:

      o    Sender Template

           The result should be Sender Template describes the appropriate adjustment format of data packets that
           the sender will originate.  This template is in the
      distributed RSVP state, and immediate propagation form of a
           filter spec that could be used to select this sender's
           packets from others in the
      succeeding nodes.

      The RSVP state associated with a same session in on the same link.

           Like a particular node filter spec, the Sender Template is
      divided into atomic elements that are created, refreshed, less than fully
           general at present, specifying only sender IP address,
           UDP/TCP sender port, and
      timed out independently. protocol id.   The atomicity is determined by port number
           and/or protocol id can be wildcarded.

      o    Tspec

           PATH message may optionally carry a Tspec that defines an
           upper bound on the
      requirement traffic level 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 sender will
           generate.  This Tspec can be a one-to-one correspondence between state carried in used by 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.

   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 prevent over-
           reservation request will propagate as far as
      the closest point(s) along (and perhaps unnecessary Admission Control
           failure) on the sink tree to non-shared links starting at the sender(s) where sender.

      o    Adspec

           The PATH message may carry a
      reservation level equal or greater than that being requested has
      been made.  At that point, the merging process will drop it in
      favor package of another, equal or larger, reservation request.

      Although flowspecs are opaque to RSVP, OPWA advertising
           information, known as an RSVP daemon must be able
      to calculate the "largest" of "Adspec".  An Adspec received in a set of flowspecs.  This
           PATH message is
      required both passed to calculate the effective flowspec to install on a
      given physical interface (see local traffic control routines,
           which return an updated Adspec; 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 updated version is
           forwarded downstream.

       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 5: Router Using RSVP

      Figure 5 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 Tspec the
      incoming and Rspec components, each of which outgoing roles (for different data flows but the same
      session).

      As illustrated in Figure 5, there may
      itself be multi-dimensional), they are not strictly ordered.  When
      it cannot take multiple previous hops
      and/or next hops through a given physical interface.  This may
      result from the larger connected network being a shared medium or from
      the existence of two flowspecs, non-RSVP routers in the path to the next RSVP hop
      (see Section 2.6).  An RSVP daemon must compute preserve the next and
      use a third flowspec that
      previous hop addresses in its reservation and path state,
      respectively.  A RESV message 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 sent with a unicast destination
      address, the address of a previous hop.   PATH messages, on the rules for comparing flowspecs are
      outside RSVP proper, but they
      other hand, are defined as part of sent with the service
      templates.

      For protocol efficiency, RSVP also allows session destination address, unicast
      or multicast.

      Although multiple sets of path
      (or reservation) information for next hops may send reservation requests through
      the same session to physical interface, the final effect should be "packed"
      into to install
      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 on that interface, which is not explicitly deleted.

      A teardown request may be initiated either defined by an application in an
      end system (sender or receiver), or by a router as effective
      flowspec.  This effective flowspec will be the result "maximum" of
      state timeout.  A router may also initiate a teardown message as the result of router or link failures detected
      flowspecs requested by the routing
      protocol.  Once initiated, different next hops.  In turn, a teardown request should be forwarded
      hop-by-hop without delay.

      To increase the reliability of teardown, Q copies of any given
      teardown RESV
      message can be sent.  Note that forwarded to a node cannot actually
      delete the state being torn down until it has sent Q Teardown
      messages; it must place the state in particular previous hop carries a "moribund" status
      meanwhile.  The appropriate value of Q flowspec
      that is an engineering issue.  Q
      = 1 would be the simplest and may be adequate, since unrefreshed
      state will time out anyway; teardown "maximum" over the effective reservations on the
      corresponding outgoing interfaces.  Both cases represent merging,
      which is an optimization.  If one
      or more Teardown message hops discussed further below.

      There are lost, the router that failed to
      receive a Teardown message will time out its state and initiate number of ways for a new Teardown message beyond or modified reservation
      request to fail in a given node:

      1.   The effective flowspec, computed using the loss point.  Assuming that RSVP
      message loss probability is small, new request, may
           fail admission control.

      2.   Administrative policy or control may prevent the longest time to delete
      state will seldom exceed one refresh timeout period. requested
           reservation.

      3.   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 may be no matching path state along (i.e., the scope may be
           empty), which would prevent the way.  A
      RTEAR message tears down reservation state and travels towards all
      senders upstream from its point of initiation. being propagated
           upstream.

      4.   A PTEAR (RTEAR)
      message reservation style that requires a unique sender may be conceptualized as have a reversed-sense Path message
      (Resv message, respectively).

      A teardown message deletes the specified state
           filter spece that matches more than one sender in the node where
      it is received.  Like any other state change, this will be
      propagated immediately path
           state, due 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 use of wildcards.

      5.   The requested style may be forwarded at incompatible with the same node where
      merging suppresses forwarding style(s) of
           existing reservations for the corresponding RESV messages. same session on the same
           outgoing interface, so an effective flowspec cannot be
           computed.

      6.   The change requested style may be incompatible with the style(s) of
           reservations that exist on other outgoing interfaces but will
           be propagated as merged with this reservation to create a new teardown refresh message if
           for the
      result has been previous hop.

      In any of these cases, an error message is returned to remove all state the
      receiver(s) responsible for this session at this node.
      However, the result erroneous message, which may simply or
      may not be to change the propagated
      information; thus, forward along the receipt of a RTEAR path.  An error message may result
      does not modify state in the immediate forwarding of a modified RESV refresh message.

      Deletion of path state, whether as the result of a teardown
      message or because nodes through which it passes.
      Therefore, any reservations established downstream of timeout, may force adjustments in order in
      related reservation state to maintain consistency in the local
      node.  For example, when a PTEAR deletes node
      where the path state for a
      sender S, failure was detected will persist until the adjustment in reservation depends upon receiver(s)
      responsible cease attempting the style: reservation.

      In general, if the style is WF and S error is the only sender likely to be repeated at every node
      further along the session, delete
      the reservation; if the style path, it is FF, delete only reservations best to drop the errneous message
      rather than generate a flood of error messages; this is the case
      for
      sender S.  These reservation changes should the last four error classes listed above.  The first two error
      classes, admission control and administrative policy, may or may
      not trigger an
      immediate RESV refresh message, since allow propagation of the teardown message will
      have already made message, depending upon the required changes upstream.  However, at detailed
      reason and perhaps on local administrative policy and/or the
      node
      particular service request.  More complete rules are given in which an RTEAR message stops, the change of reservation
      state may trigger
      error definitions in Appendix B.

      An erroneous FILTER_SPEC object in a RESV refresh starting at that node.

   2.5 Security

      There are two distinct types of security concerns in RSVP.

      1.   Protecting RSVP Message Integrity

           It may message will normally be necessary to ensure
      detected at the integrity of first RSVP messages
           against corruption or spoofing, hop by hop.  RSVP messages
           have from the receiver application,
      i.e., within the receiver host.  However, an optional integrity field that can be created and
           verified admission control
      failure caused 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 FLOWSPEC or a POLICY_DATA object may be necessary
      detected anywhere along the path(s) to the sender(s).

      When admission control who gets privileged service and to collect billing
           information.  These mechanisms may require secure
           authentication of senders and/or receivers responsible fails for a reservation request, any
      existing reservation is left in place.  This prevents a new, very
      large, reservation from disrupting the reservation.  RSVP messages existing QoS by merging
      with an existing reservation and then failing admission control
      (this has been called the "killer reservation" problem).

      A node may contain credential
           information be allowed 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, preempt an
      intermediate cloud that does not support RSVP is unable to perform
      resource established 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 in
      accordance with administrative policy; this will automatically tunnel through such a non-RSVP cloud.
      Both RSVP also trigger an
      error message to all affected receivers.

   2.2 Merging 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 Packing

      A previous section explained that reservation requests in RESV
      messages are necessarily merged, to match the path.  When a PATH message
      traverses multicast
      distribution tree.  As a non-RSVP cloud, result, only the copies that emerge essential (i.e., the
      "largest") reservation requests are forwarded, once per refresh
      period.  A successful reservation request will carry propagate as far as a
      Previous Hop address
      the IP address of closest point(s) along the last RSVP-capable
      router before entering sink tree to the cloud.  This will effectively construct sender(s) where a tunnel through
      reservation level equal or greater than that being requested has
      been made.  At that point, the cloud for RESV messages, which merging process will be
      forwarded directly to the next RSVP-capable router on the path(s)
      back towards the source.

      Automatic tunneling is not perfect; in some circumstances drop it may
      distribute in
      favor of another, equal or larger, reservation request.

      For protocol efficiency, RSVP also allows multiple sets of path
      (or reservation) information to RSVP-capable routers not included
      in for the data distribution paths, which may create unused
      reservations at these routers.  This is because same session to be "packed"
      into a single PATH messages
      carry the IP source address of (or RESV) message, respectively.  (For
      simplicity, the previous hop, not of protocol currently prohibits packing different
      sessions into the
      original sender, same RSVP message).  Unlike merging, packing
      preserves information.

      In order to merge reservations, RSVP must be able to merge
      flowspecs and multicast routing may depend upon to merge filterspecs.  Merging flowspecs requires
      calculating the source
      as well as the destination address.  This can be overcome by
      manual configuration "largest" 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 set of the
      subflows in a hierarchically encoded flow.  However, these
      separate sessions flowspecs, which are logically related.  For example it may be
      necessary
      otherwise opaque to pass reservations for all subflows RSVP.  Merging flowspecs is required both to Admission
      Control at
      calculate the same time (since it would be nonsense effective flowspec to admit high
      frequency components but reject the baseband component of the
      session data).  Such install on a logical grouping is indicated given physical
      interface (see the discussion in RSVP by
      defining connection with Figure 5), and to
      merge flowspecs when sending 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 refresh message for 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 sessions.  A SESSION_GROUP object
      contains four fields: a reference address, a session group ID, a
      count, larger of two flowspecs, RSVP must compute and use a rank.

      o    The reference address
      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 agreed-upon choice from among error.  The definition and
      implementation of the
           DestAddress values rules for comparing flowspecs are outside
      RSVP proper, but they are defined as part of the sessions in service templates
      [ServTempl95a]

      We can now give the group, complete rules for example calculating the smallest numerically.

      o    The session group ID is used effective
      flowspec (Te, Re), to distinguish different groups
           with the same reference address.

      o    The count be installed on an interface.  Here Te is
      the number of members in the group.

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

      The SESSION_GROUP objects for all sessions effective Rspec.  As an example,
      consider interface (d) in Figure 5.

      o    Re is calculated as the group will
      contain the same values largest (using an LUB if necessary)
           of the reference address, the session
      group ID, Rspecs in RESV messages from different next hops
           (e.g., D and D') but the count value. same outgoing interface (d).

      o    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 Tspecs supplied in PATH messages for from different previous
           hops which may send data packets to this reservation (e.g.,
           some or all
      `count' sessions have appeared (or until the end of the refresh
      cycle) A, B, and then pass the B' in Figure 5) are summed; call
           this sum Path_Te.

      o    The maximum Tspec supplied in RESV requests to Admission Control as a
      group.  It messages from different
           next hops (e.g., D and D') is calculated; call this Resv_Te.

      o    Te is normally expected that all sessions in the group
      will GLB (greatest lower bound) of Path_Te and Resv_Te.
           For Tspecs defined by token bucket parameters, this means to
           take the smaller of the bucket size and the rate parameters.

      Two filter specs can be routed merged only they are identical or if one
      contains the other through wild-carding.  The result is the same more
      general of the two, i.e., the one with more wildcard fields.

   2.3 Soft State

      To maintain reservation state, RSVP keeps "soft state" in router
      and host nodes.  However,  RSVP soft state is created and periodically
      refreshed by PATH and RESV messages.  The state is deleted if not, only a
      subset of no
      refreshes arrive before the session group reservations expiration of a "cleanup timeout"
      interval; it may appear at also be deleted as the result of an explicit
      "teardown" message.

      When a given
      node; in this case, route changes, the RSVP should wait until next PATH message will initialize the end of
      path state on the
      refresh cycle new route, and then perform Admission Control future RESV messages will
      establish reservation state; the state on the subset now-unused segment
      of the session group that it has received.  The rank values route will
      identify which are missing.

      Note that routing different sessions 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 session group
      differently will generally result in delays term
      "refresh message" in establishing or
      rejecting the desired QoS.  A "bundling" facility could be added
      to multicast routing, this effective sense, to force all sessions indicate an RSVP
      message that does not modify the existing state at the node in a session group
      question.)

      In addition to
      be routed along the same path.

   2.8 Host Model

      Before cleanup timeout, there is a session can be created, "refresh timeout"
      period.  As messages arrive, the session identification,
      comprised of DestAddress and perhaps RSVP daemon checks them against
      the generalized destination
      port, must be assigned existing state; if it matches, the cleanup timeout timer on
      the state is reset and communicated to all the senders message is dropped.  At the expiration
      of each refresh timeout period, RSVP scans its state to build and
      receivers
      forward PATH and RESV messages to succeeding hops.

      RSVP sends its messages as IP datagrams without reliability
      enhancement.  Periodic transmission of refresh messages by some out-of-band mechanism.  In order hosts
      and routers is expected to join an replace any lost RSVP
      session, messages.  To
      tolerate K-1 successive packet losses, the following events happen effective cleanup
      timeout must be at least K times the end systems.

      H1   A receiver joins refresh timeout.  In
      addition, the multicast group specified by
           DestAddress, using IGMP.

      H2   A potential sender starts sending RSVP PATH messages to traffic control mechanism in the
           DestAddress, using RSVP.

      H3   A receiver listens for PATH messages.

      H4   A receiver starts sending appropriate RESV network should be
      statically configured to grant high-reliability service to RSVP
      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 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 group (H1).  Then there will be no
           multicast routes beyond previous section.  If the host (or beyond
      received state differs from the first RSVP-
           capable router) along stored state, the path; stored state is
      updated.  Furthermore, if the data result will be dropped at to modify the first hop until receivers(s) do appear (assuming refresh
      messages to be generated, these refresh messages must be generated
      and forwarded immediately.  This will result in state 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 routing protocol that "prunes off"
      groups.

      The "soft" router state maintained by RSVP is dynamic; to change
      the set of senders Si or otherwise
           avoids unnecessary paths).

      o    Suppose that receivers Rj or to change any QoS
      request, a new sender host simply starts sending revised PATH messages (H2)
           and immediately starts sending data (H5), and there are
           receivers but no and/or RESV messages have reached
      messages.  The result should be an appropriate adjustment in the sender yet
           (e.g., because its PATH messages have not yet propagated
      RSVP state and immediate propagation to all nodes along the receiver(s)).  Then path.

      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 initial data
      requirement that any sender or receiver may arrive at
           receivers without enter or leave the desired QoS.

      o    If a receiver starts sending RESV messages (H4) before
      session at any
           PATH messages have reached it (H5) (and if path time, so its state is
           being used to route RESV messages), should be created and timed out
      independently.

   2.4 Teardown

      RSVP will return error teardown messages remove path and reservation state without
      waiting for the cleanup timeout period, as an optimization to
      release resources quickly.  It is not necessary (although it may
      be desirable, since the receiver.  The receiver resources being consumed may simply choose be
      "valuable"), to
           ignore such error messages, or it explicitly tear down an old reservation.

      A teardown request may avoid them be initiated either by waiting
           for PATH messages before sending RESV messages.

      A specific an application program interface (API) for RSVP is not
      defined in this protocol spec, as it may be host an
      end system dependent.
      However, Section 4.6.1 discusses the general requirements and
      presents (sender or receiver), or by a generic API.

3. Examples

   We use router as the following notation for result of
      state timeout.  Once initiated, a RESV message:

   1.   Wildcard-Filter

        WF( *{Q})

        Here "*{Q}" represents teardown request should be
      forwarded hop-by-hop without delay.

      Teardown messages (like other RSVP messages) are not delivered
      reliably.  However, loss of 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 teardown message is not considered a single RESV message.

   For simplicity we assume here that flowspecs are one-dimensional,
   defining for example
      problem because 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 will time out even if it is not
      explicitly deleted.  If one or more teardown message hops labeled
   (a) and (b) and two outgoing interfaces labeled (c) and (d).  This
   topology are
      lost, the router that failed to receive a teardown message will be assumed in
      time out its state and initiate a new teardown message beyond the examples
      loss point.  Assuming that follow. RSVP message loss probability is small,
      the longest time to delete state will seldom exceed one refresh
      timeout period.

      There are
   three upstream senders; packets from sender S1 (S2 two types of RSVP teardown message, PTEAR and S3) arrive
   through previous hop (a) ((b), respectively).  There are also three RTEAR.  A
      PTEAR message travels towards all receivers downstream receivers; packets bound for R1 from its
      point of initiation and R2 (R3) are routed via
   outgoing interface (c) ((d) respectively).

   In addition to the connectivity shown in 5, we must also specify deletes path state along the
   multicast routing within this node.  Assume first that data packets
   (hence, PATH messages) way.  A RTEAR
      message deletes reservation state and travels towards all senders
      upstream 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, 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 "Receive" column shows specified state in the RESV messages received
   over outgoing interfaces (c) and () and node where
      it is received.  Like any other state change, this will be
      propagated immediately to the "Reserve" column shows next node, but only if it represents
      a net change after merging.  As a result, an RTEAR message will
      prune the resulting reservation state for each interface.   The "Send"
   column shows the RESV messages forwarded to previous hops (a) back (only) as far as possible.

   2.5 Admission Policy and
   (b).  In Security

      RSVP-mediated QoS requests will result in particular user(s)
      getting preferential access to network resources.  To prevent
      abuse, some form of back pressure on users will be required.  This
      back pressure might take the "Reserve" column, each box represents one reservation
   "channel", with form of administrative rules, or of
      some form of real or virtual billing for the corresponding filter.  As `cost' of a result
      reservation.  The form and contents of merging,
   only such back pressure is a
      matter of administrative policy that may be determined
      independently by each administrative domain in the largest flowspec Internet.

      Therefore, admission control at each node is forwarded upstream likely 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 contain a
      policy component as well as a resource reservation component.  As
      input to previous hop b.  On the
   other hand, policy-based admission decision, RSVP messages may
      carry policy data.  This data may include credentials identifying
      users or user classes, account numbers, limits, quotas, etc.

      To protect the two different flow descriptors for sender S1 are
   merged into integrity of the single message FF( S1{3B} ), which is sent policy-based admission control
      mechanisms, it may be necessary to
   previous ensure the integrity of RSVP
      messages against corruption or spoofing, hop (a), by hop.  For each outgoing interface, there is this
      purpose, RSVP messages may carry integrity objects that can be
      created and verified by neighboring RSVP-capable nodes.  These
      objects are expected to contain an encrypted part and to assume a private
      shared secret between neighbors.

      User policy data in reservation for each source that request messages presents a
      scaling problem.  When a multicast group has been requested, but this private
   reservation is shared among a large number of
      receivers, it will not be possible or desirable to carry all the
      receivers' policy data upstream to the sender(s).  The policy data
      will have to be administratively merged, near enough to the
      receivers that made to avoid excessive policy data.  Administrative merging
      implies checking 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., user credentials and accounting data packets
   from S1, S2, and S3 are routed then
      substituting a token indicating the check has succeeded.  A chain
      of trust established using an integrity field will allow upstream
      nodes to both outgoing interfaces.  Assume accept these tokens.

      Note that the routing shown in Figure 8, in which merge points for policy data packets from S1 are not
   forwarded likely to interface (d) (because be at 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
      boundaries of administrative domains.  It may be necessary to
      carry accumulated and unmerged policy data upstream through
      multiple nodes before reaching one of these merge points.

   2.6 Automatic RSVP Tunneling

      It is no route from (a) impossible to (d), deploy RSVP (or any new protocol) at the reservation forwarded
   out interface (a) considers only same
      moment throughout the reservation on interface (c), so
   no merging takes place in this case.

                          |
            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

4. entire Internet.  Furthermore, RSVP Functional Specification

   4.1 may
      never be deployed everywhere.  RSVP Message Formats

      All 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 such a cloud has sufficient excess capacity, it may
      provide acceptable and useful realtime service.

      RSVP will automatically tunnel through such a non-RSVP cloud.
      Both RSVP and non-RSVP routers forward PATH messages consist towards the
      destination address using their local uni-/multicast routing
      table.  Therefore, the routing of a common header followed PATH messages will be unaffected
      by non-RSVP routers in the path.  When a
      variable number of variable-length typed "objects" using PATH message traverses a common
      structure.  The subsections
      non-RSVP cloud, the copies that follow define emerge will carry as a Previous
      Hop address the formats IP address of the
      common header, the object structures, and each of last RSVP-capable router before
      entering the RSVP message
      types.  For each RSVP message type, there is cloud.  This will effectively construct a set of rules tunnel
      through the cloud for RESV messages, which will be forwarded
      directly to 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
                   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 next RSVP-capable router on in a PATH message (i.e., the
                   first-[RSVP-]hop router) should institute policing
                   for path(s) back
      towards the flow(s) described source.

      Automatic tunneling is not perfect; in this message.  This flag
                   should never be forwarded some circumstances it may
      distribute path information to RSVP-capable routers not included
      in PATH refresh messages.

              0x02 = LUB-Used the data distribution paths, which may create unused
      reservations at these routers.  This flag is described below in because PATH messages
      carry the section on Error
                   Messages.

         Message Length

              The total length IP source address 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 previous hop, not of the RSVP
              message, with
      original sender, and multicast routing may depend upon the checksum field replaced source
      as well as the destination address.  This can be overcome by zero.

         Object Count

              Count of variable-length objects that follow.

      4.1.2 Object Formats

         An object consists
      manual configuration of one or more 32-bit words with the neighboring RSVP programs, when
      necessary.

   2.7 Host Model

      Before a one-word
         header, in session can be created, 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 session identification,
      comprised of 4, DestAddress and at least 4.

         Class

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

              0 = NULL

                   A NULL object has a Class of zero; its C-Type is
                   ignored.  Its length generalized destination
      port, 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) assigned and
                   possibly a generalized source port, communicated to define a
                   specific session for all the other objects that follow.
                   Required in every RSVP message.

              2 = SESSION_GROUP senders and
      receivers by some out-of-band mechanism.  When present, defines a an RSVP session group, a is
      being set of
                   related sessions whose reservation requests should be
                   passed collectively to Admission Control.

              3 = RSVP_HOP

                   Carries up, the IP address of following events happen at the RSVP-capable node that
                   sent this message.  This document refers to a
                   RSVP_HOP object as a PHOP ("previous hop") object for
                   downstream end systems.

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

      H2   A potential sender starts sending RSVP PATH messages or as a NHOP ("next hop") object
                   for upstream messages.

              4 = STYLE

                   Defines to the reservation style plus style-specific
                   information that is not a FLOWSPEC or FILTER_SPEC
                   object, in
           DestAddress, using RSVP.

      H3   A receiver application receives a RESV PATH message.

              5 = FLOWSPEC

                   Defines a desired QoS, in a

      H4   A receiver starts sending appropriate RESV message.

              6 = FILTER_SPEC

                   Defines a subset of session data packets that should
                   receive messages,
           specifying the desired QoS (specified by an FLOWSPEC
                   object), in flow descriptors, using RSVP.

      H5   A sender application receives a RESV message.

              7 = SENDER_TEMPLATE

                   Contains a

      H6   A sender IP address and perhaps some
                   additional demultiplexing information to identify a
                   sender, in starts sending data packets.

      There are several synchronization considerations.

      o    Suppose that a PATH message.

              8 = SENDER_TSPEC

                   Defines new sender starts sending data (H6) 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 traffic characteristics of a sender's data stream, in will be dropped at
           the first hop until receivers(s) do appear (assuming a PATH message.

              9 = ADVERT

                   Carries an Adspec containing OPWA data, in
           multicast routing protocol that "prunes off" or otherwise
           avoids unnecessary paths).

      o    Suppose that a new sender starts sending PATH
                   message.

              10 = TIME_VALUES

                   If present, contains values for the refresh period R messages (H2)
           and immediately starts sending data (H6), and there are
           receivers but no RESV messages have reached the state time-to-live T (see section 4.5), sender yet
           (e.g., because its PATH messages have not yet propagated to
                   override
           the default values receiver(s)).  Then the initial data may arrive at
           receivers without the desired QoS.  The sender could mitigate
           this problem by awaiting arrival of R and T.

              11 = ERROR_SPEC

                   Specifies an error, the first RESV message
           [H5]; however, receivers that are farther away may not have
           reservations in place yet.

      o    If 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 receiver starts sending RESV messages (H4) before any
           PATH messages have reached it (H3), RSVP will return error
           messages 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. receiver.  The Class and C-Type fields receiver may be used together as a 16-bit
         number simply choose to define a unique type
           ignore such error messages, or it may avoid them by waiting
           for each object.

         The formats of PATH messages before sending RESV messages.

      A specific object types are application program interface (API) for RSVP is not
      defined in Appendix A.

      4.1.3 Path Message

         PATH messages carry information from senders to receivers along
         the same paths, and using the same uni-/multicast routes, this protocol spec, as it may be host system dependent.
      However, Section 4.6.1 discusses the data packets.  The IP destination address of general requirements and
      presents a PATH message
         is generic API.

3. Examples

   We use the DestAddress following notation for the session, a RESV message:

   1.   Wildcard-Filter (WF)

        WF( *{Q})

        Here "*{Q}" represents a Flow Descriptor with a "wildcard" scope
        (choosing all senders) and the source address is
         an address of the node that sent the message (if possible, the
         address a flowspec of the particular interface through which it was sent).

         The format quantity Q.

   2.   Fixed-Filter (FF)

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

        A list of (sender, flowspec) pairs, i.e., flow descriptors,
        packed into 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 single RESV message.

   3.   Shared Explicit (SE)

        SE( (S1,S2,...)Q1, (S3,S4,...)Q2, ...)

        A list of shared reservations, each specified by a sender, single
        flowspec and the sender
         descriptor list allows multiple sender descriptors to be packed
         into a PATH message. list of senders.

   For each sender in the list, the
         SENDER_TEMPLATE object defines simplicity we assume here that flowspecs are one-dimensional,
   defining for example the format average throughput, and state them as a
   multiple of data packets, the
         SENDER_TSPEC object may specify the traffic flow, some unspecified base resource quantity B.

   Figure 6 shows schematically a router with two previous hops labeled
   (a) and the
         CREDENTIAL object may specify the user credentials.  There may
         also (b) and two outgoing interfaces labeled (c) and (d).  This
   topology will be an ADVERT object carrying advertising (OPWA) data.

         Each sender host must periodically send a PATH message
         containing assumed in the examples that follow.  There are
   three upstream senders; packets from sender descriptor(s) describing its own data
         stream(s), S1 (S2 and S3) arrive
   through previous hop (a) ((b), respectively).  There are also three
   downstream receivers; packets bound for a given session.  Each sender descriptor is
         forwarded R1 and replicated as necessary R2 (R3) are routed via
   outgoing interface (c) ((d) respectively).

   In addition 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 connectivity shown in 6, we must also specify 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
   multicast routing table, generally depend upon the
         (sender host address, DestAddress) pairs, and consist of a list
         of within this node.  Assume first that data packets
   (hence, PATH messages) from each Si shown in Figure 6 is routed to
   both outgoing interfaces.  Then  Under this assumption, Figures 7, 8, and 9
   illustrate Wildcard-Filter, Fixed-Filter, and Shared-Explicit
   reservations, respectively.

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

                      Figure 6: Router Configuration

   In Figure 7, the descriptors being forwarded
         through "Receive" column shows the same outgoing interface can be packed into as few
         PATH RESV messages as possible.  Note that multicast routing of path
         information is based on received
   over outgoing interfaces (c) and (d) and the sender address(es) from "Reserve" column shows
   the sender
         descriptors, not resulting reservation state for each interface.   The "Send"
   column shows the IP source address; this is necessary RESV messages forwarded to
         prevent routing loops; see Section 4.3.  PHOP (i.e., previous hops (a) and
   (b).  In the
         RSVP_HOP object) of "Reserve" column, each PATH message should contain the IP
         source address, box represents one reservation
   "channel", with the interface address through which corresponding filter.  As a result of merging,
   only the message largest flowspec is sent.

         PATH messages are processed at each node they reach forwarded upstream 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 each previous hop.

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

              Figure 7: Wildcard-Filter Reservation Example 1

   Figure 8 shows Fixed-Filter (FF) style reservations.  The flow
   descriptors for senders implied by the SENDER_TEMPLATEs in the
         sender descriptor list.

      4.1.4 Resv Messages

         RESV messages carry reservation requests hop-by-hop S2 and S3, received from
         receivers outgoing interfaces
   (c) and (d), are packed into the message forwarded to senders, along previous hop b.
   On the reverse paths of data other hand, the two different flow descriptors for sender S1
   are merged into the session.  The IP destination address of a RESV single 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 FF( S1{3B} ), which the RESV message is sent. The IP sent to
   previous hop (a).  For each outgoing interface, there is a private
   reservation for each source address that has been requested, but this private
   reservation is an
         address of shared among the node receivers that sent the message (if possible, made the
         address request.

   Finally, Figure 9 shows a simple example of the particular Shared-Explicit (SE)
   style reservations.  Here each outgoing interface through which it was sent).

         The permissible sequence of objects in has a RESV message depends
         upon the single
   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 that 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> shared by a list of senders.

                       |
                         <Style-FF> <flow descriptor list>

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

                         <flow descriptor list> <FILTER_SPEC> <FLOWSPEC>       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 8: Fixed-Filter Reservation Example

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

             Figure 9: Shared-Explicit Reservation Example

   The reservation scope, three examples just shown assume full routing, i.e., the set data packets
   from S1, S2, and S3 are routed to both outgoing interfaces.  The top
   part of senders towards which a
         particular reservation is Figure 10 shows another routing assumption:  data packets
   from S1 are not forwarded to be forwarded, is determined by
         matching FILTER_SPEC objects against interface (d), because the mesh topology
   provides a shorter path state created
         from SENDER_TEMPLATE objects, considering any wildcards for S1 -> R3 that
         may be present.

      4.1.5 Error Messages

         There are two types does not traverse this
   node.  The bottom 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 Figure 10 shows WF style reservations under this
   assumption.  Since there is the
              unicast address of a previous hop.

         o    RERR messages result no route from RESV messages and travel hop-
              by-hop towards the appropriate receivers, routed by (a) to (d), the reservation state.  At each hop,
   forwarded out interface (a) considers only the IP destination
              address reservation on
   interface (c); no merging takes place in this case.

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

                    Router Configuration

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

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

   Finally, we note that state that is the unicast address of received through a next-hop node.
              Routing particular
   interface Iout in never forwarded out the same interface.
   Conversely, state that is discussed below.

         RSVP error messages are triggered forwarded out interface Iout must be
   computed using only by processing state that arrived on interfaces different from
   Iout.  A trivial example of PATH this rule is illustrated in Figure 11,
   which shows a transit router with one sender 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>
             <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 one receiver on each set independently
   interface (and assumes one next/previous hop per interface).
   Interfaces (a) and return a separate error
         message (c) are both outgoing and incoming interfaces for each that is
   this session.  Both receivers are making wildcard-scope reservations,
   in error.

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

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

         o    The node that creates a RERR message as group, with the result exception of
              processing a RESV message should send the RERR message out the interface through next hop from which
   they came.  These result in independent reservations in the RESV arrived.

              In succeeding hops, the routing of a RERR message depends
              upon its style and upon routing.  In general, two
   directions.

                      ________________
                   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 |                | c
   ( R1, S1 ) <----->|     Router     |<-----> ( R2, S2 )
                     |________________|

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

                    Figure 11: Independent Reservations

4. RSVP Functional Specification

   4.1 RSVP Message Formats

      All RSVP messages consist 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 common header followed by a
      variable number of flowspecs.  Assume variable-length typed "objects".  The
      subsections that a
              reservation whose error is being reported was formed by
              merging two flowspecs Q1 and Q2 from different next hops.

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

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

              -    If Q1 object structures, and Q2 are incomparable, each of the error RSVP message
                   should be forwarded to both next hops, and types.

      For each RSVP message type, there is a set of rules for the LUB
                   flag should be turned on.

              The ERROR_SPEC
      permissible ordering and the LUB-flag should be delivered to the
              receiver application.  In the case choice 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 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 | Flags|    Type     |       RSVP Checksum       |
         +-------------+-------------+-------------+-------------+
         |       Message Length      |        (Reserved)         |
         +-------------+-------------+-------------+-------------+

         The fields in a RESV message will
              normally be detected at the first common header are as follows:

         Vers

              Protocol version number.  This is version 2.

         Flags

              (None defined yet)

         Type

              1 = PATH

              2 = RESV

              3 = PERR

              4 = RERR

              5 = PTEAR

              6 = RTEAR
         RSVP hop from Checksum

              A standard TCP/UDP checksum over the
              receiver application, i.e., within contents of the receiver host.
              However, an admission control failure caused RSVP
              message, with the checksum field replaced by a FLOWSPEC zero.

         Message Length

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

      4.1.2 Object Formats

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

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

         An object may be detected anywhere along header has the
              path(s) to following fields:

         Length

              A 16-bit field containing the sender(s).

      4.1.6 Teardown Messages

         There are two types total object length in
              bytes.  Must always be a multiple of RSVP Teardown message, PTEAR 4, and RTEAR.

         o    PTEAR messages delete path state (which at least 4.

         Class-Num

              Identifies the object class; values of this field are
              defined 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 Appendix A.  Each object class has a name,
              which will always be capitalized in this document.  An
              RSVP implementation must recognize the point following classes:

              NULL

                   A NULL object has a Class-Num of teardown
              initiation.  RTEAR message are routed like RESV messages, zero, and their IP destination address its C-Type
                   is the unicast address ignored.  Its length must be at least 4, but can
                   be any multiple 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 4.  A NULL object may appear
                   anywhere in the style-specific tail of a RTEAR message sequence of objects, and its contents
                   will be ignored and may be omitted.

         If by the state being deleted was created with user credentials
         from a CREDENTIAL field, then receiver.

              SESSION

                   Contains the matching PTEAR or RTEAR
         message must include matching CREDENTIAL field(s).

         [There is IP destination address (DestAddress) and
                   possibly a problem here: tearing down path state may
         implicitly delete reservation state.  But generalized destination port, to define a PTEAR message does
         not have credentials for the reservation state, only
                   specific session for the
         path state.  Some argue other objects that a CREDENTIAL may not be needed follow.
                   Required in
         teardown messages, on the assumption that false teardown
         messages can be injected only with every RSVP message.

              RSVP_HOP

                   Carries the collusion IP address of routers
         along the data path, and in RSVP-capable node that case, the colluding router can
         just
                   sent this message.  This document refers to a
                   RSVP_HOP object as well stop delivering the RESV messages, which will have
         the same effect.]

   4.2 Sending RSVP Messages

      RSVP a PHOP ("previous hop") object for
                   downstream messages are sent hop-by-hop between RSVP-capable routers or as
      "raw" IP datagrams, protocol number 46.  Raw IP datagrams are
      similarly intended a NHOP ("next hop") object
                   for upstream messages.

              TIME_VALUES

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

              STYLE

                   Defines the
      first/last hop router; however, it reservation style plus style-specific
                   information that is also possible to encapsulate
      RSVP messages as UDP datagrams for end-system communication, as
      described not a FLOWSPEC or FILTER_SPEC
                   object, in Appendix C.  UDP encapsulation will simplify
      installation of RSVP on current end systems, particularly when
      firewalls are a RESV message.

              FLOWSPEC

                   Defines a desired QoS, 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 RESV message.

              FILTER_SPEC

                   Defines a subset of service to RSVP packets.  RSVP session data packets that should
      not use significant bandwidth, but
                   receive the queueing delay for RSVP
      messages needs desired QoS (specified by an FLOWSPEC
                   object), in a RESV message.

              SENDER_TEMPLATE

                   Contains a sender IP address and perhaps some
                   additional demultiplexing information to be controlled.

      An RSVP identify a
                   sender, in a PATH or RESV message consists message.

              SENDER_TSPEC

                   Defines the traffic characteristics 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, sender's
                   data stream, in a message with PATH message.

              ADSPEC

                   Carries an Adspec containing OPWA data, in a long list of
      descriptors will be divided into segments PATH
                   message.

              ERROR_SPEC

                   Specifies an error, in a PERR or RERR message.

              POLICY_DATA

                   Carries information that will fit into
      individual datagrams, each carrying the same root fields.  Each of
      these messages will be processed at the receiving node, with allow a
      cumulative effect on the local state.  No explicit reassembly is
      needed.

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

      [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 decide whether an interface connected to a non-RSVP cloud associated reservation is
                   administratively permitted.  May appear in
      which some particular link far away has a smaller MTU.  This would
      affect only those sessions that happened PATH or
                   RESV message.

              INTEGRITY

                   Contains cryptographic data to use that link.
      Proper solution authenticate the
                   originating node, and perhaps to verify the contents,
                   of this case would require MTU discovery
      separately RSVP message.

              SCOPE

                   An explicit specification of the scope for each interface and each session, which is forwarding
                   a very
      large amount RESV message.

              TAG

                   Encloses a list of machinery one or more objects and some overhead for attaches a rare (?) case.
      Best approach seems
                   logical name or "tag" value to be them.  The tag value
                   is unique to rely on IP fragmentation the next/previous hop 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 session
                   (specified by the refresh period. HOP and SESSION objects, respectively).
                   The effect
      of such a loop enclosed object list is to keep state active "forever", even if the end
      nodes have ceased refreshing it (but "tagged sublist", and
                   the state will objects in it said to be deleted
      when "tagged" with the receivers leave tag
                   value.  Objects in a particular tagged sublist must
                   all have the multicast group and/or same class-num.

                   Tagged objects with the senders
      stop sending PATH messages).

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

      PATH messages are forwarded using routes determined by the
      appropriate routing protocol.  For routing that is source-
      dependent (e.g., be logically related, i.e., to be members of some multicast routing algorithms), the RSVP
      daemon must route each sender descriptor separately using the
      source addresses found in the SENDER_TEMPLATE
                   larger logical set of objects.  This
      should ensure  Note that there will be the tagged
                   sublist implies no auto-refresh loops ordering; it defines only a set of PATH
      information, even
                   objects.

                   The meaning of the logical relationship depends upon
                   the class-num of the tagged objects.

         C-Type
              Object type, unique within Class-Num.  Values are defined
              in a topology Appendix A.

         The maximum object content length is 65528 bytes.  The Class-
         Num and C-Type fields (together with cycles.

      Since PATH messages don't loop, they create path state defining the 'Optional' flag bit)
         may be used together as a
      loop-free reverse path 16-bit number to each sender.  As define 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 unique type
         for each object.

         The high-order bit of the Class-Num is used to determine what
         action a potential auto-refresh problem
      for RESV, RTEAR, and RERR messages with wildcard scope, as we now
      discuss.

      If node should take if it does not recognize the topology has no loops, Class-
         Num of an object.  If Class-Num < 128, then auto-refresh can be avoided,
      even for wildcard scope, with the following rule:

         A reservation request received from next hop N must not node should
         ignore the object but forward it (unmerged).  If Class-Num >=
         128, the message should be
         forwarded to N.

      This rule is illustrated in Figure 10, which shows a transit
      router with one sender rejected and one receiver an "Unknown Object
         Class" error returned.  Note that merging cannot be performed
         on each interface (and
      assumes one next/previous hop per interface).  Interfaces unknown object types; as 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 result, unmerged objects may be
         forwarded to all previous hops for the first node that does know how to merge them.
         The scaling limitations that this imposes must be considered
         when defining and deploying new object types.

      4.1.3 Path Message

         PATH messages carry information from senders in to receivers along
         the group, with paths used by the exception data packets.  The IP destination address
         of a PATH message is the next hop from which they
      came.  These result in independent reservation requests in DestAddress for the two
      directions, without session; the
         source address is 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 address of cycles in the
      topology.  [TBD!!].

      We treat routing of RERR messages as a special case.  They are node that 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 message
         (preferably the multicast tree to
      DestAddress, rooted at address of the node on interface through 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 was
         sent).  The PHOP (i.e., the corresponding
      reservations on RSVP_HOP) object of each PATH
         message should contain the two different interfaces. IP source address.

         The current
      implementation does NOT allow this; instead, it prevents mixing format 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 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> ::= <SENDER_TEMPLATE>  [ <SENDER_TSPEC> ]

                                    [ <POLICY_DATA> ]   [ <ADSPEC> ]

         Each sender descriptor defines a sender, and the new route.  This sender
         descriptor list allows fast adaptation multiple sender descriptors to
      routing changes without the overhead of be packed
         into a short refresh period.

   4.5 Time Parameters PATH message.  For each element of state, there are two time parameters: sender in the
      refresh period R and list, the time-to-live value T.  R specifies
         SENDER_TEMPLATE object defines the
      period between sending successive refreshes format 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 data packets; in
         addition, a SENDER_TSPEC object may specify the "cleanout time" is K *
      T.  Here K is traffic flow, a small integer; K-1 successive messages
         POLICY_DATA object may be lost
      before state is deleted.  Currently K = 3 is suggested.

      Clearly, specify user credential and accounting
         information, and an ADSPEC object may carry advertising (OPWA)
         data.

         Each sender host must periodically send PATH message(s)
         containing a smaller T means increased RSVP overhead.  If sender descriptor for each its own data stream(s).
         Each sender descriptor is forwarded and replicated as necessary
         to follow the router
      does not implement local repair, delivery path(s) for a smaller T improves data packet from the speed of
      adapting to routing changes.  With local repair, a router can be
      more relaxed about T, since same
         sender, finally reaching the periodic refresh becomes only a
      backstop robustness mechanism.

      There are three possible ways for a router applications on all receivers
         (except that it is not looped back to determine R and T.

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

      o    A router may adjust same application process as the value of T dynamically sender).

         It is an error to keep a
           constant total overhead send ambiguous path state, i.e., two or more
         Sender Templates that are different but overlap, due to refresh traffic;
         wildcards.  For example, if we represent a Sender Template as more
           sessions appear,
         (IP address, sender port, protocol id and use `*' to represent
         a wildcard, then each of the period following pairs of Sender
         Templates would be lengthened.  In this
           case, R = T could be used.

      o    R and T can be specified an error:

                 (10.1.2.3, 34567, *) and (10.1.2.3, *, *)

                 (10.1.2.3, 34567, *) and (10.1.2.3, 34567, 17)

         A PATH message received at a node is processed to create path
         state for all senders defined by SENDER_TEMPLATE objects in the end systems.  For this
           purpose, PATH
         sender descriptor list.  If present, any POLICY_DATA,
         SENDER_TSPEC, and RESV messages may contain the optional
           TIM_VALUES object.  When messages ADSPEC objects are merged and forwarded to
           the next hop, R should be also saved in the minimum R that has been
           received, and T should be path
         state.  If an error is encountered while processing a PATH
         message, a PERR message is sent to all senders implied by the maximum T that has been
           received.   Thus,
         SENDER_TEMPLATEs.

         Periodically, the largest T determines how long path state is
           retained, and the smallest R determines the responsiveness of
           RSVP scanned to route changes.  In the first hop, they create new PATH
         messages which are expected
           to be equal.  The RSVP API might allow an application to
           override forwarded upstream.  A node must
         independently compute the default value route for each sender descriptor
         being forwarded.  These routes, obtained from uni-/multicast
         routing, generally depend upon the (sender host address,
         DestAddress) pairs and consist of a particular session.

   4.6 RSVP Interfaces

      RSVP list of outgoing
         interfaces.  The descriptors being forwarded through the same
         outgoing interface may be packed into as few PATH messages as
         possible.  Note that multicast routing of path information is
         based on a router has interfaces the sender address(es) from the sender descriptors,
         not the IP source address; this is necessary to prevent routing and
         loops; see Section 4.3.

         Multicast routing may also report the expected incoming
         interface (i.e., the shortest path back to traffic control
      in the kernel.  RSVP sender).  If so,
         any PATH message that arrives on a host has an interface to applications
      (i.e, an API) and also an different interface should
         be discarded immediately.

         It is possible that routing will report no routes for a
         (sender, DestAddress) pair; path state for this sender should
         be stored locally but not forwarded.

      4.1.4 Resv Messages

         RESV messages carry reservation requests hop-by-hop from
         receivers to traffic control (if it
      exists on senders, along the host).

      4.6.1 Application/RSVP Interface

         This section describes a generic interface between an
         application and an RSVP control process. reverse paths of data flow for
         the session.  The details IP destination address of a real
         interface may be operating-system dependent; RESV message is
         the following can
         only suggest unicast address of a previous-hop node, obtained from the basic functions to be performed.  Some
         path state.  The IP source address is an address of
         these calls cause information to be returned asynchronously.

         o    Register

              Call: REGISTER( DestAddress , DestPort the node
         that sent the message.  The NHOP (i.e., the RSVP_HOP) object
         must contain the IP address of the (incoming) interface through
         which the RESV message is sent.

         The RESV message format is as follows:

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

                                     [ , SESSION_object <INTEGRITY> ]  , SND_flag , RCV_flag [ , Source_Address <TIME_VALUES> ]

                                     [ , Source_Port <SCOPE> ]

                                     <STYLE> <flow descriptor list>

         The following style-dependent rules control the composition of
         a valid flow descriptor list.

         o    WF Style:

                  <flow descriptor list> ::=

                        <FLOWSPEC> [ , Sender_Template <POLICY_DATA> ] [ , Sender_Tspec <FILTER_SPEC> ]

              A FILTER_SPEC that is entire wildcard may be omitted.

         o    FF style:

                  <flow descriptor list> ::=

                        <FLOWSPEC> [ , Data_TTL <POLICY_DATA> ] <FILTER_SPEC>
                        | <flow descriptor list> [ , UserCredential <FLOWSPEC> ]

                                      [ , Upcall_Proc_addr <POLICY_DATA> ] )  -> Session-id

              This call initiates RSVP processing for a session, <FILTER_SPEC>

              Each elementary FF style request is 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 single
              (FLOWSPEC, FILTER_SPEC) pair, and multiple such requests
              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 packed into the future.  Normally SESSION_object will be
              omitted; if it is supplied, it should be an
              appropriately-formatted representation flow descriptor list of a SESSION
              object.

              SND_flag should single
              RESV message.  A FLOWSPEC or POLICY_DATA object can be set true
              omitted if it is identical to the host will send data,
              and RCV_flag should be set true if most recent such object
              that appeared in the host will receive
              data.  Setting neither true is an error.  The optional
              parameters Source_Address, Source_Port, Sender_Template,
              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 list.

         o    SE style:

                  <flow descriptor list> ::= <SE descriptor>

                              | <flow descriptor list> <SE descriptor>

                  <SE descriptor> ::= <FLOWSPEC> [ <POLICY_DATA> ]

                                                    <filter spec list>

                  <filter spec list> ::=  <FILTER_SPEC>

                                  |  <filter spec list> <FILTER_SPEC>

              Each elementary SE style request is true, defined by 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 single SE
              descriptor, which the
                   data will be sent.  If it is omitted, includes 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, FLOWSPEC defining the port is "wild"
                   and can match any port in shared
              reservation, possibly a FILTERSPEC.

              -    Sender_Template

                   This parameter is included as an escape mechanism to
                   support POLICY_DATA object, and a more general definition list of
              FILTER_SPEC objects.  Multiple elementary requests, each
              representing an independent shared reservation, may be
              packed into the sender
                   ("generalized source port").  Normally this parameter flow descriptor list of a single RESV
              message.  A POLICY_DATA object may be omitted; omitted if it is supplied, it should be an
                   appropriately formatted representation
              identical to the most recent such object that appeared in
              the list.

         The reservation scope, i.e., the set of sender hosts towards
         which a
                   SENDER_TEMPLATE object.

              -    Sender_Tspec

                   This parameter particular reservation 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 forwarded, is being supplied on
         determined as follows:

         o    For a style with explicit scope, match each FILTER_SPEC
              object against the data packets.  It is
                   needed path state created from SENDER_TEMPLATE
              objects to ensure that Path messages do not have select a
                   scope larger than multicast data packets.

              Finally, Upcall_Proc_addr particular sender.  It 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 )
              A receiver uses this call if
              a FILTER_SPEC matches more than one SENDER_TEMPLATE, due
              to make wildcarding.  A SCOPE object, if present, should be
              ignored.

         o    For a resource reservation
              for the session registered as `session-id'.  The style
              parameter indicates with wildcard scope, a SCOPE object, if
              present, defines the reservation style.  The rest scope with an explicit list of sender
              IP addresses (see Section 4.3 below).  If there is no
              SCOPE object, the parameters depend upon the style, but generally these
              will include appropriate flowspecs and filter specs.

              The first RESERVE call will initiate scope is determined by the periodic
              transmission relevant set
              of RESV messages. senders in the path state.  A later RESERVE call may SCOPE object must be given sent
              in any wildcard scope RESV message that is forwarded to modify
              more than one previous hop.  See Section 4.3 below.

         If an outgoing message is too large to fit into the parameters MTU of the earlier call (but
              note that changing
         interface, it can be sent as multiple messages, as follows:

         o    For FF style, the reservations may result in
              admission control failure, depending upon flow descriptor list can be split as
              required to fit; the style).

              The RESERVE call returns immediately.  Following rest of the message should be
              replicated into each packet.

         o    For WF style, a RESERVE
              call, SCOPE object containing an asynchronous ERROR/EVENT upcall may occur at any
              time.

         o    Release

              Call: RELEASE( session-id )

              This call will terminate RSVP state for explicit list
              of sender IP addresses  can be split as required to fit;
              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 rest of the upcall procedure whose
              address was supplied in message should be replicated into each
              packet.

         o    For SE style, the REGISTER call.

              This upcall may occur asynchronously at any time after a
              REGISTER call and before a RELEASE call, flow descriptor list can be split as
              required 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 fit; the receipt rest of a PATH
                   message, indicating to the application that there message should be
              replicated into each packet.

              If a single SE descriptor is
                   at least one active sender.  This upcall provides
                   synchronizing information too large to fit, its filter
              spec list can similarly be split as required.  However,
              the receiver
                   application, and it may also provide parallel lists subsets 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 a particular filter spec list must appear.

                   Error_code and Error_value, and LUB-flag should each be
                   ignored
              enclosed 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 TAG objects carrying the error, and
                   Error_value may supply some additional (perhaps
                   system-specific) data about same tag value, so
              the error.  `List_count' receiver will be 1, and Filter_spec_list and Flowspec_list
                   will contain the Sender_Template and the Sender_Tspec
                   supplied in able to match each FILTER_SPEC object
              to the REGISTER call; Advert_list will
                   contain one NULL object.

              3.   Info_type = Resv Error

                   An Resv appropriate shared reservation.

      4.1.5 Error event indicates an Messages

         There are two types of RSVP 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 messages.

         o    PERR messages result from PATH messages and one
                   FLOWSPEC object.  These objects travel towards
              senders.  PERR messages are taken from the
                   RESV message that caused the error (unless routed hop-by-hop using 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 state; at each hop, the
              corresponding asynchronous upcall to IP destination address is the application only
              on
              unicast address of a previous hop.

         o    RERR messages result from RESV messages and travel towards
              the first occurrence, or when appropriate receivers.   They are routed hop-by-hop
              using the information to be
              reported changes.

      4.6.2 RSVP/Traffic Control Interface

         In reservation state; at each router and host, enhanced QoS hop, the IP
              destination address is achieved by a group the unicast address of
         inter-related traffic control functions:  a packet classifier,
         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 next-hop
              node.

         Errors encountered while processing error messages must not
         create further error messages.

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

                                       [ , Sender_Tspec] <INTEGRITY> ]  <ERROR_SPEC>

                                       <sender descriptor>

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

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

                                       [ , SD_rank , SD_end_flag <INTEGRITY> ] )

              This call passes a Flowspec defining a desired QoS to
              admission control.  It may also pass Sender_Tspec, the
              maximum traffic characteristics computed over  <ERROR_SPEC>

                                      <STYLE> <error flow descriptor>

         The following style-dependent rules control the
              SENDER_TSPECs composition 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. valid error flow descriptor.

         o    WF Style:

                  <error flow descriptor> ::= <FLOWSPEC> [ <FILTER_SPEC> ]

         o    FF style:

                  <error flow descriptor> ::=  <FLOWSPEC> <FILTER_SPEC>

         o    SE style:

                  <error flow descriptor> ::= <FLOWSPEC> <filter spec list>

         The SD_rank ERROR_SPEC object specifies the error and SD_end_flag fields are used for a member includes the IP
         address of a session group.  SD_rank is the rank value from node that detected the
              SESSION_GROUP object.  The call is made error (Error Node
         Address).

         When a PATH or RESV message has been "packed" with each multiple
         sets of elementary parameters, the
              sessions in the group, and SD_end_flag is RSVP implementation should
         process each set true for the
              last one.

              This call returns an independently and return a separate error code if Flowspec
         message for each that is malformed
              or if in error.

         In general, error messages should be delivered to the requested resources are unavailable.  Otherwise,
              it establishes a new reservation channel corresponding to
              Rhandle.  It returns
         applications on all the opaque number Rhandle for
              subsequent references session nodes that (may have)
         contributed to this reservation.

         2.   Add Filter

              Call: TC_AddFilter( Rhandle, Session, Filterspec )

              This call error.  More specifically:

         o    A PERR message is used forwarded to define a filter corresponding all previous hops for all
              senders listed in the Sender Descriptor List.

         o    A RERR message is generally forwarded to all receivers
              that may have caused the
              given handle, following error being reported.

              The node that creates 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
              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 RERR message sends the
              reservation.  If new_Flowspec is included, it is passed RERR
              message to
              Admission Control; if it is rejected, the current flowspec
              is left in force.  If new_Flowspec is omitted, next hop from which the erroneous
              reservation is deleted came.  The message must contain the
              information required to define the error and Rhandle is invalidated.

         5.   OPWA Update

              Call: TC_Advertise( interface, Adspec

                              [ ,Sender_TSpec ] ) -> New_Adspec

              This call is used for OPWA to compute route the outgoing
              advertisement New_Adspec for
              error message.  Thus, it contains the STYLE, a specified interface.

         6.   Initialize Traffic Control

              Call: TC_Initialize(interface )

              This call FLOWSPEC,
              and one or more FILTER_SPEC(s) from the erroneous RESV
              message.

              In succeeding hops, a RERR message is used when RSVP initializes its forwarded using the
              node's reservation 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 next hops of reservations
              that match the
         packet forwarding FILTER_SPEC(s) and routing mechanism of the node.

         o    Promiscuous receive mode for RSVP messages

              Any datagram received for IP protocol 46 FLOWSPEC in the RERR
              message.  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 diverted forwarded
                   only to the RSVP program next hop for processing, without being
              forwarded.  The identity of Q2.

              -    If Q1 and Q2 are incomparable, the interface on which it is
              received error message
                   should also be available forwarded to both next hops, and the RSVP daemon.

         o    Route discovery
              RSVP must LUB-
                   Used flag should be able to discover the route(s) turned on.

              The RERR message that is forwarded should carry 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
              FILTER_SPEC from the corresponding reservation state (thus
              `un-merging' the filter spec).  For reservations with
              wildcard scope, there is an asynchronous notification additional limitation on
              forwarding RERR messages, to RSVP
              that avoid loops; see Section 4.3
              below.

              When 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 RERR message reaches a (multicast) datagram to receiver, the STYLE object,
              flow descriptor list, and ERROR_SPEC object (which
              contains the LUB-Used flag) should be
              sent on a specific outgoing virtual link, bypassing delivered to 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
              receiver application.  In the case of outgoing PATH messages on different
              interfaces, for an Admission Control
              error, the same source and destination addresses,
              and to avoid loops.

         o    Discover Interface List

              RSVP must flow descriptor list will contain the FLOWSPEC
              object that failed.  If the LUB-Used flag is off, this
              should be able `equal' to learn what real and virtual
              interfaces exist.

5. Message Processing Rules

   This generic description of RSVP operation assumes (but not necessarily identical to)
              the following data
   structures.  An actual implementation FLOWSPEC originated by this application; otherwise,
              they may use additional or different
   structures to optimize processing. differ.

      4.1.6 Teardown Messages

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

         o    PSB -- Path State Block

        Each PSB holds    A PTEAR message deletes path state for a particular (session, sender)
        pair, defined by SESSION and SENDER_TEMPLATE objects,
        respectively.  PSB contents include a PHOP object (which may, in turn,
              delete reservation state) and possibly
        SENDER_TSPEC, CREDENTIAL, and/or ADVERT objects travels towards all
              receivers that are downstream from the point of
              initiation.  A PTEAR message is routed like a PATH
        messages.
              message, and its IP destination address is DestAddress for
              the session.

         o    RSB -- Reservation State Block

        RSB's are used to hold reservation state.  Each RSB holds    A RTEAR message deletes 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 travels
              towards all matching senders upstream from 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 point of common header,
   and discard
              teardown initiation.  A RTEAR message if it fails.

   Further processing depends upon is routed like a
              corresponding RESV message type.

   PATH MESSAGE ARRIVES

        Start with (using the Refresh_Needed flag off.

        Each sender same scope rules).
              Its IP destination address is the unicast address of a
              previous hop.

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

                                         [ <INTEGRITY> ]

                                         <sender descriptor object sequence list>

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

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

                                         [ <INTEGRITY> ] [ <SCOPE> ]

                                         <STYLE> <flow descriptor list>

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

         FLOWSPEC or POLICY_DATA objects in the message defines a
        sender.  Process each sender as follows.

        1.   If there is flow descriptor list of
         a CREDENTIAL object, verify it; if it is
             unacceptable, build RTEAR message will be ignored and send a PERR message, drop may be omitted.

         Note that the PATH
             message, and return.

        2.   If there is no path state block (PSB) for RTEAR message will cease to be forwarded at the (session,
             sender) pair then:

             o    Create
         same node where merging suppresses forwarding of the
         corresponding RESV messages.  The change will be propagated as
         a new PSB.

             o    Set a cleanup timer for the PSB.  If this is teardown message if the first
                  PSB result has been to remove all
         state for this session at this node; otherwise, it may result
         in the session, set immediate forwarding of a modified RESV refresh timer for message.

         Deletion of path state, whether as the
                  session.

             o    Copy PHOP into the PSB.  Copy into the PSB any result of the
                  following objects that are present a teardown
         message or because of timeout, may force adjustments in related
         reservation state to maintain consistency 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 local node.

         The adjustment in reservation state depends upon 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 style.
         For example, suppose a PERR message for
                  "Bad Credential", drop the PATH message, and return.

             o    Restart cleanup timer.

             o    Update the PSB with values from PTEAR deletes the message, as
                  follows.  Copy path state for a
         sender S.  If the ADVERT object, style specifies distinct reservations (FF),
         only reservations for sender S should be deleted; if any, into the
                  PSB.  Copy the EntryPolice flag into style
         specifies shared reservations (WF or SE), delete the PSB.

                  If
         reservation if this was the values of PHOP or SEND_TSPEC differ between last filter spec.  These
         reservation changes should not trigger an immediate RESV
         refresh message, since the teardown message and the PSB, copy will have already
         made the new values into required changes upstream.  However, at the PSB
                  and turn on node in
         which a RTEAR message stops, the Refresh_Needed flag.  If SEND_TSPEC
                  has changed, reservations matching S may also change;
                  this change of reservation state
         may be deferred until trigger a RESV refresh arrives.

             o    Call the appropriate route discovery routine and
                  compare the route mask with starting at that node.

   4.2 Sending RSVP Messages

      RSVP messages are sent hop-by-hop between RSVP-capable routers as
      "raw" IP datagrams with protocol number 46.  Raw IP datagrams are
      similarly intended to be used between an end system and the ROUTE_MASK value
                  already
      first/last hop router; however, it is also possible to encapsulate
      RSVP messages as UDP datagrams for end-system communication, as
      described in the PSB; if a new bit (interface) has been
                  added, turn Appendix C.  UDP encapsulation may simplify
      installation of RSVP on the Refresh_Needed flag.  Store new
                  ROUTE_MASK current end systems, particularly when
      firewalls are in use.

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

      An RSVP PATH or RESV message generally consists of a small root
      segment followed by a potentially unbounded variable-length list
      of objects.  The variable part may overflow the PSB.

        4. capacity of one
      datagram.  If RSVP used IP fragmentation and reassembly (or an
      equivalent byte-by-byte fragmentation mechanism at the Refresh_Needed flag is now set, execute RSVP
      level), loss of a single packet would unnecessarily lose the PATH
             REFRESH event sequence (below).

   PATH TEAR MESSAGE ARRIVES

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

        o    Forward a copy session.  It is instead recommended that
      an RSVP implementation use "semantic" fragmentation, using the
      structure of the PTEAR RSVP message.

      An unbounded list in an RSVP message using the same rules as in fact consists of
      individual atomic elements that are packed together for
      efficiency.  Wben sending 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, message, an RSVP should therefore pack
      only what will fit into one packet, and then continue packing with
      the next sender descriptor.

             2.   Examine packet, etc.  Each of these messages will be processed
      independently at the receiving node, each updating its part of the RSB's for this
      session and delete any
                  reservation state associated with sender S, depending
                  upon in the reservation style.  For example:

                  Delete a WF reservation for which S node.  No explicit reassembly is the only
                       sender.

                  Delete an FF reservation for S.

             3.   Delete the PSB.

   PATH ERROR MESSAGE ARRIVES

        o    If there needed.

      Since RSVP messages 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 normally expected 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, be generated and ADVERT objects in sent
      hop-by-hop, their MTU should be determined by the message is ignored.

             Otherwise (PHOP is not local API), forward a copy MTU of each
      interface.

      Upon the
             PERR arrival of an RSVP message to M that changes the PHOP node.

   RESV MESSAGE ARRIVES
        A RESV message arrives through outgoing interface OI.

        o    Check state, a
      node must forward the SESSION object. modified state immediatly.  If there are no existing PSB's for SESSION then build and
             send a RERR message (as described later) specifying "No
             Path Information", drop this is
      implemented as an immediate refresh of all the RESV message, and return.
             However, do not send state for the RERR message if
      session, then no refresh messages should be sent out the style has
             wildcard reservation scope and this interface
      through which M arrived.  This rule is necessary to prevent packet
      storms on broadcast LANs.

      Some multicast routing protocols provide for "multicast tunnels",
      which encapsulate multicast packets for transmission through
      routers that do not have multicast capability.  A multicast tunnel
      looks like a logical outgoing interface that is mapped into some
      physical interface.  A multicast routing protocol that supports
      tunnels will describe a route using a list of logical rather than
      physical interfaces.  RSVP can support multicast tunnels in the receiver
             host itself.

        o    Check the STYLE object.

             If style
      following manner:

      1.   When a node N forwards a PATH message out a logical outgoing
           interface L, it includes in the message conflicts with some encoding of the style
           identity of any
             reservation for this session in place on any interface,
             reject L.  This information is carried (in the RESV message by building and sending HOP
           object) as a RERR
             message specifying "Bad Style", drop the RESV message, and
             return.

        o    Check value called the CREDENTIAL object.

             Verify "logical interface handle" or
           LIH.

      2.   The next hop node N' stores the CREDENTIAL field (if any) to check permission to
             create LIH value in its path state.

      3.   When N' sends a reservation.  [This check may also involve RESV message to N, it includes the
             CREDENTIAL fields LIH value
           from the PSB's path state (again, 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 HOP object).

      4.   When 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 message arrives at N, its LIH value provides
           the following once, using some internal
             placeholder "WILD_FILTER" for FILTERSPEC information necessary to indicate
             wildcard scope.

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

             2.   Start or restart
           appropriate logical interface.  Note that N creates and
           interprets the cleanout timer on LIH; it is an opaque value to N'.

   4.3 Avoiding RSVP Message Loops

      We must ensure that the RSB.

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

             4.   If the RSB existed and if FLOWSPEC forwarding RSVP control messages
      avoid looping.  In steady state, PATH and the
                  SENDER_TSPEC objects are unchanged, drop the RESV
                  message and return.

             5.   Compute Sender_Tspec as the maximum over messages are
      forwarded only once per refresh period on each hop.  This avoids
      directly looping packets, but there is still the
                  SENDER_TSPEC objects possibility of an
      " auto-refresh" loop, clocked by the PSB's within the scope refresh period.  The effect
      of
                  the reservation.

             6.   Set Police_flag on such a loop is to keep state active "forever", even if any PSB's in the scope end
      nodes have ceased refreshing it (but the
                  EntryPolice flag on, or if state will be deleted
      when the style is WF and there
                  is more than one PSB in receivers leave the scope, otherwise off.

             7.   Computer K_Flowspec, multicast group and/or the effective kernel flowspec, as senders
      stop sending PATH messages).  On the maximum of other hand, error and
      teardown messages are forwarded immediately and are therefore
      subject to direct looping.

      o    PATH Messages

           PATH messages are forwarded using routes determined by the FLOWSPEC values in all RSB's for
           appropriate routing protocol.  For routing that is source-
           dependent (e.g., some multicast routing algorithms), the same (SESSION, OI, FILTERSPEC) triple.  Similarly, RSVP
           daemon must route each sender descriptor separately using the kernel filter spec K_filter is either
           source addresses found in the
                  FILTER_SPEC object under consideration (unitary
                  scope), or it is WILD_FILTER (wildcard scope).

                  If SENDER_TEMPLATE objects.  This
           should ensure that there was will be no previous kernel reservation auto-refresh loops of
           PATH messages, even 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 topology with cycles.

           Consider each message
                  specifying "Admission control failed", drop type.

      o    PTEAR Messages

           PTEAR messages use the RESV
                  message, same routing as PATH messages 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)
           therefore cannot loop.

      o    PERR Messages

           Since PATH messages don't loop, they create path state
           defining a loop-free reverse path to set the filter, drop the RESV message each sender.  PERR
           messages are always directed to particular senders and return.

                  /item
           therefore cannot loop.

      o    RESV Messages

           Like PERR message, RESV messages directed to particular
           senders (i.e., with explicit scope) cannot loop.  However, if
           there was is a previous kernel
                  reservation potential for auto-refresh of RESV messages with handle K_handle, call
           wildcard scope; the kernel
                  interface module:

                     TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec)

                  If this call fails, build solution is presented below.

      o    RTEAR Messages

           RTEAR messages are routed the same as RESV messages and send a have
           an analogous looping problem for wildcard scope.

      o    RERR message
                  specifying "Admission control failed".  In any case,
                  drop Messages

           RERR messages for wildcard scope reservations have the RESV message same
           potential for looping as the reservations themselves, and return. the
           solution presented below is required.

      If processing a RESV message finds an error, the topology has no loops, then looping of wildcard-scoped
      messages can be avoided by simply enforcing the rule given
      earlier: state that is received through a RERR message particular interface
      must never be forwarded out the same interface.  However, when the
      topology does have cycles then further effort is
        created containing flow descriptor needed to prevent
      auto-refresh loops in wildcard-scope RESV, RTEAR, and RERR
      messages.  The solution is for such messages to carry an ERRORS explicit
      sender address list in a SCOPE object.  The
        Error Node field

      When a RESV or RTEAR message with wildcard scope is to be
      forwarded to a particular previous hop, a new SCOPE object is
      computed from the SCOPE objects that were received (in messages of
      the ERRORS same type).  If the computed SCOPE object (see Appendix A) is set empty, the
      message is not forwarded to the IP address of OI, and previous hop; otherwise, the
      message is sent unicast to NHOP.

        created containing the new SCOPE object.  The rules for
      computing a new SCOPE object for a RESV TEAR MESSAGE ARRIVES

        A or RTEAR message arrives on outgoing interface OI.

        o    If there are no existing PSB's as
      follows:

      1.   The union is formed of the sets of sender IP addresses listed
           in all SCOPE objects in the reservation state for SESSION then drop the
             RTEAR message given
           session.

           If reservation state from some NHOP does not contain a SCOPE
           object, a substitute sender list must be created and return.

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

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

             1.   Find matching RSB(s) for scope (WF) message that arrived
           on outgoing interface OI, the 4-tuple: (SESSION, NHOP,
                  style, FILTERSPEC).  If no RSB substitute list 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 ) set of
           senders that route to delete OI.  For an explicit scope (SE)
           message, it is 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 set of matching PSB.

             4.   Otherwise (there are other RSB's for senders explicitly listed in the same
                  reservation), recompute K_Flowspec and call
           message.

      2.   Any local senders are removed from this set.

      3.   If the kernel
                  interface module:

                     TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec) SCOPE object is to update the reservation, and then execute be sent to PHOP, remove from the
           set any senders that did not come from PHOP.

      Figure 12 shows an example of wildcard-scoped (WF style) 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
      messages.  The address lists within SCOPE objects are shown in
      square brackets.  Note that there may be additional connections
      among the ERRORS object.
             Let nodes, creating looping topology that is not shown.

                         ________________
                      a |                | c
           R4, S4<----->|     Router     |<-----> R2, S2, S3
                        |                |
                      b |                |
           R1, S1<----->|                |
                        |________________|

          Send on (a):           |    Receive on (c):
                                 |
             <-- WF( [S4] )      |       <-- WF( [S4, S1])
                                 |
          Send on (b):           |
                                 |
             <-- WF( [S1] )      |
                                 |
          Receive on (a):        |    Send on (c):
                                 |
             WF( [S1,S2,S3]) --> |       WF( [S2, S3]) -->
                                 |
          Receive on (b):        |
                                 |
             WF( [S2,S3,S4]) --> |
                                 |

           Figure 12: SCOPE Objects in Wildcard-Scope Reservations

      SCOPE objects are not necessary if the resulting multicast routing bit mask be M.

        o    Determine uses
      shared trees or if the set of RSBs matching reservation style has explicit scope.
      Furthermore, attaching a SCOPE object to a reservation may be
      deferred to a node which has more than one previous hop upstream.

      The following rules are used for SCOPE objects in wildcard-scoped
      RERR messages:

      1.   The node that detected the triple: (SESSION,
             style, FILTERSPEC).  If no RSB is found, drop error initiates an RERR message
             and return.

             Recompute the maximum over the FLOWSPEC objects of this set
           containing a copy of RSB's.  If the LUB was used in this computation, turn on SCOPE object associated with the LUB-flag
           reservation state or message in error.

      2.   Suppose a wildcard-scoped RERR message arrives at a node with
           a SCOPE object containing the received RESV message.

        o    Delete from sender host address list L.
           The node forwards the set RERR message using the rules of RSVs any whose OI does not appear in Section
           4.1.5.  However, 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 forwarded out OI must
           contain a SCOPE object derived from the received packet, as
             possibly modified above.

             Otherwise (NHOP L by including only those
           senders that route to OI.  If this SCOPE object is not local API), forward a copy of empty, the
           RERR message to the PHOP node.

   PATH REFRESH

   This sequence may should not be entered by either the expiration of the path
   refresh timer for sent out OI.

   4.4 Local Repair

      When a particular session, or immediately as route changes, the result
   of processing a next PATH message turning on or RESV refresh will establish
      path or reservation state (respectively) along the Refresh_Needed flag.

   For each virtual outgoing interface ("vif") V, build a PATH message
   and send it to V. new route.  To build the message, consider each PSB whose
   ROUTE_MASK includes V, and do
      provide fast adaptation to routing changes without the following:

   o    Pass overhead of
      short refresh periods, the ADVERT and SENDER_TSPEC objects present in local routing protocol module can
      notify the PSB 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 kernel call TC_Advertise, and get back a modified ADVERT
        object.  Pack this modified object into new route.

      More specifically, the PATH message being
        built. rules are as follows:

      o    Create    When routing detects a sender descriptor sequence containing the
        SENDER_TEMPLATE, CREDENTIAL, and SENDER_TSPEC objects, if
        present in the PSB.  Pack the sender descriptor into change of the set of outgoing
           interfaces for sending PATH
        message being built. messages for destination G, RSVP
           should send immediate PATH refreshes for all sessions G/*
           (i.e., for any session with destination G, regardless of
           destination port).

      o    If    When a PATH message arrives with a Previous Hop address that
           differs from the PSB has one stored in the EntryPolice flag on and if interface V is not
        capable path state, RSVP should
           send immediate RESV refreshes for that session.

   4.5 Time Parameters

      There are two time parameters relevant to each element of policing, turn the EntryPolice flag on RSVP
      path or reservation state in a node: the PATH
        message being built.

   o    If the maximum size of refresh period R between
      receiving successive refreshes for the state, and its lifetime L.
      Each RSVP RESV or PATH message may contain a TIME_VALUES object
      specifying the R value that was used to generate this refresh
      message; this is reached, send used to determine the
        packet out interface V L when the state is
      received and start packing stored.

      In more detail:

      1.   To avoid premature loss of state, we require that L >= (K +
           0.5)* R, where K is a new one.

   RESV REFRESH

   This sequence small integer.  Then K-1 successive
           messages may be entered by either lost without state being deleted.  Currently
           K = 3 is suggested.

      2.   Each message will generally carry a TIME_VALUES object
           containing the expiration R used to generate refreshes; the recipient
           node uses this R to determine L of the
   reservation refresh timer for stored state.

           However, if a particular session, or immediately as default R = Rdef is used, the result of processing TIME_VALUES
           object may be omitted from a RESV message.

   Each PSB for this session  Rdef is considered in turn, currently
           defined to compute a style-
   dependent tail sequence.  These sequences for a given PHOP are then
   packed into be 30 seconds.

      3.   This document does not specify the same message(s) and sent interval R 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 used for
           generating refresh messages.  If the node does not correspond to implement
           local repair of reservations disrupted by route changes, a
           smaller R improves the API, do speed of adapting to routing changes
           (but increases overhead).  With local repair, a router can be
           more relaxed about R since the following.

   o    Compute (FLOWSPEC, FILTER_SPEC) Pair

        Select each RSB in whose reservation scope periodic refresh becomes only
           a backstop robustness mechanism.  A node may therefore adjust
           the PSB falls, and
        compute effective R dynamically to limit the maximum over overhead due to
           refresh messages.

      4.   The TIME_VALUES object could contain, in addition to the FLOWSPEC objects of this
           hop-by-hop R value, an end-to-end upper bound on R, called
           Rmax.  When Rmax is specified, a node cannot set of
        RSB's.  Also, select R > Rmax.
           However, a node is allowed to refuse an appropriate FILTER_SPEC.  The scope
        depends upon the style RSVP message (i.e.,
           drop it and the filter spec return an error) when it specifies an Rmax value
           that is so small that it would create unacceptable overhead.
           This refusal would look like a kind of the RSB:

        1.   WF: Select every RSB whose OI matches admission control
           failure.

      5.   However, when R is changed dynamically, there is a bit in limit to
           how fast it may increase.  Specifically, the
             ROUTE_MASK ratio of the PSB.

             In this case, FILTER_SPEC two
           successive values R2/R1 must not exceed 1 + Slew.Max.

           Currently, Slew.Max is the standard WILD_FILTER.

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

             In this case, FILTER_SPEC 0.30.  With K = 3, one packet may be
           lost without state timeout while R 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 increasing 30 percent
           per refresh cycle.

      6.   To improve robustness, a style (since style must node may temporarily send refreshes
           more often than R after a state change (including initial
           state establishment).

      7.   A node should randomize its refresh timeouts to avoid
           synchronization and burstiness of refreshes.

      8.   The values of Rdef, K, and Slew.Max used in an implementation
           should be
        consistent across RSB's for given session).  [??Again, need
        merging rules]]

   o    Build RESV packets

        Append this (FLOWSPEC, FILTER_SPEC pair) easily modifiable, as experience may lead to the RESV message
        being built for destination PHOP (from the PSB).  When the
        packet fills, or upon completion
           different values.  The possibility of all PSB's with the same
        PHOP, set the NHOP address dynamically changing K
           and/or Slew.Max in the message response to the interface
        address measured loss rates is for
           future study.

   4.6 RSVP Interfaces

      RSVP on a router has interfaces to routing and send to traffic control
      in the packet out that kernel.  RSVP on a host has an interface to the PHOP
        address.

   appendix
6. Object Type Definitions

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

   6.1 SESSION Class

      Currently, SESSION objects contain the pair: (DestAddress,
      DestPort), where DestAddress is traffic control (if it
      exists on the data destination address host).

      4.6.1 Application/RSVP Interface

         This section describes a generic interface between an
         application and
      DestPort is the UDP/TCP destination port.  Other SESSION C-Types
      could 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 ]

                         [ , Source_ProtID ]  [ , Sender_Template ]

                         [ , Sender_Tspec ]   [ , Data_TTL ]

                         [ , Sender_Policy_Data ]

                         [ , Upcall_Proc_addr ] )  -> Session-id

              This call initiates RSVP processing for a session, defined in
              by DestAddress together with the future 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 other demultiplexing
      conventions some more general definition of the
              session ("generalized destination port"), should that be
              necessary 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 future.  Normally SESSION_object will be
              omitted; if it is supplied, it should be an
              appropriately-formatted representation of a SESSION object: Class = 1, C-Type = 129

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +               IP6 DestAddress (16 bytes)              +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |        ////////////       |         DestPort          |
           +-------------+-------------+-------------+-------------+
   6.2 SESSION_GROUP Class

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

           +-------------+-------------+-------------+-------------+
           |               IPv4 Reference DestAddress              |
           +-------------+-------------+-------------+-------------+
           |      Session_Group ID     |    Count    |     Rank    |
           +-------------+-------------+-------------+-------------+
              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,
              Sender_Tspec, Data_TTL, and Sender_Policy_Data 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.  This parameter is needed on
                   a multihomed sender host.

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

              -    Source_ProtID

                   This is the IP protocol ID for the sender data.  If
                   it is omitted or zero, the protocol id is "wild" and
                   can match any protocol id in a FILTER_SPEC.

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

              -    Sender_Policy_Data

                   This optional parameter passes policy data for the
                   sender.  This data may be supplied by a system
                   service, with the application treating it as opaque.

              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 )

              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, filter specs, and
              possibly receiver policy data objects.

              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
              Upcall: <Upcall_Proc>( ) -> session-id, Info_type,

                            [ Error_code , Error_value , LUB-Used, ]

                            List_count, [ Flowspec_list,]

                            [ Filter_spec_list, ] [ Advert_list, ]

                            [ Policy_data ]

              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 to a receiver
                   application that there is at least one active sender.
                   It results from receipt of the first PATH message for
                   this session.

                   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'will be
                   the number in each list;  where these objects are
                   missing, corresponding null objects must appear.  The
                   Error_code, Error_value, LUB-Used flag, and
                   Policy_data parameters will be undefined in this
                   upcall.

              2.   Info_type = Resv Event

                   A Resv Event upcall indicates to a sender application
                   that a reservation for this session in place along
                   the entire path to at least one receiver.  It is
                   triggered by the receipt of the first reservation
                   message or by modification of previous reservation
                   state, for this session.

                   `List_count' will be 1, and Flowspec_list will
                   contain one FLOWSPEC, the effective QoS that would be
                   applicable to the application itself.
                   Filter_spec_list and Advert_list will contain one
                   NULL object.  The Error_code, Error_value, LUB-Used
                   flag, and Policy_data parameters will be undefined in
                   this upcall.

              3.   Info_type = Path Error

                   An Path Error event indicates an error in sender
                   information that was specified in the REGISTER call.

                   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 supplied in the
                   REGISTER call; Sender_Tspec and Advert_list will each
                   contain one NULL object.  The Policy_data parameter
                   will be undefined in this upcall.

              4.   Info_type = Resv Error

                   An Resv Error event indicates an error in processing
                   a reservation 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.

                   Filter_spec_list and Flowspec_list will contain the
                   FILTER_SPEC and FLOWSPEC objects from the error flow
                   descriptor (see Section 4.1.5).  List_count will
                   specify the number of FILTER_SPECS in
                   Filter_spec_list, while there will be one FLOWSPEC in
                   Flowspec_list.  The Policy_data parameter will be
                   undefined in this upcall.

              5.   Info_type = Policy Data

                   A Policy Information upcall passes a Policy_data
                   parameter containing policy information (accounting,
                   current costs, prices, quota, etc.) that arrived at
                   the receiver.

                   List_count will be zero, and the Error_code,
                   Error_value, and LUB-Used flag  parameters will be
                   undefined in this upcall.

              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,
         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( Interface, Flowspec

                                     [ , Sender_Tspec]

                                     , E_Police_Flag , M_Police_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.

              E_Police_Flag and M_Police_Flag are Boolean parameters.
              E_Police_Flag is on if this is an entry node, while
              M_Police is on if this node is an interior data merge
              point for a shared reservation style.  These flags are
              used to enable traffic policing or shaping when
              appropriate, in accordance with the service.

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

              Call: TC_ModFlowspec( Rhandle, new_Flowspec

                                  [ , Sender_Tspec] , Police_flag )

              This call can modify an existing reservation.  If
              new_Flowspec is included, it is passed to Admission
              Control; if it is rejected, the current flowspec is left
              in force.  The corresponding filter specs, if any, are not
              affected.

         3.   Delete Flowspec

              Call: TC_DelFlowspec( Rhandle )

              This call will delete an existing reservation, including
              the flowspec and all associated filter specs.

         4.   Add Filter Spec

              Call: FHandle = TC_AddFilter( Rhandle, Session , FilterSpec )

              This call is used to associate an additional filter spec
              with the reservation specified by the given Rhandle,
              following a successful TC_AddFlowspec call.  This call
              returns a filter handle FHandle.

         5.   Delete Filter Spec

              Call: TC_DelFilter( FHandle )

              This call is used to remove a specific filter, specified
              by FHandle.

         6.   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.
              Sender_TSpec is also passed if it is available.

         7.   Preemption Upcall

              Upcall: TC_Preempt() -> RHandle, Reason_code

              In order to grant a new reservation request, the admission
              control and/or policy modules may be allowed to preempt an
              existing reservation.  This might be reflected in an
              upcall to RSVP, passing the RHandle of the preempted
              reservation, and some indication of the reason.

      4.6.3 RSVP/Routing Interface

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

         o    Promiscuous receive mode for RSVP messages

              Any datagram received for IP protocol 46 must 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 Query

              RSVP must be able to query the routing daemon for the
              route(s) for forwarding a specific datagram.

                 Ucast_Route_Query( DestAddress, Notify_flag ) -> OutInterface

                 Mcast_Route_Query( SrcAddress, DestAddress, Notify_flag )

                                              -> OutInterface_list

              If the Notify_flag is True, routing will save state
              necessary to issue unsolicited route change notification
              callbacks whenever the specified route changes.  This will
              continue until routing receives a route query call with
              the Notify_Flag set False.

         o    Route Change Notification

              If requested by a route query with the Notify_flag True,
              the routing daemon may provide an asynchronous callback to
              RSVP that a specified route has changed.

                 Ucast_Route_Change( ) ->   DestAddress, OutInterface

                 Mcast_Route_Change( )

                             -> SrcAddress, DestAddress, 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 for the same source and
              destination addresses on different interfaces.  It is also
              necessary in some cases to avoid routing loops.

         o    Discover Interface List

              RSVP must be able to learn what real and virtual
              interfaces are active, with their IP addresses.

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, which are defined by SESSION and SENDER_TEMPLATE objects,
        respectively.  PSB contents include a PHOP object and possibly
        SENDER_TSPEC, POLICY_DATA, and/or ADSPEC objects from PATH
        messages.

   o    RSB -- Reservation State Block

        Each RSB holds reservation state for a particular 4-tuple:
        (session, next hop, style, filterspec), which are defined in
        SESSION, NHOP, STYLE, and FILTER_SPEC objects, respectively.
        RSB contents also include a FLOWSPEC object and may include a
        POLICY_DATA object.  We assume that RSB contents include the
        outgoing interface OI that is implied by NHOP.

   MESSAGE ARRIVES

   Verify version number, checksum, and length fields of common header,
   and discard message if any mismatch is found.

   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, starting the
        Path_Refresh_Needed and Resv_Refresh_Needed flags off.

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

        2.   Call the appropriate Route_Query routine, using DestAddress
             from SESSION and (for multicast routing) SrcAddress from
             SENDER_TEMPLATE.  This provides a routing bit mask
             ROUTE_MASK and (for a multicast destination) an
             EXPECTED_INTERFACE.

        3.   If the message arrived on an interface different from
             EXPECTED_INTERFACE, drop it and return.

        4.   Search for a path state block (PSB) whose (SESSION,
             SENDER_TEMPLATE) pair matches the corresponding objects in
             the message.

             If there is a match considering wildcards in the
             SENDER_TEMPLATE objects, but the two SENDER_TEMPLATEs
             differ, build and send a "Ambiguous Path" PERR message,
             drop the PATH message, and return.

        5.   If there is no matching PSB for the (SESSION,
             SENDER_TEMPLATE) pair then:

             o    Create a new PSB.

             o    Set a cleanup timer for the PSB.  If this is the first
                  PSB for the session, set a refresh timer for the
                  session.

             o    Copy the SESSION, TIME_VALUES, and PHOP objects into
                  the PSB.  Copy into the PSB any of the following
                  objects that are present: POLICY_DATA, SENDER_TSPEC,
                  and ADSPEC.

             o    Store ROUTE_MASK and EXPECTED_INTERFACE in the PSB.

             o    Turn on the Path_Refresh_Needed flag.

        6.   Otherwise (there is a matching PSB):

             o    Restart cleanup timer.

             o    If the SENDER_TSPEC and/or ADSPEC values differ
                  between the message and the PSB, copy the new values
                  into the PSB and turn on the Path_Refresh_Needed flag.
                  Note that if SEND_TSPEC has changed, reservations
                  matching S may also change; this may be deferred until
                  a RESV refresh arrives.

             o    If the new ROUTE_MASK differs from that stored in the
                  PSB, turn on the Path_Refresh_Needed flag, and store
                  the new ROUTE_MASK into the PSB.

             o    If the new EXPECTED_INTERFACE differs from that stored
                  in the PSB, turn on the Resv_Refres_Needed flag and
                  store the new EXPECTED_INTERFACE value into the PSB.

        7.   Save the IP TTL with which the message arrived in the PSB .

        8.   If the Refresh_Needed flag is now set, execute the PATH
             REFRESH event sequence (below); however, send no PATH
             refresh messages out the interface through which the PATH
             message arrived.

        9.   If the Resv_Needed flag is now set, execute the RESV
             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
             for a PATH message (see PATH REFRESH).

        o    Each sender descriptor in the PTEAR message contains a
             SENDER_TEMPLATE object defining 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
                  reservation state that is associated with sender S and
                  no other sender.

             3.   Delete the PSB.

        o    Drop the PTEAR message and return.

   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,
                               Error_code, Error_value, 0,
                               1, SENDER_TEMPLATE, NULL, NULL, NULL)

             Any POLICY_DATA, SENDER_TSPEC, or ADSPEC object in the
             message is ignored.

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

   RESV MESSAGE ARRIVES

        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 the 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 "Conflicting Style", drop the RESV
             message, and return.

        o    Check the POLICY_DATA object.

             Verify the POLICY_DATA field (if any) to check permission
             to create a reservation.  If it is unacceptable, build and
             send an "Administrative rejection" RERR message, drop the
             RESV message, and return.

        o    Make reservations

             Process the STYLE object and the flow descriptor list.

             For FF style, execute the following steps for each b flow
             descriptor, i.e., for each (FLOWSPEC, FILTER_SPEC) pair.
             For SE style, execute the following steps for each
             FILTER_SPEC in the list, using the given FLOWSPEC.  For WF
             style, execute the following once, using an internal
             placeholder "WILD_FILTER" for FILTERSPEC if it is omitted.

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

             2.   Start or restart the cleanout timer on the RSB.  Start
                  a refresh timer for this session if none was started.

             3.   If the RSB existed and contains state matching this
                  flow descriptor, continue with the next flow
                  descriptor.  Otherwise (the state is new or modified),
                  continue processing the current flow descriptor with
                  the following steps.

             4.   Scan the set of PSBs (senders) whose SENDER_TSPECs
                  match FILTER_SPEC.

                  -    If this set is empty, build and send an error
                       message specifying "No sender information", and
                       continue with the next flow descriptor.

                  -    If this set contains more than one PSB and if the
                       style has the explicit option (e.g., FF or SE),
                       build and send an error message specifying
                       "Ambiguous filter spec" and continue with the
                       next flow descriptor.

                  -    Set K_E_Police_flag on if any of these PSBs have
                       the E_Police flag on, otherwise set
                       K_E_Police_flag off.  Set K_M_Police_flag on if
                       the style has wildcard scope and there is more
                       than one PSB in the scope, otherwise, set
                       K_M_Police_flag off.

                  -    Compute K_Tspec as the sum of the SENDER_TSPEC
                       objects, if any, in this set of PSBs.

             5.   Compute the parameters for the effective reservation,
                  by considering all RSB's for the same (SESSION, OI,
                  FILTERSPEC) triple.

                  -    Compute the effective kernel flowspec,
                       K_Flowspec, as the maximum of the FLOWSPEC values
                       in these RSB's

                  -    Compute the effective kernel filter spec K_Filter
                       by merging the FILTER_SPEC objects in these
                       RSB's.

             6.   If this reservation has wildcard scope and this is not
                  the first flow descriptor in the message, one of the
                  filter specs must have changed; delete the old one and
                  install the new:

                         TC_DelFilter( old_Fhandle );

                         Fhandle = TC_AddFilter( Rhandle, SESSION, K_filter)

                  Then continue with the next flow descriptor.

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

                     Rhandle = TC_AddFlowspec( OI, K_flowspec, K_Tspec,
                                         K_E_Police_flag, K_M_Police_flag )

                  If this call fails, build and send a RERR message
                  specifying "Admission control failed", and continue
                  with the next flow descriptor.  Otherwise, record the
                  kernel handle Rhandle returned by the call in the
                  RSB(s).  Then call:

                     TC_AddFilter( Rhandle, SESSION, K_Filter)

                  to set the filter, and continue with the next flow
                  descriptor.

                  However, if there was a previous kernel reservation
                  with handle Rhandle, and the flowspec has changed,
                  call:

                     TC_ModFlowspec( Rhandle, K_Flowspec, K_Tspec,
                                       K_E_Police_flag, K_M_Police_flag )

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

                  If the flowspec is unchanged but the filter spec has
                  changed, install the new:

                     TC_DelFilter( old_Fhandle )
                        Fhandle = TC_AddFilter( Rhandle, SESSION, K_filter)

                  Then continue with the next flow descriptor.

        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.

   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 flow descriptor list 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_DelFlowspec( K_handle )

                  to delete the reservation.  Then build and forward a
                  new RTEAR 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)

                  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 Address 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-Used 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-Used,
                               FILTER_SPEC, FLOWSPEC, NULL)

             Here LUB-Used 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 outgoing interface OI, build a PATH message and send it to
   OI.  To build the message, consider each PSB whose ROUTE_MASK
   includes OI, and do the following:

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

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

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

   o    Compute the IP TTL for the PATH message as one less than the
        maximum of the TTL values from the senders included in the
        message.  However, if the result is zero, return without sending
        the PATH message.

   o    If the maximum size of the PATH message is reached, send the
        packet out interface OI 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 or RTEAR message.

   For each PHOP defined by the path state, scan the RSBs, merge the
   style, FLOWSPECs and FILTER_SPECs appropriately, build a new RESV
   message, and send it to PHOP.  Each message carries a NHOP object
   containing the local address of the interface through which it is
   sent.

   The details of building the RESV messages depend upon the
   shared/distinct option of the style.  For each PHOP, do the
   following:

   o    Distinct style

        Select each sender Si (PSB) for PHOP, and do the following:

        1.   Select all RSB's whose FILTER_SPECs match the
             SENDER_TEMPLATE object for Si and whose OI matches a bit in
             the ROUTE_MASK of the PSB for Si.

        2.   Compute the maximum over the FLOWSPEC objects of this set
             of RSB's, and merge their FILTER_SPEC, STYLE, and
             POLICY_DATA objects.

        3.   Append the (FLOWSPEC, FILTER_SPEC pair) to the RESV message
             being built for destination PHOP.  When the packet fills,
             or upon completion of all PSB's with the same PHOP, send
             it.

   o    Shared style

        1.   Select each sender Si (PSB) for PHOP, and select all RSB's
             that: (a) have an OI matching a bit in the ROUTE_MASK for
             Si, and (b) contain at least one FILTER_SPEC that matches
             the SENDER_TEMPLATE object for Si.

        2.   For all selected RSB's for all Si corresponding to a given
             PHOP:

             -    Compute the maximum over the FLOWSPEC objects of this
                  set of RSB's.

             -    Merge the metching FILTER_SPEC objects; this will in
                  general result in a list of non-overlapping
                  FILTER_SPECs, but where there are overlaps due to
                  wildcards, use the `wildest'.

             -    Merge the STYLE and POLICY_DATA objects.

             -    Place the resulting merged objects into a RESV message
                  and send it to PHOP.

        3.   If the scope is wildcard, a forwarded RESV must contain a
             SCOPE object.  The set of IP addresses in the SCOPE object
             sent to a given PHOP is formed as follows.

             -    Take the union of the senders listed in SCOPE objects
                  in all RSB's.

             -    Intersect that set with the set of sender hosts listed
                  in path state for PHOP.

             -    If the resulting set is empty, no RESV should be
                  forwarded to this PHOP.

APPENDIX A. Object 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.

   All unused fields should be sent as zero and ignored on receipt.

   A.1 SESSION Class

      SESSION Class = 1.

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

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

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

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

      DestAddress

           The IP unicast or multicast destination address of the
           session.

      Flags

           0x01 = E_Police flag

                The E_Police flag is used in PATH messages to determine
                the effective "edge" of the network, to control traffic
                policing.  If the sender host is not itself capable of
                traffic policing, it will set this bit on in PATH
                messages it sends.  The first node whose RSVP is capable
                of traffic policing will do so (if appropriate to the
                service) and turn the flag off.

                [It might make more sense to include this flag in ADSPEC
                object.]

      DestPort

           The UDP/TCP destination port for the session.  Zero may be
           used to indicate a `wildcard', i.e., any port.

           Other SESSION C-Types could be defined in the future to
           support other demultiplexing conventions in the transport-
           layer or application layer.

   A.2 RSVP_HOP Class

      RSVP_HOP class = 3.

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

           +-------------+-------------+-------------+-------------+
           |             IPv4 Next/Previous Hop Address            |
           +-------------+-------------+-------------+-------------+
           |                 Logical Interface Handle              |
           +-------------+-------------+-------------+-------------+

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

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +             IP6 Next/Previous Hop Address             +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |                 Logical Interface Handle              |
           +-------------+-------------+-------------+-------------+

      This object provides the IP address of the interface through which
      the last RSVP-knowledgeable hop forwarded this message.  The
      Logical Interface Handle is a 32-bit number which may be used to
      distinguish logical outgoing interfaces as described in Section
      4.2; it should be identically zero if there is no logical
      interface handle.

   A.3 INTEGRITY Class

      INTEGRITY class = 4.

      See draft-ietf-rsvp-md5-00.txt.

   A.4 TIME_VALUES Class

      TIME_VALUES class = 5.

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

           +-------------+-------------+-------------+-------------+
           |                    Refresh Period                     |
           +-------------+-------------+-------------+-------------+
           |                  Max Refresh Period                   |
           +-------------+-------------+-------------+-------------+

      Refresh Period

           The refresh timeout period R used to generate this message;
           in milliseconds.

      Max Refresh Period

           The largest R value that a node is allowed to apply to the
           downstream state for this session.  A node may refuse to
           accept this requirement, by ignoring the message containing
           this TIME_VALUES object and sending a "R too small" error
           message.

           If this value is zero, no limit is set.

   A.5 ERROR_SPEC Class

      ERROR_SPEC class = 6.

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

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

      o    IP6 ERROR_SPEC object: Class = 6, C-Type = 2

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

      Error Node Address

           The IP address of the node in which the error was detected.

      Flags

           0x01 = LUB-Used

                The use of this flag is described in section 4.1.5.

      Error Code

           A one-octet error description.

      Error Value

           A two-octet field containing additional information about the
                error.  Its contents depend upon the Error Type.

      The values for Error Code and Error Value are defined in Appendix
      B.

   A.6 SCOPE Class

      SCOPE class = 7.

      This object contains a list of IP addresses, used for routing
      messages with wildcard scope without loops.  The addresses must be
      listed in ascending numerical order.

      o    IPv4 SCOPE List object: Class = 7, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |                IP4 Src Address (4 bytes)              |
           +-------------+-------------+-------------+-------------+
           //                                                      //
           +-------------+-------------+-------------+-------------+
           |                IP4 Src Address (4 bytes)              |
           +-------------+-------------+-------------+-------------+

      o    IP6  SCOPE list object: Class = 7, C-Type = 2

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +                IP6 Src Address (16 bytes)             +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           //                                                      //
           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +                IP6 Src Address (16 bytes)             +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
   A.7 STYLE Class

      STYLE class = 8.

      o    STYLE object: Class = 8, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |   Style ID  |              Option Vector              |
           +-------------+-------------+-------------+-------------+

      Style ID

           An integer identifying the style, as follows:

           0 = No ID assigned; use option vector.

           1 = WF

           2 = FF

           3 = SE

      Option Vector

           A set of bit fields giving values for the reservation
           options.  If new options are added in the futre,
           corresponding fields in the option vector will be assigned
           from the least-significant end.  If a node does not recognize
           a style ID, it may interpret as much of the option vector as
           it can, ignoring new fields that may have been defined.

           The option vector bits are assigned (from the left) as
           follows:

           19 bits: Reserved

           2 bits: Sharing control

                00b: Reserved

                01b: Distinct reservations

                10b: Shared reservations

                11b: Reserved
           3 bits: Scope control

                000b: Reserved

                001b: Wildcard scope

                010b: Explicit scope

                011b - 111b: Reserved

      The low order bits of the option vector are determined by the
      style id, as follows:

              WF 10001b
              FF 01010b
              SE 10010b
   A.8 FLOWSPEC Class

      FLOWSPEC class = 9.

      The following C-Types for service types are defined.  The
      corresponding object contents are specified in service template
      documents created by the int-serv working group.

      o    Class = 9, C-Type = 1:  Controlled-Delay Quality of Service

      o    Class = 9, C-Type = 2:  Predictive Quality of Service

      o    Class = 9, C-Type = 3:  Guaranteed Quality of Service

      There is also a container C-Type, used to enclose a set of
      FLOWSPEC objects that could not be merged at a downstream node
      because they include unrecognized C-Types.

      o    Class = 9, C-Type = 254:  Controlled-Delay Quality of Service

           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 FLOWSPEC object  1                  //
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 FLOWSPEC object  2                  //
           |                                                       |
           +-------------+-------------+-------------+-------------+
           //                                                     //
           //                                                     //
           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 FLOWSPEC object  k                  //
           |                                                       |
           +-------------+-------------+-------------+-------------+
   A.9 FILTER_SPEC Class

      FILTER_SPEC class = 10.

      o    IPv4 FILTER_SPEC object: Class = 10, C-Type = 1

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

      o    IP6 FILTER_SPEC object: Class = 10, C-Type = 2

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

      o    IP6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +               IP6 SrcAddress (16 bytes)               +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |   ///////   |         Flow Label (24 bits)            |
           +-------------+-------------+-------------+-------------+

      SrcAddress

           The IP source address for a sender host, or zero to indicate
           a `wildcard'.

      Protocol Id

           The IP protocol Identifier, or zero to indicate a `wildcard'.

      SrcPort

           The UDP/TCP source port for a sender, or zero to indicate a
           `wildcard' (i.e., any port).

      Flow Label

           A 24-bit Flow Label, defined in IP6.  This value may be used
           by the packet classifier to efficiently identify the packets
           belonging to a particular (sender->destination) data flow.

   A.10 SENDER_TEMPLATE Class

      SENDER_TEMPLATE class = 11.

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

           Definition same as IPv4/UDP FILTER_SPEC object.

      o    IP6/UDP SENDER_TEMPLATE object: Class = 11, C-Type = 2

           Definition same as IP6/UDP FILTER_SPEC object.

   A.11 SENDER_TSPEC Class

      SENDER_TSPEC class = 12.

      The only current form of Tspec is a token bucket.

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

            +-----------+-----------+-----------+-----------+
            |        b: Token Bucket Depth (bits)           |
            +-----------+-----------+-----------+-----------+
            |        r: Average data rate (bits/sec)        |
            +-----------+-----------+-----------+-----------+
   A.12 ADSPEC Class

      ADSPEC class = 13.

      [TBD]
   A.13 POLICY_DATA Class

      POLICY_DATA class = 14.

      o    Type 1 POLICY_DATA object: Class = 14, C-Type = 1

           [TBD]

      o    Unmerged POLICY_DATA object: Class = 14, C-Type = 254

           This object is a container for a list of POLICY_DATA objects
           (none of which may have C-Type = 254).  The contained objects
           have not yet been merged.

           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 POLICY_DATA object  1              //
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 POLICY_DATA object  2              //
           |                                                       |
           +-------------+-------------+-------------+-------------+
           //                                                     //
           //                                                     //
           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 POLICY_DATA object  k              //
           |                                                       |
           +-------------+-------------+-------------+-------------+
   A.14 TAG class

      TAG class = 20.

      o    TAG object: Class = 20, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |                       Tag Value                       |
           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                   Tagged Sublist                    //
           |                                                       |
           +-------------+-------------+-------------+-------------+

           Tag Value

                The value of the tag being attached to the objects in
                the Tagged Sublist.  The tag value is unique for each
                session and next/previous hop.

           Tagged Sublist

                A list of objects with the same class-num (but not
                necessarily the same C-Type).

APPENDIX B. Error Codes and Values

   The following Error Codes are defined.

   o    Error Code = 01: Admission failure

        Reservation rejected by admission control.

        For this Error Code, the 16 bits of the Error Value field are:

        suur cccc cccc cccc

        where the bits are:

        s = 0: RSVP should reject the message without updating local
             state.

        s = 1: RSVP may use message to update local state and propagate
             it.

        uu = 00: Low order 12 bits contain a globally-defined sub-code
             (values listed below).

        uu = 10: Low order 12 bits contain a sub-code that is specific
             to local organization.  RSVP is not expected to be able to
             interpret this except as a numeric value.

        uu = 11: Low order 12 bits contain a sub-code that is specific
             to the service.  RSVP is not expected to be able to
             interpret this except as a numeric value.  Since the
             traffic control mechanism might substitute a different
             service, this encoding may include some representation of
             the service in use.

        r: Reserved bit, should be zero.

        cccc cccc cccc: 12 bit code.

        The following globally-defined sub-codes may appear in the low-
        order 12 bits when uu = 00:

        -    Sub-code = 1: Delay bound cannot be met

        -    Sub-code = 2: Requested bandwidth unavailable

        -    Sub-code = 11: Service conflict

        -    Sub-code = 12: Service unsupported

             Traffic control can provide neither the requested service
             nor an acceptable substitute.

        -    Sub-code = 13: Bad Flowspec or Tspec value

             Unreasonable request.  High order 4 bits should be 000r, so
             that RSVP will reject the message.

        -    Sub-code = 14: Rmax value too small.

             Rmax would result in excessive refresh overhead.

   o    Error Code = 02: Administrative rejection

        Reservation has been rejected for administrative reasons.

        For this Error Code, the high order 4 bits of the Error Value
        field are assigned as for Code = 01 (above).  For this case, the
        following global sub-codes may be used:

        -    Sub-code = 1: Required credential(s) not presented.

        -    Sub-code = 2: Request too large

             Reservation request exceeds allowed value for this user
             class.

        -    Sub-code = 3: Insufficient quota or balance.

        -    Sub-code = 4: Administrative preemption

   o    IP6 SESSION_GROUP Object: Class    Error Code = 2, C-Type 03: No path information for this Resv

        RSVP should reject the message.

   o    Error Code = 129:

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +               IP6 Reference DestAddress               +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |      Session-Group ID     |    Count    |     Rank    |
           +-------------+-------------+-------------+-------------+
   6.3 RSVP_HOP Class 04: No sender information for this Resv

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

   o    Error Code = 05: Ambiguous path

        Sender specification is ambiguous with existing path state.
        RSVP should reject the message.

   o    Error Code = 06: Ambiguous filter spec

        Filter spec matches more than one sender, in style that requires
        a unique match.  RSVP should reject the message.

   o    Error Code = 07: Conflicting or unknown style

        Reservation style conflicts with style(s) of existing
        reservation state, or it is unknown.  If the high-order bit of
        Error Value is zero, RSVP should reject the message.

   o    Error Code = 11: Missing required object

        RSVP was unable to find or construct required object data from
        message.  Error Value will be Class-Num that is missing.  RSVP
        should reject the message.

   o    Error Code = 12: Unknown object class

        Error Value will contain 16-bit value composed of (Class-Num,
        C-Type) of unknown object.  This error should be sent only if
        RSVP is going to reject the message.

   o    IPv4 RSVP_HOP object: Class    Error Code = 3, 13: Unknown object C-Type

        Error Value will contain 16-bit value composed of (Class-Num,
        C-Type) of object.  This error should be sent only if RSVP is
        going to should reject the message.

   o    Error Code = 1

           +-------------+-------------+-------------+-------------+
           |             IPv4 Next/Previous Hop Address            |
           +-------------+-------------+-------------+-------------+ 14: Object error

        A non-specific error indicating bad format or contents of an
        object.  The Error Value will contain 16-bits value (Class-Num,
        C-Type) from header of bad object.  RSVP should reject the
        message.

   o    IP6 RSVP_HOP object: Class    Error Code = 3, C-Type 21: Traffic Control error

        Some system error was detected and reported by the traffic
        control modules.  The Error Value will contain a system-specific
        value giving more information about the error.

   o    Error Code = 129

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       + 22: RSVP System error
        The Error Value field will provide implementation- dependent
        information on the error.

APPENDIX C. UDP Encapsulation

   As described earlier, RSVP control messages are intended to be
   carried directly within IP datagrams as "raw packets".  Implementing
   RSVP in a node will require an intercept in the packet forwarding
   path for protocol 46, and the necessary kernel change is incorporated
   in the recent releases of IP multicasting

   There are particular circumstances where it may be desirable to
   encapsulate RSVP messages in UDP packets, as a short-term measure.

   1.   UDP encapsulation can be used between hosts and the last- (or
        first-) hop router(s).  This may ease installing RSVP on some
        host systems, by avoiding a kernel change for the RSVP
        intercept.

   2.   UDP encapsulation may be useful for legal penetration of
        firewalls.

   3.   UDP encapsulation might be used on each interface of an
        intermediate RSVP router whose kernel supported multicast but
        which did not have the RSVP intercept.

   In the following discussion, we concentrate on (1) and (2).

   Figure 13 shows a typical situation for a host running RSVP.  Here
   two RSVP-capable hosts Hu and Hr within a corporation are connected
   to the Internet through some arbitrarily complex set of networks and
   routers that is labelled the "Corporate cloud".  The border router R
   is assumed to be RSVP-capable, but the corporate cloud is not.

                     _ _ _ _
     ______        (         )      RSVP-capable
    |      |
           +             IP6 Next/Previous Hop Address             +      (           )       router
    |  Hu  |-----(  Corporate  )      ______
    |______|      (           )     a|      |b
                 (    cloud    )-----|  R   |---->Internet
     ______       (           )      |______|
    |
           +                                                       +      |     (             )
    |
           +-------------+-------------+-------------+-------------+  Hr  |------(           )
    |______|       (_ _ _ _ _)

                       Figure 13: End Host Situation

   We assume that Hu is a "UDP-only" host that requires UDP
   encapsulation, while Hr is a "raw-capable" host that can use raw RSVP
   packets.  The UDP encapsulation scheme should allow RSVP
   interoperation among an arbitrary topology of Hr hosts and Hu hosts
   as well as routers R.

   RESV messages are always sent unicast; once path state has been
   established, the unicast destination address of each RESV message is
   known.  If the path state also indicates whether the next host node
   needs UDP encapsulation, a RESV message can simply be sent to the
   next-hop node, either in raw mode or with UDP encapsuation.

   UDP encapsulation of PATH messages poses a more difficult problem.
   To solve it, we define two new well-known multicast addresses G1 and
   G2, and a well-known UDP port Pu.  Then the table in Figure 14 shows
   the rules.  Under the `Send' column, the notation is <mode>(destaddr,
   destport, TTL), where TTL is the IP-layer hop count.  The `Receive'
   column shows the group that is joined and, where relevant, the UDP
   Listen port.  T1 and T2 are configured IP TTL values used for
   encapsulation, while Tr is the local TTL value of the specific PATH
   message.  Finally, D is the DestAddress for the particular session.

   Node  Node Type          Send               Receive
   ___   __________     _______________     _______________
   Hu   UDP-only host    UDP(G1,Pu,T1)        UDP(G1,Pu)
                                             and UDP(G2,Pu)

   Hr   Raw-mode host    UDP(G1,Pu,T1)        UDP(G1,Pu)
                        and Raw(D,,Tr)       and Raw()

   R    Router
         Interface a:    UDP(G2,Pu,T2)        UDP(G1,Pu)
                        and Raw(D,,Tr)       and Raw()

         Interface b:    Raw(D,,Tr)           Raw()

           Figure 14: UDP Encapsulation Rules for Path Messages

   Note that R and Hr must send their PATH messages twice, once with UDP
   encapsulation and once in raw mode.  In two cases (Hr -> R and Hr ->
   Hr), each PATH message will be delivered twice.  The router may take
   steps to ignore the duplicates, but this redundancy actually has no
   ill effect other than overhead for processing the extra messages.

   A router must keep track of which of its interfaces are using UDP
   encapsulation and which are not.  A node can always listen for
   UDP(G1,Pu) on each interface, and if it receives a UDP-encapsulated
   PATH message, mark the corresponding path state as UDP-needed.  Then
   matching RESV messages will be correctly encapsulated.

   Two provisions are necessary for this automatic determination of
   encapsulation to work.

   C1   A router must use different groups G1 and G2 for sending and
        receiving, as already shown.

   C2   The TTL value T1 used by a host must be exactly enough to reach
        the router R.

   If T1 is too small to pass through the corporate cloud, of course
   PATH messages will not be forwarded.  If T1 is too large, multicast
   routing in R will forward the UDP packet into the Internet until its
   hop count expires.  This object provides will turn on UDP encapsulation between
   routers within the Internet, causing bogus UDP traffic.  (Note that
   UDP packets addressed to G2 by a router will not be received by a
   neighboring router).

   However, there are possible situations where it will be impossible to
   find a value of T1 that meets condition C2.  Within the corporate
   cloud there might be a multicast tunnel with an outgoing threshold
   larger than the hop count through the cloud.  Another possibility is
   that there might be more than one border router R, with different
   TTL's.  There are several possible ways that C2 might be satisfied in
   such cases.

   1.   It might be possible to configure the hosts' RSVP daemons with
        the IP address for R; the daemons could then "unicast" PATH
        messages to this address.  This solution will be feasible as
        long as the number of Hr and Hu hosts is small.

   2.   A particular host on the interface through which LAN including Hu could be designated as
        an "RSVP relay host".  This system would listen on (G1,Pu) and
        be configured with the last RSVP-knowledgeable hop forwarded this message.

   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 IP address of elements in R.  It could then forward
        any (PATH) messages it received directly to R, and T1 could be
        set only large enough to reach local hosts and the variable-length object list relay.

   Finally, manual configuration of T1 could be replaced by an expanding
   ring search conducted by host RSVP daemons.  This possibility is for
   future study.

APPENDIX D. Experimental and Open Issues
   D.1 RSVP MTU

      The spec says that follows.  See the RESV message format definition
                earlier.

   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 MTU for RSVP messages, which are sent hop
      by hop, is determined by the MTU at each interface.  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 being requested. 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.  The values currently defined best approach seems to be to
      rely on IP fragmentation and reassembly for this code are:

                1 = Guaranteed Service

                     The Tspec case.

   D.2 Reservation Compatability

      How strong is (b, r), while the Rspec is (r).  (d) requirement for compatability of reservations in
      different directions?  For example, see Figure 11; should it be
      possible to have incompatible reservation styles on the two
      interfaces?  If R1 requests a WF reservation and R2 requests a FF
      reservation, it is ignored.

                2 = Bounded-Delay Predictive Service logically possible to make the corresponding
      reservations on the two different interfaces.  The Tspec is (b, r), while current
      implementation does NOT allow this; instead, it prevents mixing of
      incompatible styles in the Rspec is (d).

   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 same session on a node, even if they
      are on different interfaces.

   D.3 Session Groups (Experimental)

      Section 1.2 explained that a host, distinct destination address, and SrcPort is
      therefore a UDP/TCP
      source port, defining distinct session, will be used for each of the
      subflows in a sender.

   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 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 as IP6/UDP FILTER_SPEC object.

   6.8 SENDER_TSPEC Class

      The most common form time (since it would be nonsense to admit high
      frequency components but reject the baseband component of Tspec 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 token bucket.

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

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

      [TBD]

   6.10 TIME_VALUES Class

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

           +-------------+-------------+-------------+-------------+
           |                    Refresh Period                     |
           +-------------+-------------+-------------+-------------+
           |                    State TTL Time                     |
           +-------------+-------------+-------------+-------------+
   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        |
           +-------------+-------------+-------------+-------------+ 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    IP6 ERROR_SPEC object: Class = 11, C-Type = 129

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

      Errnor Node    The IP reference address

      Error Code

           A one-octet error description.

                01 = Insufficient memory

                02 = Count Wrong

                     The FD Count field does not match length is an agreed-upon choice from among the
           DestAddress values of
                     message.

                03 = No path information for this Resv

                04 = No Sender information the sessions in the group, for this Resv
                     There example
           the smallest numerically.

      o    The session group ID is path information, but it does not include used to distinguish different groups
           with the sender specified same reference address.

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

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

      The SESSION_GROUP objects for all sessions 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 group will
      contain the same values of values.

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

                09 = Resources unavailable [Sub-reasons?  Depend upon
                     traffic control the reference address, the session
      group ID, and admission control algorithms?]

                10 = Illegal style

      Error Value

           Specific cause 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 error described by refresh
      cycle) and then pass the Error Code.

   6.12 CREDENTIAL Class

      [TBD]

   6.13 INTEGRITY Class

      [TBD]

7. UDP Encapsulation

   As described earlier, RSVP control messages are intended RESV requests to be
   carried Admission Control as "raw packets", directly within IP datagrams.  Implementing
   RSVP in a node will typically require an intercept
      group.  It is normally expected that all sessions in the packet
   forwarding path for protocol 46, which means a kernel change. group
      will be routed through the same nodes.  However, for ease if not, only a
      subset of installing RSVP on host systems in the short
   term, it session group reservations may be desirable to avoid host kernel changes by supporting
   UDP encapsulation of RSVP messages.  This encapsulation would be used
   between hosts and appear at a given
      node; in this case, the last- (or first-) hop router(s).  This scheme
   will also support RSVP should wait until the case end of an intermediate RSVP router whose
   kernel supports multicast but does not have the RSVP intercept, by
   allowing UDP encapsulation
      refresh cycle and then perform Admission Control on each interface. the subset of
      the session group that it has received.  The UDP encapsulation approach must support a domain rank values will
      identify which are missing.

      Note that contains a
   mix routing different sessions 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 session group
      differently will also receive some local RSVP packets generally result in both formats.  We
   assume that delays in establishing or
      rejecting the only negative impact of this duplication will desired QoS.  A "bundling" facility could be
   (negligible) additional packet processing overhead added
      to multicast routing, to force all sessions in a session group to
      be routed along the raw-capable
   hosts and first-hop routers.

   [REST TBD]

8. same path.

      D.3.1 Resv Messages

         Add:

          [ <SESSION_GROUP> ]

         after the SESSION object.

      D.3.2 SESSION_GROUP Class

         SESSION_GROUP class = 2.

         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 = 2:

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

         The variables are defined in above.

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

      D.4.1 Reservation Styles

         A Dynamic-Filter (DF) style reservation makes "distinct"
         reservations with "wildcard" scope, but it decouples
         reservations from filters.

         o    Each DF reservation request specifies a number D of
              distinct reservations to be made using the same specified flowspec, and
      these flowspec.
              These reservations have a are distributed with wildcard reservation  scope, so they go
      everywhere.
              i.e., to all senders.

              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.

         o    In addition to D and the flowspec, a DF style reservation
              may also specify a list of K filterspecs, for some K in
              the range: 0 <= K <= D'.  These filterspecs define
              particular senders to use the D' reservations, 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 or
         SE style.

   8.2

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

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

                           |
            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: 15: 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).
         15).  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, RSVP should call TC_AddFlowspec C times.

   8.3

      D.4.3 Resv Messages

         Add the following sequence:

          <style-specific-tail> ::=

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

          <filter spec

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

                         <FLOWSPEC> <filter spec list> <FILTER_SPEC>

   8.4

      D.4.4 STYLE Class

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

              +-------------+-------------+-------------+-------------+
              |   Style=3 Style ID=4  |   Attribute Vector  0...0101001b        |
              +-------------+-------------+-------------+-------------+
              |   ////////    //////       ///////   | Dyn    Dynamic Resv Cnt|  FD Count     |
           +-------------+-------------+-------------+-------------+
              +-------------+-------------+---------------------------+

              Style

                3 ID

                   4 = Dynamic-Filter

           Dyn (DF)

              Attribute Vector

                   18 bits: Reserved

                   1 bit: Decoupled if 1.

                   2 bits: Sharing control (as before)

                   3 bits: Scope control (as before)

              Dynamic 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 the number of FILTER_SPEC objects in
                   filter spec list.

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.

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

[ServTempl95a]  Shenker, S., "Network Element Service Specification
    Template", Internet Draft draft-ietf-intserv-svc-template-00.txt,
    Integrated Services Working Group, 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

   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