Internet Draft                                            R. Braden, Ed.
Expiration: January May 1996                                                 ISI
File: draft-ietf-rsvp-spec-07.txt draft-ietf-rsvp-spec-08.txt                               L. Zhang
                                                                    PARC
                                                               D. Estrin
                                                               S. Berson
                                                                     ISI
                                                               S. Herzog
                                                                     ISI
                                                                S. Jamin
                                                                     USC
                                                           J. Wroclaswki
                                                                     MIT

                Resource ReSerVation Protocol (RSVP) --

                   Version 1 Functional Specification

                              July 7,

                           November 22, 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.

Table of Contents

1. Introduction ........................................................5
   1.1 Data Flows ......................................................8
   1.2 Reservation Model ...............................................9
   1.3 Reservation Styles ..............................................11
   1.4 Examples of Styles ..............................................14
2. RSVP Protocol Mechanisms ............................................18
   2.1 RSVP Messages ...................................................18
   2.2 Port Usage ......................................................20
   2.3 Merging Flowspecs ...............................................21
   2.4 Soft State ......................................................22
   2.5 Teardown ........................................................24
   2.6 Errors and Acknowledgments ......................................25
   2.7 Policy and Security .............................................27
   2.8 Automatic RSVP Tunneling ........................................28
   2.9 Host Model ......................................................28
3. RSVP Functional Specification .......................................30
   3.1 RSVP Message Formats ............................................30
   3.2 Sending RSVP Messages ...........................................42
   3.3 Avoiding RSVP Message Loops .....................................44
   3.4 Local Repair ....................................................48
   3.5 Time Parameters .................................................48
   3.6 Traffic Policing and TTL ........................................50
   3.7 Multihomed Hosts ................................................51
   3.8 Future Compatibility ............................................52
   3.9 RSVP Interfaces .................................................55
4. Message Processing Rules ............................................65
APPENDIX A. Object Definitions .........................................82
APPENDIX B. Error Codes and Values .....................................97
APPENDIX C. UDP Encapsulation ..........................................101
APPENDIX D. Experimental and Open Issues ...............................103
   What's Changed Since Danvers IETF

   The most important changes in this document from the rsvp-spec-05 rsvp-spec-07 draft
   are:

      o    Added fields to common header for linear fragmentation,    The role and
        moved all references to semantic fragmentation to Appendix D.

   o    Added SE (Shared Explicit) style to all parts interpretation of the document.

   o    Further clarified reservation options IP Protocol Id is changed.
           The Protocol Id is now a required part of the session
           definition, and added table in Figure
        3.  Defined option vector in STYLE object.

   o    Renamed CREDENTIAL object class to POLICY_DATA object class, filter specs and
        rewrote section 2.5 to more fully express its intended usage.

   o    Clarified sender templates now assume
           the relationship between Protocol Id from the wildcard scope session rather than stating it
           explicitly.

      o    A "soft" reservation option and wildcards in individual FILTER_SPEC
        objects: wildcard confirmation message is as wildcard does. added.

      o    Added SCOPE object definition    The text states explicitly that an erroneous reservation
           message is not forwarded.  A mechanism to allow a receiver
           more flexible control over forwarding of its messages after
           an admission control failure has not been designed and defined is
           therefore not included in this version of the rules protocol.

      o    A terminology confusion is eliminated.  The term "scope" was
           used both for its use
        to prevent looping a set of wildcard-scope messages.

   o    Added some mechanisms for handling backwards compatibility senders and for
        future protocol extensions: (1) High bit a set of object class number;
        (2) unmerged FLOWSPEC C-Type; (3) unmerged POLICY_DATA C-Type.

   o    Rewrote Section 4.3 on preventing looping.  Included rules for
        SCOPE object.

   o    Specified rules for local repair upon route change notification
        (Section 4.4).

   o    Specified sender hosts.
           A new term "sender selection" is introduced for each error type whether or not the state
        information in first,
           leaving "scope" for the erroneous packet is to be stored and
        forwarded. second.

      o    Deleted the discussion of retransmitting    The FILTER_SPEC object is dropped from a Teardown message Q
        times; assume Q=1 wildcard sender
           selection (WF) style reservation, which now selects "all
           senders" without qualification.

      o    The StyleID byte is sufficient. dropped from a STYLE object, as
           redundant.

      o    Moved Session Groups    An SE style flow descriptor is simplified to Appendix D, "Experimental and Open
        Issues".  Session Groups should be revisited as part of a larger
        context of cross-session reservations. single
           flowspec.

      o    Changed common header format, removing Object Count (which was
        redundant) and rearranging the remaining fields.  Moved the two
        common header flags into objects: Entry-Police into SESSION
        object    The IP Router Alert option is now required in PATH, PTEAR,
           and LUB-used into ERROR_SPEC object. RACK messages.

      o    Revised the rules for state timeout (Section 4.5) and redefined
        the    The TIME_VALUES object format.

   o    Changed the error message format: (1) removed is now required RSVP_HOP
        object from PERR in RESV and RERR PATH
           messages; (2) specified more carefully
        what may appear in flow descriptor list of RERR messages. there is no default.

      o    Revised the definitions of error codes and error values, and
        moved them into    Policing at branch points is now defined in a separate Appendix B. new section on
           policing (3.6).

      o    No longer require CREDENTIAL (i.e., POLICY_DATA) match for
        teardown.    A 2-second delay is inserted into local repair.

      o    Revised routing    Merging of RERR messages to use SCOPE SE with WF objects to avoid
        wildcard-induced looping. is no longer allowed.

      o    Added LIH (logical interface handle) to RSVP_HOP object,    The Rmax end-to-end bound on the refresh rate R is removed,
           since its utility was unclear.

      o    A rule for IP
        multicast tunnels. randomizing refresh timeouts is included.

      o    Specified    The suggestion that addresses should TCP could be sorted in SCOPE object. used for carrying RSVP state
           through a congested non-RSVP cloud is removed.

      o    Added two new upcall event types    SENDER_TSPECS are now required in the API: reservation event
        and policy data event. PATH| messages.

      o    Generalized the generic traffic control calls slightly to allow
        multiple filter specs per flowspec, for SE style.  This
        introduced a    There are new set of handles, called FHandle.  Also added sections on multihomed hosts (3.7) and future
           compatibility (3.8).  The latter section makes clear that a
        preemption upcall.

   o    Added route change notification to the generic interface to
        routing.

   o    Updated the
           message processing rules (Section 5). containing an object with unknown C-Type should be
           rejected.  Any more forgiving treatment seems too complex.

      o    Rewrote    Appendix C on UDP encapsulation. encapsulation is completely changed.

      o    Removed specification of FLOWSPEC object format (but int-serv
        working group has since reneged on promise to specify it).    Some text was rearranged in Sections 1 and 2.

1. Introduction

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

   A

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

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

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

            HOST                             ROUTER

 _________________________    RSVP   ______________________  _____________________________
|                         |    .---------------.    .--------------.                  |
|  _______       ______   |   .   /    | ________  .   ______        |
| |       |     |      |  |  .  /     ||        |  . |      ||      |       | RSVP
| |Applic-|     | RSVP <----- <----/      ||Routing |   -> RSVP <------> <---------->
| |  App  <----->daemon|  |        ||Protocol|    |daemon||    |daemon|       |
| |       |     |      |  |        || daemon <---->      ||      |       |
| |_______|     |___.__|  |        ||_ ._____|    |__.___||
   |===|===============v=====|         |===v=============v====|    |__.__.|       |
|   |               |     |        | data     ..........   |             |   .  ............       |
|===|===============|=====|        |===|=============|====.======|
| data     .........|     |        |   |  ...........|     .____ |
|   |  ____v_   ____v____  ____V_   ____V____ |        |  _v__v_    _____v___  _V__V_    _____V___ | Adm.||
|   | |Class-| |         ||  data  | |Class-|  |         ||  data         ||Cntrl||
|   |=> ifier|=> Packet  =============>  ============> ifier|==> Packet  |======>  ||_____|| data
|     |______| |Scheduler||        | |______|  |Scheduler||  |Scheduler|===========>
|              |_________||        |           |_________||           |_________|       |
|_________________________|         |______________________|        |_____________________________|

                  Figure 1: RSVP in Hosts and Routers

   Each router that is capable of resource reservation passes incoming
   data packets to through a packet classifier and then queues them as
   necessary in a packet scheduler.  The packet classifier determines
   the route and the QoS class for each packet.  The  There is a scheduler allocates
   for each interface, to allocate resources for transmission on the
   particular link-layer medium used by each that interface.  If the link-layer 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 to obtain the QoS requested by RSVP.  There are many possible ways this might  This
   mapping to the link layer QoS may be
   accomplished, and accomplished in a number of
   possible ways; the details will be medium-dependent.  The
   scheduler itself allocates packet transmission capacity on  On a QoS-
   passive medium such as a leased line. line, the scheduler itself allocates
   packet transmission capacity.  The scheduler may also allocate other
   system resources such as CPU time or buffers.

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

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

   RSVP is designed to scale well for very large multicast groups.
   Since both the membership of a large group will be constantly changing, and the topology of large
   multicast trees are likely to change with time, the RSVP design
   assumes that router state for traffic control will be built and
   destroyed incrementally.  For this purpose, RSVP uses "soft state" in
   the routers, in addition routers.  That is, RSVP sends periodic refresh messages to receiver-initiation.
   maintain the state along the reserved path(s); in absence of
   refreshes, the state will automatically time out and be deleted.

   RSVP protocol mechanisms provide a general facility for creating and
   maintaining distributed reservation state across a mesh of multicast
   or unicast delivery paths.  RSVP transfers reservation parameters as
   opaque data (except for certain well-defined operations on the data),
   which it simply passes to traffic control for interpretation.
   Although the RSVP protocol mechanisms are largely independent of the
   encoding of these parameters, the encodings must be defined in the
   reservation model that is presented to an application (see application; see Appendix
   A). A
   for more details.

   In summary, RSVP has the following attributes:

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

   o    RSVP is simplex. simplex, i.e., it reserves for data flow in one
        direction only.

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

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

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

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

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

   The remainder of this section describes the RSVP reservation
   services.  Section 2 presents an overview of the RSVP protocol
   mechanisms, while
   mechanisms.  Section 3 gives examples of the services and
   mechanism.  Section 4 contains the functional specification of RSVP. RSVP,
   while Section 5 4 presents explicit message processing rules.  Appendix
   A defines the variable-length typed data objects used in the RSVP
   protocol.  Appendix B defines error codes and values.  Appendix C
   defines an extension for UDP encapsulation of RSVP messages.
   Finally, some experimental RSVP features are documented in Appendix D
   for future reference.

   1.1 Data Flows

      The set of

      RSVP defines a "session" as a data flows flow with the same unicast or multicast
      destination constitute a session. RSVP treats each session
      independently.  All data packets in particular
      destination and transport-layer protocol.  The destination for a
      particular session are
      directed to is generally defined by DestAddress, the same IP
      destination address DestAddress, of the data packets, and perhaps to by DstPort, a
      " generalized destination port", i.e., some further demultiplexing
      point defined in a higher
      layer (transport the transport or application).  We refer to application protocol layer.  RSVP treats
      each session independently, and this document often assumes the latter as a
      "generalized destination port".
      qualification "for the same session".

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

      Figure 2 illustrates the flow of data packets in a single RSVP
      session,
      session assuming multicast data distribution.  The arrows indicate
      data flowing from senders S1 and S2 to receivers R1, R2, and R3,
      and the cloud represents the distribution mesh created by
      the
      multicast routing protocol. routing.  Multicast distribution forwards a copy of each
      data packet from a sender Si to every receiver Rj; a unicast
      distribution session has a single receiver R.  Each sender Si and
      each receiver Rj may correspond to be running in 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
      Even if the destination address is unicast,

      For unicast transmission, there may will be multiple
      receivers, distinguished by the generalized port.  There a single destination host
      but there may also be multiple senders for a unicast destination, i.e., senders; RSVP can set up reservations
      for multipoint-to-point multipoint-to-single-point transmission.

   1.2 Reservation Model

      An elementary RSVP reservation request consists of a "flowspec"
      together with a "filter spec"; this pair is called a "flow
      descriptor".  The flowspec specifies a desired QoS.  The filter
      spec (together
      spec, together with the DestAddress and the generalized
      destination port defining the session) defines session definition, specifies the set of data
      packets -- the "flow" -- to receive the QoS defined by the
      flowspec.  The flowspec is used to set parameters to the node's
      packet scheduler (assuming that admission control succeeds), while
      the filter spec is used to set parameters in the packet
      classifier.  Data packets that are addressed to a particular
      session but do not match any of the filter specs for that session
      are handled as best-effort traffic.

      Note that the action to control the QoS occurs at the place where the
      data enters the medium, i.e., at the upstream end of the link,
      although the an RSVP reservation request originates from receiver(s)
      downstream.

      The flowspec in a reservation request will generally include a
      service type and two sets of numeric parameters: (1) an "Rspec" (R
      for `reserve'), which  In this document, we define the directional terms
      "upstream" vs.  "downstream", "previous hop" vs. "next hop", and
      "incoming interface" vs "outgoing interface" with respect to the
      direction of data flows.

      The flowspec in a reservation request will generally include a
      service class and two sets of numeric parameters: (1) an "Rspec"
      (R for `reserve') that defines the desired per-hop reservation, QoS, and (2) a "Tspec"
      (T for `traffic'), which defines the parameters `traffic') that
      may be used to police describes the data flow, i.e., to ensure it does not
      exceed its promised traffic level. flow.  The form formats and
      contents of 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 admission
      control and packet scheduling components of traffic control.  A
      service that requires traffic policing might for example apply it
      at the edge of the network and at data merge points; RSVP knows
      when these occur and must so indicate to the traffic control
      mechanism.  On the other hand, RSVP cannot interpret the service
      embodied in the flowspec and therefore does not know whether
      policing will actually be applied in a particular case.

      In the most general RSVP reservation model approach [RSVP93], filter specs may select
      arbitrary subsets of the packets in a given session.  Such subsets
      might be defined in terms of senders (i.e., sender IP address and
      generalized source port), in terms of a higher-level protocol, or
      generally in terms of any fields in any protocol headers in the
      packet.  For example, filter specs might be used to select
      different subflows in a hierarchically-encoded signal by selecting
      on fields in an application-layer header.  However, in the
      interest of simplicity (and to minimize layer violation), the
      present RSVP version uses a much more restricted form of filter
      spec: select only on
      spec, consisting of sender IP address, on address and optionally the UDP/TCP
      port number,
      and perhaps on IP protocol id. number SrcPort.

      RSVP can distinguish subflows of a hierarchically-encoded signal
      if they reservation request messages originate at receivers and are assigned distinct multicast destination addresses, or,
      for
      passed upstream towards the sender(s).  When a unicast destination, distinct destination ports.  Data
      packets that reservation request
      is received at a node, two general actions are addressed to taken.

      1.   Make a particular session but do not
      match any of reservation

           The flowspec and the filter specs for that session spec are expected to be
      sent as best-effort traffic, and under congested conditions, such
      packets are likely to experience long delays, and they may be
      dropped.  When a receiver does not wish to receive a particular
      (sub-)flow, it can economize on network resources by explicitly
      asking the network to drop unneeded the data packets; it does so
      by leaving the multicast group(s) to which these packets are
      addressed.  Thus, determining where packets get delivered should
      be a routing function; RSVP is concerned only with the QoS of
      those packets that are delivered by routing.

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

      1.   Daemon makes a reservation

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

      2.   Daemon forwards   Forward the reservation request upstream

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

      The reservation request that a node forwards upstream may differ
      from the request that it received, received from downstream, for two
      reasons.  First, it is possible (in theory) in theory for the traffic control
      mechanism to modify the flowspec hop-by-hop, although none of the
      currently no realtime defined services
      do this. does so.  Second, reservations for the
      same sender, or the same set of senders, from different downstream
      branches of the multicast distribution tree(s) must be are "merged" as reservations
      travel upstream.  Merging reservations is a necessary
      consequence of multicast distribution, which creates a single
      stream of data packets in upstream; that is, a particular router from any Si,
      regardless of node forwards upstream only the set of receivers downstream.  The
      reservation
      for Si on a particular outgoing link L should be request with the "maximum" of
      the individual flowspecs from the receivers Rj that are downstream
      via link L.  Merging is discussed further in Section 2.2.

      The basic RSVP reservation model is "one pass": flowspec.

      When a receiver sends originates a reservation request, it can also
      request upstream, and each a confirmation message to indicate that its request was
      (probably) installed in the network.  A successful reservation
      request propagates as far as the closest point(s) along the sink
      tree to the sender(s) where there is an existing reservation level
      equal or greater than that being requested.  At that point, the
      arriving request will be dropped in favor of the equal or larger
      reservation in place; the node may then send a reservation
      confirmation message back to the receiver.  Note that the receipt
      of a confirmation is only a high-probability indication, not a
      guarantee that the requested service is in place all the way to
      the sender(s), as explained in Section 2.6.

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

   1.3 Reservation Styles

      A reservation request includes a set of control options, which are
      collectively called the reservation "style".

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

      Another option controls the scope selection of the request: senders: an "explicit" sender specification,
      list of all selected senders, or a "wildcard" that implicitly
      selects a group of senders. all the senders to the session.  In an explicit-style explicit-selection
      reservation, the each filter spec must match exactly one sender, while the filter spec
      in a wildcard reservation must match at least one sender but may
      match any number. wildcard-selection no filter spec is needed.

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

                 Figure 3: Reservation Attributes and Styles

      The styles currently defined are as follows (see Figure 3):

      1.

      o    Wildcard-Filter (WF) Style

           The WF style implies the options: "shared" reservation and "
           wildcard" reservation scope. sender selection.  Thus, a WF-style reservation
           creates a single reservation into which flows from all
           upstream senders are mixed; this reservation may be thought
           of as a shared "pipe", whose "size" is the largest of the
           resource requests for that link from all receivers, independent of the
           number of senders using it.  A WF-style reservation has wildcard scope, i.e., the reservation is
           propagated upstream towards all sender hosts.  A WF-style
           reservation hosts, and
           automatically extends to new senders as they appear.

      2.   Fixed-Filter (FF) Style

           The FF style implies the options: "distinct" reservations and
           "explicit"

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

               WF( * {Q})

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

      o    Fixed-Filter (FF) Style

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

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

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

               FF( S{Q})

           where S is the selected sender and Q is the corresponding
           flowspec; the pair forms a
           given node.

      3. flow descriptor.  RSVP allows
           multiple elementary FF-style reservations to be requested at
           the same time, using a list of flow descriptors:

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

      o    Shared Explicit (SE) Style

           The SE style implies the options: "shared" reservation and "
           explicit" reservation scope. sender selection.  Thus, an SE-style reservation
           creates a single reservation into which flows from all
           upstream senders are mixed.  However, like a the FF reservation style, the
           SE style allows a receiver to explicitly specify the set of
           senders.

           Symbolically, we can represent an SE reservation request by:

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

           i.e., a flow descriptor composed of a flowspec Q and a list
           of senders (and therefore its scope (and therefore
           the scope) is specified explicitly by the receiver making the
           reservation. S1, S2, etc.

      Both 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  Packetized audio conferencing, where is an example of an application
      suitable for shared reservations; since a limited number of people
      talk at once; once, each receiver might issue a WF or SE reservation
      request for twice the bandwidth required for one audio channel sender (to allow
      some over-speaking).  On the other hand, the FF style, which
      creates independent reservations for the flows from different
      senders, is appropriate for video signals.

      It is not possible to merge

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

      Other reservation options and styles may be defined in the future
      (see Appendix D.4, for example).

2. RSVP Protocol Mechanisms

   2.1 RSVP Messages

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

      Each receiver host sends RSVP reservation request (RESV) messages
      towards

   1.4 Examples of Styles

      This section presents examples of each of the senders.  These reservation messages must follow in
      reverse the routes styles
      and show the effects of merging.

      Figure 4 shows schematically a router with two incoming interfaces
      through which data packets streams will use, all arrive, labeled (a) and (b), and
      two outgoing interfaces through which data will be forwarded,
      labeled (c) and (d).  This topology will be assumed in the way
      examples that follow.  There are three upstream
      to the senders; packets
      from sender hosts included S1 (S2 and S3) arrive through previous hop (a) ((b),
      respectively).  There are also three downstream receivers; packets
      bound for R1 (R2 and R3) are routed via outgoing interface (c)
      ((d), respectively).  We furthermore assume that R2 and R3 arrive
      via different next hops, e.g., via the two routers D and D' in
      Figure 9.  This illustrates the scope.  RESV messages must be
      delivered effect of a non-RSVP cloud or a
      broadcast LAN on interface (d).

      In addition to the sender hosts so that the hosts can set up
      appropriate traffic control parameters for connectivity shown in 4, we must also specify
      the multicast routes within this node.  Assume first hop.

      Also note that RSVP sends no positive acknowledgment messages to
      indicate success (although the delivery of a reservation request
      to a sender could be used data
      packets from each Si shown in Figure 4 is routed to trigger an acknowledgement at a
      higher level of protocol.)
            Sender                                       Receiver
                          _____________________
               Path --> both outgoing
      interfaces.  Under this assumption, Figures 5, 6, and 7 illustrate
      Wildcard-Filter, Fixed-Filter, and Shared-Explicit reservations,
      respectively.

                         ________________
                     (a)|                | (c)
      ( S1 )
             Si =======> ---------->|                |----------> (    Multicast R1 ) Path -->
               <-- Resv
                        |     Router     |
                     (b)|                | (d)
      ( S2,S3 ) =========> Rj ------->|                |----------> (    distribution R2, R3 ) <-- Resv
                         (_____________________)
                        |________________|

                        Figure 4: Router Configuration
      For simplicity, these examples show flowspecs as one-dimensional
      multiples of some base resource quantity B.  The "Receive" column
      shows the RSVP Messages

      Each sender transmits RSVP PATH messages forward along reservation requests received over outgoing
      interfaces (c) and (d), and the uni-
      /multicast routes provided by "Reserve" column shows the routing protocol(s); see Figure
      4.  These "Path" messages store path
      resulting reservation state in for each node.  Path
      state is used by RSVP to route interface.   The "Send"
      column shows the RESV messages hop-by-hop in reservation requests that are sent upstream to
      previous hops (a) and (b).  In the
      reverse direction.  (In "Reserve" column, each box
      represents one reserved "pipe" on the future, some routing protocols may
      supply reverse path forwarding information directly, replacing outgoing link, with the
      reverse-routing function of path state).

      PATH messages may also carry
      corresponding flow descriptor.

      Figure 5, showing the following information:

      o    Sender Template

           The Sender Template describes WF style, illustrates the format two possible
      merging situations. Each of data packets that the sender will originate.  This template is two next hops on interface (d)
      results in the form of a
           filter spec that could be separate RSVP reservation request, as shown.  These
      two requests are merged into the effective flowspec 3B, which is
      used to select this sender's
           packets from others in make the same session reservation on interface (d).  To forward the same link.

           Like
      reservation requests upstream, the reservations on the interfaces
      (c) and (d) are merged; as a filter spec, result, the Sender Template is less than fully
           general at present, specifying only sender IP address,
           UDP/TCP sender port, and protocol id.   The 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 traffic level that the sender will
           generate.  This Tspec can be used by RSVP to prevent over-
           reservation (and perhaps unnecessary Admission Control
           failure) on the non-shared links starting at the sender.

      o    Adspec

           The PATH message may carry a package of OPWA advertising
           information, known as an "Adspec".  An Adspec received in a
           PATH message is passed to the local traffic control routines,
           which return an updated Adspec; the updated version larger flowspec 4B 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 |   _____
       _____ upstream to each previous hop.

                             | Path-->|_____________________|  Path -->
               Send          |       Reserve              Receive
                             |
                             |       _______
         WF( *{4B} ) <- (a)  |  (c) | * {4B}|    (c) <- WF( *{4B} )
                             |                                          |--|  D'      |_______|
                             |
      -----------------------|----------------------------------------
                             |  B' |--|       _______
         WF( *{4B} ) <- (b)  |  |_____|
      |_____|  (d) | * {3B}|    (d) <- WF( *{3B} )
                             |      |_______|        <- WF( *{2B} )

              Figure 5: Router Using RSVP Wildcard-Filter (WF) Reservation Example

      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). 6 shows Fixed-Filter (FF) style reservations.  The same physical interface may act in both the
      incoming flow
      descriptors for senders S2 and outgoing roles (for different data flows but the same
      session).

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

      Although multiple next hops may send reservation requests through the same physical interface, three different flow
      descriptors for sender S1 are merged into the final effect should be to install
      a reservation on that interface, single request FF(
      S1{4B} ), which is defined by an effective
      flowspec.  This effective flowspec will be the "maximum" of the
      flowspecs requested by the different next hops.  In turn, a RESV
      message forwarded sent to a particular previous hop carries a flowspec
      that is the "maximum" over the effective reservations on the
      corresponding (a).  For each outgoing interfaces.  Both cases represent merging,
      which
      interface, there is discussed further below.

      There are a number of ways separate reservation for a syntactically valid each source that
      has been requested, but this reservation
      request to fail in a given node:

      1.   The effective flowspec, computed using the new request, may
           fail admission control.

      2.   Administrative policy or control may prevent the requested
           reservation.

      3.   There may be no matching path state (i.e., the scope may be
           empty), which would prevent is shared among all the reservation being propagated
           upstream.

      4.   A reservation style that requires a unique sender may have a
           filter spec
      receivers that matches more than one sender in the path
           state, due to the use of wildcards.

      5.   The requested style may be incompatible with the style(s) of
           existing reservations for the same session on made the same
           outgoing interface, so request.

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

              Figure 6: Fixed-Filter (FF) Reservation Example

      Figure 7 shows an effective flowspec cannot be
           computed.

      6.   The requested style may be incompatible with the style(s) example of Shared-Explicit (SE) style
      reservations.  When SE-style reservations that exist on other outgoing interfaces but will
           be merged with this reservation to create a refresh message
           for are merged, the previous hop.

      In any of these cases, an error message
      resulting filter spec is returned to the
      receiver(s) responsible for the erroneous message.  An error
      message does not modify state in the nodes through which it
      passes.  Therefore, any reservations established downstream union of the
      node where the failure was detected will persist until the
      receiver(s) responsible cease attempting the reservation. original filter specs.

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

            Figure 7: Shared-Explicit (SE) Reservation Example

      The erroneous message may or may not be propagated forward.  In
      general, if the error is likely to be repeated at every node
      further along the path, it is best three examples just shown assume that data packets from S1,
      S2, and S3 are routed to drop the erroneous message
      rather than generate a flood of error messages; this is the case
      for the last four error classes listed above. both outgoing interfaces.  The first two error
      classes, admission control and administrative policy, may or may
      not allow propagation top part
      of the message, depending upon the detailed
      reason Figure 8 shows another routing assumption: data packets from S2
      and perhaps on local administrative policy and/or the
      particular service request.  More complete rules S3 are given in not forwarded to interface (c), e.g., because the
      error definitions in Appendix B.

      An erroneous FILTER_SPEC object in
      network topology provides a RESV message will normally be
      detected at the first RSVP hop shorter path for these senders towards
      R1, not traversing this node.  The bottom part of Figure 8 shows
      WF style reservations under this assumption.  Since there is no
      route from (b) to (c), the receiver application,
      i.e., within reservation forwarded out interface (b)
      considers only the receiver host.  However, reservation on interface (d).

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

                       Router Configuration

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

             Figure 8: WF Reservation Example -- Partial Routing

2. RSVP Protocol Mechanisms

   2.1 RSVP Messages

       Previous       Incoming           Outgoing             Next
       Hops           Interfaces         Interfaces           Hops

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

                         Figure 9: Router Using RSVP

      Figure 9 illustrates RSVP's model of a router node.  Each data
      stream arrives from a "previous hop" through a corresponding
      "incoming interface" and departs through one or more "outgoing
      interface(s)".  The same physical interface may act in both the
      incoming and outgoing roles for different data flows in the same
      session.  Multiple previous hops and/or next hops may be reached
      through a given physical interface, as a result of the connected
      network being a shared medium, or the existence of non-RSVP
      routers in the path to the next RSVP hop (see Section 2.8).  An
      RSVP daemon preserves the next and previous hop addresses in its
      reservation and path state, respectively.

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

      Each receiver host sends RSVP reservation request (RESV) messages
      upstream towards the senders.  These reservation messages must
      follow exactly the reverse of the routes the data packets will
      use, upstream to all the sender hosts included in the sender
      selection.  RESV messages must be delivered to the sender hosts
      themselves so that the hosts can set up appropriate traffic
      control parameters for the first hop.

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

      A PATH message may carry the following information in addition to
      the previous hop address:

      o    Sender Template

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

           Like a filter spec, the Sender Template is less than fully
           general at present, specifying only the sender IP address and
           optionally the UDP/TCP sender port.  It assumes the protocol
           Id for the session.

      o    Sender Tspec

           A PATH message is required to carry a Sender Tspec, which
           defines the traffic characteristics of the data stream that
           the sender will generate.  This Tspec is used by traffic
           control to prevent over-reservation (and perhaps unnecessary
           Admission Control failure) on all links on which the named
           sender is the only source sending to the session.

      o    Adspec

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

      For protocol efficiency, RSVP also allows multiple sets of
      reservation information for the same session to be "packed" into a
      single RESV message.  Unlike merging, packing preserves
      information.  For simplicity, however, the protocol currently
      prohibits packing reservations of different sessions into the same
      RSVP message.

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

   2.2 Port Usage

      At present an RSVP session is defined by the triple: (DestAddress,
      ProtocolId, DstPort).  Here DstPort is a UDP/TCP destination port
      field (i.e., a 16-bit quantity carried at octet offset +2 in the
      transport header).  DstPort may be omitted (set to zero) if the
      ProtocolId specifies a protocol that does not have a destination
      port field in the format used by UDP and TCP.

      RSVP allows any value for ProtocolId.  However, end-system
      implementations of RSVP may know about certain values for this
      field, and in particular must know about the values for UDP and
      TCP (17 and 6, respectively).  An end system should give an admission control
      failure caused error
      to an application that either:

      o    specifies a non-zero DstPort for a protocol that does not
           have UDP/TCP-like ports, or

      o    specifies a zero DstPort for a protocol that does have
           UDP/TCP-like ports.

      Filter specs and sender templates are defined by the pair:
      (SrcAddress, SrcPort), where SrcPort is a UDP/TCP source port
      field (i.e., a 16-bit quantity carried at octet offset +0 in the
      transport header).   SrcPort may be omitted (set to zero) in
      certain cases.  The following rules hold for the use of zero
      DstPort and/or SrcPort fields in RSVP.

      1.   Destination ports must be consistent.

           Path state and/or reservation state for the same DestAddress
           and ProtocolId must have DstPort values that are all zero or
           all non-zero.  Violation of this condition in a node is a
           "Conflicting Dest Port" error.

      2.   Destination ports rule.

           If DstPort in a session definition is zero, all SrcPort
           fields used for that session must also be zero.  The
           assumption here is that the protocol does not have TCP/UDP-
           like ports.   Violation of this condition in a node is a
           "Conflicting Src Port" error.

      3.   Source Ports must be consistent.

           A sender host must not send path state both with and without
           a zero SrcPort.  Violation of this condition is an "Ambiguous
           Path" error.

   2.3 Merging Flowspecs

      As noted earlier, a single physical interface may receive multiple
      reservation request from different next hops for the same session
      and with the same filter spec, but RSVP should install only one
      reservation on that interface.  This reservation should an
      effective flowspec that is the "maximum" of the flowspecs
      requested by the different next hops.  Similarly, a RESV message
      forwarded to a previous hop should carry a flowspec that is the
      "maximum" of the flowspecs requested by the different next hops.
      Both cases represent flowspec merging.

      Merging flowspecs requires calculating the "largest" of a FLOWSPEC or a POLICY_DATA object set of
      flowspecs, which are otherwise opaque to RSVP.  Since flowspecs
      are multi-dimensional vectors (they contain both Tspec and Rspec
      components, each of which may itself be
      detected anywhere along multi-dimensional),
      generally speaking they cannot be strictly ordered.  However, in
      many cases one can easily determine the path(s) to "larger" of two flowspecs,
      such as when both request the sender(s). same bandwidth but one requests a
      tighter delay, or when one of the two requests both a higher
      bandwidth and a tighter delay bound.  When admission control fails for the "larger" of the two
      cannot be determined, RSVP must compute and use a reservation request, any
      existing reservation third flowspec
      that is left in place.  This prevents at least as large as each, i.e., a new, very
      large, reservation from disrupting "least upper bound"
      (LUB).  If the existing QoS by merging
      with two flowspecs are incomparable, their comparison
      will treated as an existing reservation and then failing admission control
      (this has been called error.

      We can now give the "killer reservation" problem).

      A node may be allowed complete rules for calculating the effective
      flowspec (Te, Re) to preempt be installed on an established reservation, interface.  Here Te is the
      effective Tspec and Re is the effective Rspec.  As an example,
      consider interface (d) in
      accordance with administrative policy; this will also trigger Figure 9.

      1.   Re is calculated as the largest (using an
      error message to LUB if necessary)
           of the Rspecs in RESV messages from different next hops
           (e.g., D and D') but the same outgoing interface (d).

      2.   All Tspecs that were supplied in PATH messages from different
           previous hops (e.g., some or all affected receivers.

   2.2 Merging of A, B, and Packing

      A previous section explained that reservation requests B' in Figure 9)
           are summed; call this sum Path_Te.

      3.   The maximum Tspec supplied in RESV messages are necessarily merged, from different
           next hops (e.g., D and D') is calculated; call this Resv_Te.

      4.   Te is the GLB (greatest lower bound) of Path_Te and Resv_Te.
           For Tspecs defined by token bucket parameters, this means to match
           take the multicast
      distribution tree.  As a result, only smaller of the essential (i.e., bucket size and the
      "largest") reservation requests rate parameters.

      Flowspecs, Tspecs, and Adspecs are forwarded, once per refresh
      period.  A successful reservation request will propagate as far as
      the closest point(s) along the sink tree opaque to RSVP.  Therefore, the sender(s) where a
      reservation level equal or greater than that being requested has
      been made.  At that point, the merging process will drop it in
      favor
      last of another, equal or larger, reservation request.

      For protocol efficiency, RSVP also allows multiple sets these steps is actually performed by traffic control.  The
      definition and implementation of path
      (or reservation) information for the same session to be "packed"
      into a single PATH (or RESV) message, respectively.  (For
      simplicity, the protocol currently prohibits packing different
      sessions into rules for comparing
      flowspecs, calculating LUB's, and summing Tspecs are outside the same
      definition of RSVP message).  Unlike merging, packing
      preserves information.

      In order to merge reservations, [ServTempl95a].  Section 3.9.4 shows generic
      calls that an RSVP must be able daemon could use for these functions.

   2.4 Soft State

      RSVP takes a "soft state" approach to merge
      flowspecs managing the reservation
      state in routers and hosts.  RSVP soft state is created and to merge filterspecs.  Merging flowspecs requires
      calculating the
      periodically refreshed by PATH and RESV messages.  The state is
      deleted if no matching refresh messages arrive before the "largest"
      expiration of a set of flowspecs, which are
      otherwise opaque to RSVP.  Merging flowspecs is required both to
      calculate "cleanup timeout" interval.  It may also be
      deleted by an explicit "teardown" message, described in the effective flowspec to install on a given physical
      interface (see next
      section.  At the discussion in connection with Figure 5), expiration of each "refresh timeout" period and to
      merge flowspecs when sending
      after a state change, RSVP scans its state to build and forward
      PATH and RESV refresh message upstream.  Since
      flowspecs are generally multi-dimensional vectors (they contain
      both Tspec messages to succeeding hops.

      PATH and Rspec components, each of which may itself be
      multi-dimensional), they RESV messages are not strictly ordered. idempotent.  When it cannot
      take a route changes, the larger of two flowspecs, RSVP must compute
      next PATH message will initialize the path state on the new route,
      and use future RESV messages will establish reservation state there;
      the state on the now-unused segment of the route will time out.
      Thus, whether a
      third flowspec that message is at least as large as each, i.e., "new" or a "least
      upper bound" (LUB).  It is also possible for two flowspecs to be
      incomparable, which "refresh" is treated determined
      separately at each node, depending upon the existing state at that
      node.

      RSVP sends its messages as an error.  The definition IP datagrams with no reliability
      enhancement.  Periodic transmission of refresh messages by hosts
      and
      implementation routers is expected to handle the occasional loss of the rules for comparing flowspecs are outside RSVP proper, but they are defined as part of
      messages.  If the service templates
      [ServTempl95a]

      We effective cleanup timeout is set to K times the
      refresh timeout period, then RSVP can now give tolerate K-1 successive RSVP
      packet losses without falsely erasing a reservation.  We recommend
      that the complete rules network traffic control mechanism be statically
      configured to grant some minimal bandwidth for calculating RSVP messages to
      protect them from congestion losses.

      The state maintained by RSVP is dynamic; to change the effective
      flowspec (Te, Re), set of
      senders Si or to change any QoS request, a host simply starts
      sending revised PATH and/or RESV messages.  The result should be installed on
      an interface.  Here Te is
      the effective Tspec and Re is appropriate adjustment in the effective Rspec.  As an example,
      consider interface (d) RSVP state in Figure 5.

      o    Re all nodes along the
      path.

      In steady state, refreshing is calculated as performed hop-by-hop to allow
      merging.  If the largest (using an LUB if necessary)
           of received state differs from the Rspecs stored state, the
      stored state is updated.  If this update results in RESV modification
      of state to be forwarded in refresh messages, these refresh
      messages from different next hops
           (e.g., D must be generated and D') but forwarded immediately, so that
      state changes can be propagated end-to-end without delay.
      However, propagation of a change stops when and if it reaches a
      point where merging causes no resulting state change.  This
      minimizes RSVP control traffic due to changes and is essential for
      scaling to large multicast groups.

      State that is received through a particular interface I* should
      never be forwarded out the same outgoing interface.  Conversely, state that
      is forwarded out interface (d).

      o    The Tspecs supplied in PATH messages from I* must be computed using only state
      that arrived on interfaces different previous
           hops which may send data packets to this reservation (e.g.,
           some or all from I*.  A trivial example
      of A, B, and B' this rule is illustrated in Figure 5) are summed; call 10, which shows a transit
      router with one sender and one receiver on each interface (and
      assumes one next/previous hop per interface).  Interfaces (a) and
      (c) serve as both outgoing and incoming interfaces for this sum Path_Te.

      o    The maximum Tspec supplied
      session.  Both receivers are making wildcard-scope reservations,
      in which the RESV messages from different
           next are forwarded to all previous hops (e.g., D and D') is calculated; call this Resv_Te.

      o    Te is for
      senders in the GLB (greatest lower bound) of Path_Te and Resv_Te.
           For Tspecs defined by token bucket parameters, this means to
           take group, with the smaller exception of the bucket size and the rate parameters.

      Two filter specs can be merged only next hop from
      which they are identical or if one
      contains the other through wild-carding. came.  The result is independent reservations in the more
      general of the two, i.e.,
      two directions.

      There is an additional rule governing the one with more wildcard fields.

   2.3 Soft State

      To maintain reservation state, forwarding of RESV
      messages: state from RESV messages received from outgoing
      interface Io should be forwarded to incoming interface Ii only if
      PATH messages from Ii are forwarded to Io.

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

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

                     Figure 10: Independent Reservations

   2.5 Teardown

      Upon arrival, RSVP keeps "soft state" in router "teardown" messages remove path and host nodes.  RSVP soft reservation
      state immediately.  Although it is created not necessary to explicitly
      tear down an old reservation, we recommend that all end hosts send
      a teardown request as soon as an application finishes.

      There are two types of RSVP teardown message, PTEAR and periodically
      refreshed by PATH RTEAR.  A
      PTEAR message travels towards all receivers downstream from its
      point of initiation and RESV messages.  The deletes path state is deleted if no
      matching refresh messages arrive before along the expiration way.  An
      RTEAR message deletes reservation state and travels towards all
      senders upstream from its point of initiation.  A PTEAR (RTEAR)
      message may be conceptualized as a
      "cleanup timeout" interval.  It reversed-sense Path message
      (Resv message, respectively).

      A teardown request may also be deleted initiated either by an application in an
      end system (sender or receiver), or by a router as the result of an explicit "teardown" message, described in
      state timeout.  Once initiated, a teardown request must be
      forwarded hop-by-hop without delay.  A teardown message deletes
      the next section.
      At specified state in the expiration of each "refresh timeout" period, RSVP scans its node where it is received.  As always,
      this state change will be propagated immediately to build and forward PATH and RESV refresh messages to
      succeeding hops.

      When the next node,
      but only if there will be a route changes, the next PATH net change after merging.  As a
      result, an RTEAR message will initialize the
      path state on prune the new route, and future RESV messages will
      establish reservation state there; the state on the now-unused
      segment back
      (only) as far as possible.

      Like all other RSVP messages, teardown requests are not delivered
      reliably.  The loss of a teardown request message will not cause a
      protocol failure because the route unused state will eventually time out.  Thus, whether a message out
      even though it is
      "new" or not explicitly deleted.  If a "refresh" teardown message
      is determined separately at each node,
      depending upon lost, the existence of state at router that node.

      RSVP sends failed to receive that message will time
      out its messages as IP datagrams without reliability
      enhancement.  Periodic transmission of refresh messages by hosts state and routers initiate a new teardown message beyond the loss
      point.  Assuming that RSVP message loss probability is expected small, the
      longest time to replace any lost delete state will seldom exceed one refresh
      timeout period.

   2.6 Errors and Acknowledgments

      There are two RSVP messages.  To
      tolerate K-1 successive packet losses, error messages, RERR and PERR, and a
      reservation confirmation message RACK.

      There are a number of ways for a syntactically valid reservation
      request to fail at some node along the path, triggering a RERR
      message:

      1.   The effective cleanup
      timeout must flowspec that is computed using the new request
           may fail admission control.

      2.   Administrative policy may prevent the requested reservation.

      3.   There may be at least K times no matching path state, so that the refresh timeout.  In
      addition, request
           cannot be forwarded towards the sender(s).

      4.   A reservation style that requires the traffic control mechanism explicit selection of a
           unique sender may have a filter spec that is ambiguous, i.e.,
           that matches more than one sender in the network should be
      statically configured to grant high-reliability service to RSVP
      messages, path state, due to protect RSVP messages from congestion losses.
           the use of wildcard fields in the filter spec.

      5.   The "soft"  state maintained by RSVP is dynamic; to change requested style may be incompatible with the set style(s) of senders Si or receivers Rj
           existing reservations.  The incompatibility may occur among
           reservations for the same session on the same outgoing
           interface, or to change among effective reservations on different
           outgoing interfaces.

      In any QoS request, of these cases, a host
      simply starts sending revised PATH and/or RESV messages.  The
      result should be an appropriate adjustment in RERR message is returned to the RSVP state and
      immediate propagation
      receiver(s) responsible for the erroneous request.  A node may
      also decide to preempt an established reservation.  A preemption
      will trigger a RERR message to all nodes along affected receivers.  An error
      message does not modify state in the path.

      In steady state, refreshing is performed hop-by-hop, nodes through which allows
      merging and packing as described in it
      passes.  Therefore, any reservations established downstream of the previous section.  If
      node where the
      received state differs from failure occurred will persist until the stored state, responsible
      receiver(s) explicitly tear down the stored state is
      updated.  Furthermore, if or allow it to time
      out.

      In this version of RSVP, detection of an error in a reservation
      request not only generates a RERR message, it also prevents the result will
      request from being forwarded further.  This may not always be the
      desirable behavior; for example, a receiver may want a reservation
      request to modify propagate all the refresh
      messages way to be generated, these refresh messages must be generated
      and forwarded immediately.  This will result in state changes
      propagating end-to-end without delay. the sender despite an
      admission control failure at a particular link along the path.
      However, propagation design of a
      change stops when the appropriate mechanism has proved difficult,
      and if it reaches a point where merging causes
      no resulting state change.  This minimizes RSVP therefore this version take the simplest approach.

      When admission control traffic
      due to changes and is essential fails for scaling to large multicast
      groups.

      The RSVP state associated with a session reservation request, any
      existing reservation is left in place.  This prevents a particular node is
      divided into atomic elements that are created, refreshed, and
      timed out independently.  The atomicity is determined new, very
      large, reservation from disrupting the existing QoS by merging
      with an existing reservation and then failing admission control
      (this has been called the
      requirement that any sender or "killer reservation" problem).

      To request a confirmation for its reservation request, a receiver may enter or leave
      Rj includes in the
      session at any time, so RESV message a confirmation-request object
      containing its state should be created and timed out
      independently.

   2.4 Teardown

      RSVP teardown messages remove path IP address.  At each merge point, only the largest
      flowspec and reservation state without
      waiting for any accompanying confirmation-request object is
      forwarded upstream.  If the cleanup timeout period, as an optimization to
      release resources quickly.  It reservation request from Rj is not necessary equal
      to explicitly tear
      down an old reservation, although it may be desirable in many
      cases.

      A teardown request may be initiated either by an application in an
      end system (sender or receiver), or by a router as smaller than the result of
      state timeout.  Once initiated, reservation in place on a teardown request should be
      forwarded hop-by-hop without delay.

      Teardown messages (like other RSVP messages) node, its RESV
      are not delivered
      reliably.  However, loss of forwarded further, and if the RESV included an
      confirmation-request object, a teardown RACK message is not considered a
      problem because sent back to Rj.
      This mechanism has the state following consequences:

      o    A new reservation request with a flowspec larger than any in
           place for a session will time out even if it is not
      explicitly deleted.  If one normally result in either a RERR or more teardown
           a RACK message hops are
      lost, the router that failed back to receive a teardown the receiver from each sender.  In
           this case, the RACK message will
      time out its state and initiate be an end-to-end
           confirmation.

      o    The receipt of a new teardown message beyond the
      loss point.  Assuming that RSVP message loss probability is small, RACK gives no guarantees.  Assume the longest time to delete state will seldom exceed one refresh
      timeout period.

      There are first
           two types of RSVP teardown message, PTEAR and RTEAR.  A
      PTEAR message travels towards all receivers downstream reservation requests from its
      point of initiation receivers R1 and deletes path state along R2 arrive at
           the way.  A RTEAR
      message deletes node where they are merged.  R2, whose reservation state and travels towards all senders
      upstream from its point of initiation.  A PTEAR (RTEAR) message was
           the second to arrive at that node, may be conceptualized as receive a reversed-sense Path message (Resv
      message, respectively).

      A teardown message deletes RACK from
           that node while R1's request has not yet propagated all the specified state
           way to a matching sender and may still fail.  In this case,
           R2 will receive a RACK although there is no end-to-end
           reservation in place.  Furthermore, if the node where
      it two flowspecs are
           equal, R2 may receive a RACK followed by a RERR.  However, if
           its flowspec is received.  Like any other state change, this smaller, R2 will be
      propagated immediately to the next node, but receive only if it represents the RACK.

      o    Despite these uncertainties, receipt of a net change after merging.  As RACK indicates a result, an RTEAR message will
      prune
           high probability that the reservation state back (only) as far as possible.

   2.5 Admission is in place.

      o    Finally, note that RERR and/or RACK messages may be lost.

   2.7 Policy and 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 is likely to be
      required.  This back pressure might take the form of
      administrative rules, or of some form of real or virtual billing
      for the `cost' "cost" of a reservation.  The form and contents of such
      back pressure is a matter of administrative policy that may be
      determined independently by each administrative domain in the
      Internet.

      Therefore, admission control at each node is likely to contain a
      policy component as well as in addition to a resource reservation component.
      As input to the 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 integrity of the policy-based admission control
      mechanisms, it may be necessary to ensure the integrity of RSVP
      messages against corruption or spoofing, hop by hop.  For this
      purpose, RSVP messages may carry integrity objects that can be
      created and verified by neighboring neighbor RSVP-capable nodes.  These
      objects are expected to contain an encrypted part and to assume a
      shared secret between neighbors.

      User policy data in reservation request messages presents a
      scaling problem.  When a multicast group has a large number of
      receivers, it will not be possible impossible or desirable undesirable to carry all the
      receivers' policy data upstream to the sender(s).  The policy data
      will have to be administratively merged, merged at places near enough to the
      receivers
      receivers, to avoid excessive policy data.  Administrative merging
      implies checking the user credentials and accounting data and then
      substituting a token indicating the check has succeeded.  A chain
      of trust established using an integrity field will allow upstream
      nodes to accept these tokens.

      In summary, different administrative domain in the Internet may
      have different policies regarding their resource usage and
      reservation.  The role of RSVP is to carry policy data associated
      with each reservation to the network as needed.  Note that the
      merge points for policy data are likely to be at the 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

   2.8 Automatic RSVP Tunneling

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

      RSVP will automatically tunnel tunnels through such a non-RSVP cloud.  Both
      RSVP and non-RSVP routers forward PATH messages towards the
      destination address using their local uni-/multicast routing
      table.  Therefore, the routing of PATH messages will be unaffected
      by non-RSVP routers in the path.  When a PATH message traverses a
      non-RSVP cloud, it carries to the copies that emerge will carry as next RSVP-capable node the IP
      address of the last RSVP-capable router before entering the cloud.
      This effectively constructs a Previous
      Hop tunnel through the cloud for RESV
      messages, which can then be forwarded directly to the next RSVP-
      capable router on the path(s) back towards the source.

      Some interconnection topologies of RSVP and non-RSVP routers can
      cause RESV messages to arrive at the wrong RSVP-capable node, or
      to arrive at the wrong interface at the correct node.  An RSVP
      daemon must be prepared to handle either situation.  When a RESV
      message arrives, its IP destination address should normally be the IP
      address of one of the last RSVP-capable router before
      entering the cloud.  This will effectively construct a tunnel
      through local interfaces.  If so, the cloud for RESV messages, which will reservation
      should be forwarded
      directly to the next RSVP-capable router made on the path(s) back
      towards the source.

      Automatic tunneling is not perfect; in some circumstances addressed interface, even if it may
      distribute path information to RSVP-capable routers is not included
      in the data distribution paths,
      one on which may create unused
      reservations at these routers.  This is because PATH messages
      carry the IP source address of message arrived.  If the previous hop, destination address does
      not of the
      original sender, match any local interface and multicast routing may depend upon the source
      as well as the destination address.  This can message is not a PATH or
      PTEAR, it should be overcome forwarded without further processing by
      manual configuration of the neighboring RSVP programs, when
      necessary.

   2.7 this
      node.

   2.9 Host Model

      Before a session can be created, the session identification,
      comprised of DestAddress and perhaps the generalized destination
      port, must be assigned and communicated to all the senders and
      receivers by some out-of-band mechanism.  When an RSVP session is
      being set up, the following events happen at the end systems.

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

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

      H3   A receiver application receives a PATH message.

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

      H5   A sender application receives a RESV message.

      H6   A sender starts sending data packets.

      There are several synchronization considerations.

      o    H1 and H2 may happen in either order.

      o    Suppose that a new sender starts sending data (H6) but there
           are no multicast routes because no receivers have joined the
           group (H1).  Then there will be no
           multicast routes beyond the host (or beyond the first RSVP-
           capable router) along the path; the data will be dropped at some router
           node (which node depends upon the first hop routing protocol) until
           receivers(s) do appear (assuming a
           multicast routing protocol that "prunes off" or otherwise
           avoids unnecessary paths). appear.

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

      o    If a receiver starts sending RESV messages (H4) before
           receiving any PATH messages have reached it (H3), RSVP will return error
           messages to the receiver.

           The receiver may simply choose to ignore such error messages,
           or it may avoid them by waiting for PATH messages before
           sending RESV messages.  [LZ: should recommend that a receiver
           wait for at least PATH messages to arrive before sending RESV
           messages.]

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

3. Examples

   We use the following notation for a RESV message:

   1.   Wildcard-Filter (WF)

        WF( *{Q})

        Here "*{Q}" represents a Flow Descriptor with RSVP Functional Specification

   3.1 RSVP Message Formats

      An RSVP message consists of a "wildcard" scope
        (choosing all senders) and common header followed by a flowspec variable
      number of quantity Q.

   2.   Fixed-Filter (FF)

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

        A list variable-length, typed "objects".  The subsections that
      follow define the formats of (sender, flowspec) pairs, i.e., flow descriptors,
        packed into a single RESV message.

   3.   Shared Explicit (SE)

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

        A list the common header, the object
      structures, and each of shared reservations, the RSVP message types.

      For each specified by a single
        flowspec and RSVP message type, there is a list set of senders.

   For simplicity we assume here that flowspecs are one-dimensional,
   defining rules for example the average throughput,
      permissible choice and state them as a
   multiple ordering of some unspecified base resource quantity B.

   Figure 6 shows schematically a router object types.  These rules are
      specified using Backus-Naur Form (BNF) augmented with two previous hops labeled
   (a) and (b) and two outgoing interfaces labeled (c) and (d). square
      brackets surrounding optional sub-sequences.

      3.1.1 Common Header

                0             1              2             3
         +-------------+-------------+-------------+-------------+
         | Vers | Flags|    Type     |       RSVP Checksum       |
         +-------------+-------------+-------------+-------------+
         |         RSVP Length       |  (Reserved) |  Send_TTL   |
         +-------------+-------------+-------------+-------------+
         |                     Message ID                        |
         +----------+--+-------------+-------------+-------------+
         |(Reserved)|MF|             Fragment offset             |
         +----------+--+-------------+-------------+-------------+

         The fields in the common header are as follows:

         Vers: 4 bits

              Protocol version number.  This
   topology will be assumed is version 1.

         Flags: 4 bits

              (None defined yet)

         Type: 8 bits

              1 = PATH

              2 = RESV

              3 = PERR

              4 = RERR
              5 = PTEAR

              6 = RTEAR

              7 = RACK

         RSVP Checksum: 16 bits

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

         RSVP Length: 16 bits

              The total length of this RSVP packet in bytes, including
              the examples common header and the variable-length objects that
              follow.  There are
   three upstream senders; packets from sender S1 (S2 and S3) arrive
   through previous hop (a) ((b), respectively).  There are also three
   downstream receivers; packets bound for R1 and R2 (R3) are routed via
   outgoing interface (c) ((d) respectively).

   In addition to  If the connectivity shown in 6, we must also specify MF flag is on or the
   multicast routing within this node.  Assume first that data packets
   (hence, PATH messages) from each Si shown in Figure 6 Fragment Offset field
              is routed to
   both outgoing interfaces.  Under non-zero, 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, is the "Receive" column shows length of the RESV messages received
   over outgoing interfaces (c) and (d) and current fragment of
              a larger message.

         Send_TTL: 8 bits

              The IP TTL value with which the "Reserve" column shows message was sent.

         Message ID: 32 bits

              A label shared by all fragments of one message from a
              given next/previous RSVP hop.  An RSVP implementation
              assigns a unique Message ID to each message it sends.

         MF: More Fragments Flag: 1 bit

              This flag is the resulting reservation state low-order bit of a byte; the seven high-
              order bits are reserved.  It is on for each interface.   The "Send"
   column shows all but the last
              fragment of a message.

         Fragment Offset: 24 bits

              This field gives the RESV messages forwarded to previous hops (a) and
   (b).  In byte offset of the "Reserve" column, each box represents fragment in the
              message.

      3.1.2 Object Formats

         Every object consists of one reservation
   "channel", or more 32-bit words with the corresponding filter.  As a result of merging,
   only one-
         word header, in the largest flowspec is forwarded upstream to each previous hop.

                          |
            Send          |       Reserve              Receive
                          |
                          |       _______
      WF( *{3B} ) <- (a)  |  (c) following format:

                0             1              2             3
         +-------------+-------------+-------------+-------------+
         | * {B}       Length (bytes)      |    (c) <- WF( *{B} )  Class-Num  |      |_______|   C-Type    |
   -----------------------|----------------------------------------
         +-------------+-------------+-------------+-------------+
         |       _______
      WF( *{3B} ) <- (b)                                                       |  (d)
         //                  (Object contents)                   //
         | * {3B}|    (d) <- WF( *{3B} )                                                       |      |_______|

            Figure 7: Wildcard-Filter (WF) Reservation Example

   Figure 8 shows Fixed-Filter (FF) style reservations.  The flow
   descriptors for senders S2 and S3, received from outgoing interfaces
   (c)
         +-------------+-------------+-------------+-------------+

         An object header has the following fields:

         Length

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

         Class-Num

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

              NULL

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

              SESSION

                   Contains the IP destination address (DestAddress),
                   the IP protocol id, and a generalized destination
                   port, to previous hop b.
   On define a specific session for the other hand,
                   objects that follow.  Required in every RSVP message.

              RSVP_HOP

                   Carries the two different flow descriptors for sender S1
   are merged into IP address of the single message FF( S1{3B} ), which is RSVP-capable node that
                   sent this message.  This document refers to
   previous hop (a).  For each outgoing interface, there is a private
   reservation
                   RSVP_HOP object as a PHOP ("previous hop") object for each source that has been requested, but this private
                   downstream messages or as a NHOP ("next hop") object
                   for upstream messages.

              TIME_VALUES

                   Contains the value for the refresh period R used by
                   the creator of the message; see 3.5.  Required in
                   every PATH and RESV message.

              STYLE

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

              FLOWSPEC

                   Defines a desired QoS, in a RESV message.

              FILTER_SPEC

                   Defines a subset of session data packets that made should
                   receive 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 8: Fixed-Filter (FF) Reservation Example

   Figure 9 shows 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 identify a
                   sender, in a simple example PATH message.

              SENDER_TSPEC

                   Defines the traffic characteristics of Shared-Explicit (SE) style
   reservations.  Here each outgoing interface has a single reservation sender's
                   data stream, in a PATH message.

              ADSPEC

                   Carries OPWA data, in a PATH message.

              ERROR_SPEC

                   Specifies an error, in a PERR or RERR message.

              POLICY_DATA

                   Carries information that will allow a local policy
                   module to decide whether an associated reservation is shared by
                   administratively permitted.  May appear in a PATH or
                   RESV message.

              INTEGRITY

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

              SCOPE

                   An explicit list of senders.

                       |
         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 (SE) Reservation Example sender hosts towards which to
                   forward a message.  May appear in a RESV, RERR, or
                   RTEAR message.

              RESV_CONFIRM

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

         C-Type

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

         The three examples just shown assume full routing, i.e., data packets
   from S1, S2, maximum object content length is 65528 bytes.  The Class-
         Num and S3 are routed C-Type fields may be used together as a 16-bit number
         to both outgoing interfaces. define a unique type for each object.

         The top
   part high-order bit of the Class-Num is used to determine what
         action a node should take if it does not recognize the Class-
         Num of Figure 10 shows another routing assumption: an object; see Section 3.8.

      3.1.3 Path Message

         Each sender host periodically sends a PATH message containing a
         description of each data packets stream it originates.  The PATH
         message travels from S1 are not forwarded a sender to interface (d), because receiver(s) along the mesh topology
   provides a shorter path for S1 -> R3 that does not traverse this
   node. same
         path(s) used by the data packets.  The bottom IP source address of Figure 10 shows WF style reservations under this
   assumption.  Since there a
         PATH message is no route from (a) to (d), an address of the reservation
   forwarded out interface (a) considers only sender it describes, while
         the 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: WF Reservation Example -- Partial Routing

   Finally, we note that state that destination address is received the DestAddress for the session.
         These addresses assure that the message will be correctly
         routed through a particular
   interface I is never forwarded out non-RSVP cloud.

         Each RSVP-capable node along the path(s) captures PATH messages
         and processes them to build local path state.  The node then
         forwards the PATH messages towards the receiver(s), replicating
         it as dictated by multicast routing, while preserving the
         original IP source address.  PATH messages eventually reach the
         applications on all receivers; however, they are not looped
         back to a receiver running in the same interface.  Conversely,
   state that application process as
         the sender.

         The format of a PATH message is forwarded out as follows:

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

                                     [ <INTEGRITY> ]  <TIME_VALUES>

                                     <sender descriptor>

           <sender descriptor> ::= <SENDER_TEMPLATE>   <SENDER_TSPEC>

                                    [ <POLICY_DATA> ]   [ <ADSPEC> ]

         The PHOP (i.e., the RSVP_HOP) object of each PATH message
         contains the address of the interface I must be computed using only
   state that arrived on interfaces different from I.  A trivial example through which the PATH
         message was most recently sent.  The SENDER_TEMPLATE object
         defines the format of data packets from this rule is illustrated in Figure 11, which shows sender, while the
         SENDER_TSPEC object specifies the traffic characteristics of
         the flow.  Optionally, there may be a transit
   router with one sender POLICY_DATA object
         specifying user credential and one receiver on each interface (and
   assumes one next/previous hop per interface).  Interfaces (a) accounting information and/or an
         ADSPEC object carrying advertising (OPWA) data.

         A PATH message received at a node is processed to create path
         state for the sender defined by the SENDER_TEMPLATE and (c)
   are both outgoing SESSION
         objects.  Any POLICY_DATA, SENDER_TSPEC, and incoming interfaces for this session.  Both
   receivers ADSPEC objects are making wildcard-scope reservations,
         also saved in the path state.  If an error is encountered while
         processing a PATH message, a PERR message is sent to the
         originating sender of the PATH message.  PATH messages must
         satisfy the rules on SrcPort and DstPort in which Section 2.2.

         Periodically, the RESV RSVP daemon at a node scans the path state to
         create new PATH messages are forwarded to all previous hops forward downstream.  Each message
         contains a sender descriptor defining one sender.  The RSVP
         daemon forwards these messages using routing information it
         obtains from the appropriate uni-/multicast routing daemon.
         The route depends upon the session DestAddress, and for senders in some
         routing protocols also upon the group,
   with source (sender's IP) address.
         The routing information generally includes the exception list of the next hop from none or
         more outgoing interfaces to which they came.  These
   result in independent reservations in the two directions.

                      ________________ PATH message to be
         forwarded.  Because each outgoing interface has a |                | c
   ( R1, S1 ) <----->|     Router     |<-----> ( R2, S2 )
                     |________________|

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

                    Figure 11: Independent Reservations

4. RSVP Functional Specification

   4.1 RSVP Message Formats

      All RSVP different IP
         address, the PATH messages sent out different interfaces
         contain different PHOP addresses.  In addition, any ADSPEC or
         POLICY_DATA objects carried in PATH messages consist will also
         generally differ for different outgoing interfaces.

         Some IP multicast routing protocols (e.g., DVMRP, PIM, and
         MOSPF) also keep track of the expected incoming interface for
         each source host to a common header followed by a
      variable number of variable-length typed "objects".  The
      subsections that follow define multicast group.  Whenever this
         information is available, RSVP should check the formats incoming
         interface of each PATH message and immediately discard those
         messages that have arrived on the common header, wrong interface.

      3.1.4 Resv Messages

         RESV messages carry reservation requests hop-by-hop from
         receivers to senders, along the object structures, and each reverse paths of data flows for
         the RSVP message types.

      For each RSVP session.  The IP destination address of a RESV message type, there is a set of rules for
         the
      permissible ordering and choice unicast address 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 | Flags|    Type     |       RSVP Checksum       |
         +-------------+-------------+-------------+-------------+
         |         RSVP Length       |        (Reserved)         |
         +-------------+-------------+-------------+-------------+
         |                     Message ID                        |
         +----------+--+-------------+-------------+-------------+
         |(Reserved)|MF|             Fragment offset             |
         +----------+--+-------------+-------------+-------------+ a previous-hop node, obtained from the
         path state.  The fields in IP source address is an address of the common header are node
         that sent the message.

         The RESV message format is as follows:

         Vers: 4 bits

              Protocol version number.  This is version 1.

         Flags: 4 bits

              (None defined yet)

         Type: 8 bits

              1 = PATH

              2 =

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

                                     [ <INTEGRITY> ] <TIME_VALUES>

                                     [ <S_POLICY_DATA> ]

                                     [ <RESV_CONFIRM> ]  [ <SCOPE> ]

                                     <STYLE> <flow descriptor list>

           <S_POLICY_DATA> ::=  <POLICY_DATA>

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

                              <flow descriptor list>  <flow descriptor>

         The NHOP (i.e., the RSVP_HOP) object contains the IP address of
         the (incoming) interface through which the RESV

              3 = PERR

              4 = RERR
              5 = PTEAR

              6 = RTEAR

         RSVP Checksum: 16 bits

              A standard TCP/UDP checksum over message is
         sent.  The appearance of a RESV_CONFIRM object signals a
         request for a reservation confirmation and carries the contents IP
         address of the RSVP
              message, receiver to which the RACK should be sent.  The
         S_POLICY_DATA object is a POLICY_DATA object that is associated
         with the checksum field replaced by zero.

         RSVP Length: 16 bits entire session.  There may also be flow-specific
         POLICY_DATA objects, as described below.

         The total length BNF above defines a flow descriptor list as simply a list
         of this RSVP packet flow descriptors.  The following style-dependent rules
         specify in bytes, including more detail the common header composition of a valid flow
         descriptor list for each of the reservation styles.

         o    WF Style:

                <flow descriptor list> ::=  <WF flow descriptor>
                <WF flow descriptor> ::= <FLOWSPEC> [ <F_POLICY_DATA> ]

                <F_POLICY_DATA> ::=  <POLICY_DATA>

         o    FF style:

                <flow descriptor list> ::=   <First FF flow descriptor>  |

                              <flow descriptor list> <FF flow descriptor>

                <First FF flow descriptor> ::=

                           <FLOWSPEC>  [ <F_POLICY_DATA> ] <FILTER_SPEC>

                <FF flow descriptor> ::=

                          [ <FLOWSPEC> ] [ <F_POLICY_DATA> ] <FILTER_SPEC>

              Each elementary FF style request is defined by a single
              (FLOWSPEC, FILTER_SPEC) pair, and multiple such requests
              may be packed into the variable-length objects flow descriptor list of a single
              RESV message.  A FLOWSPEC object can be omitted if it is
              identical to the most recent such object that
              follow.  If appeared in
              the MF flag is on or list; the Fragment Offset field
              is non-zero, this first FF flow descriptor must contain a
              FLOWSPEC.

         o    SE style:

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

                <SE flow descriptor> ::=

                         <FLOWSPEC> [ <F_POLICY_DATA> ] <filter spec list>

                <filter spec list> ::=  <FILTER_SPEC>

                                  |  <filter spec list> <FILTER_SPEC>

              Each elementary SE style request is defined by a single SE
              descriptor, which includes a FLOWSPEC defining the length shared
              reservation, optionally a POLICY_DATA object, and a list
              of FILTER_SPEC objects.

         The reservation scope, i.e., the current fragment set of senders towards which a larger message.

         Message ID: 32 bits

              A label shared by all fragments of one message
         particular reservation is to be forwarded, is determined as
         follows:

         o    Explicit sender selection

              Match each FILTER_SPEC object against the path state
              created from SENDER_TEMPLATE objects to select a
              given next/previous RSVP hop.
              particular sender.  An RSVP implementation
              assignes ambiguous match, i.e., a unique Message ID to each message it sends.

         MF: More Fragments Flag: 1 bit

              This flag is the low-order bit
              FILTER_SPEC matching more than one SENDER_TEMPLATE (e.g.
              through use of a byte; the seven high-
              order bits are reserved.  It wildcard port), is on for all but the last
              fragment of a message.

         Fragment Offset: 24 bits

              This field gives the byte offset of the fragment in the
              message.

      4.1.2 Object Formats

         An an error.  Any SCOPE
              object consists of one or more 32-bit words associated with a one-word
         header, in the following format:

                0             1              2             3
         +-------------+-------------+-------------+-------------+
         |       Length (bytes)      |  Class-Num  |   C-Type    |
         +-------------+-------------+-------------+-------------+
         |                                                       |
         //                  (Object contents)                   //
         |                                                       |
         +-------------+-------------+-------------+-------------+
         An object header has reservation should be ignored
              in this case.

         o    Wildcard sender selection

              All senders that route to the following fields:

         Length given outgoing interface
              match this request.  A 16-bit field containing the total object length in
              bytes.  Must always be a multiple SCOPE object, if present, contains
              an explicit list of 4, and at least 4.

         Class-Num

              Identifies sender IP addresses.  If there is no
              SCOPE object, the object class; values scope is determined by the relevant set
              of this field are
              defined in Appendix A.  Each object class has a name,
              which will always be capitalized senders in this document.  An
              RSVP implementation must recognize the following classes:

              NULL

                   A NULL object has path state.  Whenever a Class-Num of zero, and its C-Type RESV message
              with wildcard sender selection is ignored.  Its length forwarded to more than
              one previous hop, a SCOPE object must be at least 4, but can
                   be any multiple of 4.  A NULL object may appear
                   anywhere included in a sequence the
              message.  See Section 3.3 below.

      3.1.5 Error and Confirmation Messages

         There are three types of objects, RSVP error/confirmation messages.

         o    PERR messages result from PATH messages and its contents
                   will be ignored by travel towards
              senders.  PERR messages are routed hop-by-hop using the receiver.

              SESSION

                   Contains
              path state; at each hop, the IP destination address (DestAddress) and
                   possibly a generalized destination port, to define is the
              unicast address of a
                   specific session for previous hop.

         o    RERR messages result from RESV messages and travel towards
              the other objects that follow.
                   Required in every RSVP message.

              RSVP_HOP

                   Carries appropriate receivers.  They are routed hop-by-hop
              using the reservation state; at each hop, the IP
              destination address of is the RSVP-capable node that
                   sent this message.  This document refers to a
                   RSVP_HOP object as unicast address of a PHOP ("previous hop") object for
                   downstream next-hop
              node.

         o    RACK messages or as 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), are sent to
                   override (probabilistically) acknowledge
              reservation requests.  A RACK message is sent as the default values
              result of R and T.

              STYLE

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

              FLOWSPEC

                   Defines appearance of a desired QoS, RESV_CONFIRM object in a
              RESV message.

              FILTER_SPEC

                   Defines message, and contains a subset copy of session data packets that should
                   receive the desired QoS (specified by an FLOWSPEC
                   object), in a RESV message.

              SENDER_TEMPLATE

                   Contains a sender IP address and perhaps some
                   additional demultiplexing information RESV_CONFIRM.
              The RACK message is sent to identify a
                   sender, in a PATH message.

              SENDER_TSPEC

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

              ADSPEC

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

              ERROR_SPEC

                   Specifies an error, in a PERR or RERR message.

              POLICY_DATA

                   Carries information that will allow a local policy
                   module to decide whether an associated reservation
              receiver host; the address is
                   administratively permitted.  May appear in a PATH or
                   RESV message.

              INTEGRITY

                   Contains cryptographic data to authenticate obtained from the
                   originating node, and perhaps
              RESV_CONFIRM object.  A RACK message is forwarded to verify the contents,
              receiver hop-by-hop by (to accommodate the hop-by-hop
              integrity check mechanism).

         Errors encountered while processing error messages must cause
         the error message to be discarded without creating further
         error messages; however, logging of this RSVP message.

              SCOPE

                   An explicit specification such events may be useful.

         None of these messages modify the scope for forwarding
                   a RESV message.

         C-Type

              Object type, unique within Class-Num.  Values state of any node through
         which they pass; instead, they are defined
              in Appendix A. only reported to the end
         application.

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

                                       [ <INTEGRITY> ]  <ERROR_SPEC>

                                       <sender descriptor>

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

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

                                       [ <INTEGRITY> ]  <ERROR_SPEC>

                                       [S_POLICY_DATA]  [ <SCOPE> ]

                                      <STYLE> <error flow descriptor>

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

                                       [ <INTEGRITY> ]  <ERROR_SPEC>

                                       <RESV_CONFIRM>

                                       <STYLE> <flow descriptor list>

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

         The maximum RESV_CONFIRM object content length is 65528 bytes.  The Class-
         Num and C-Type fields (together with the 'Optional' flag bit)
         may be used together as a 16-bit number to define in a unique type
         for each object.

         The high-order bit of the Class-Num RACK message is used to determine what
         action a node should take if it does not recognize the Class-
         Num copy of an object.  If Class-Num < 128, then the node should
         ignore the
         object but forward it (unmerged).  If Class-Num >=
         128, from the RESV message should be rejected and an "Unknown Object
         Class" error returned.  Note that merging cannot be performed
         on unknown object types; as triggered the confirmation.

         The following style-dependent rules define the composition of a result, unmerged objects may be
         forwarded to
         valid error flow descriptor:

         o    WF Style:

                  <error flow descriptor> ::= <WF flow descriptor>
         o    FF style:

                  <error flow descriptor> ::= <FF flow descriptor>

         o    SE style:

                  <error flow descriptor> ::= <SE flow descriptor>

         The ERROR_SPEC object specifies the error and includes the IP
         address of 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 detected the error (Error Node
         Address).  POLICY_DATA objects are included in error messages carry
         in cases where they may provide relevant information from senders to receivers along (i.e.,
         when an administrative failure is being reported).  In a RACK
         message, the paths ERROR_SPEC is used by only to carry the data packets.  The IP destination address of a PATH message is
         the DestAddress for originating node, in the session; Error Node Address; the
         source address error
         specification is an address of the node a special value that sent the indicates a confirmation.

         When a RESV message
         (preferably the address contains a list of flow descriptors (e.g.,
         FF style), the interface through which it was
         sent).  The PHOP (i.e., the RSVP_HOP) object of RSVP implementation should process each PATH
         message must contain the address of the interface through which
         the PATH message was sent.

         The format of flow
         descritor independently and return a PATH separate RERR message for
         each that 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 in error.

         Generally speaking, a sender, and the sender
         descriptor list allows multiple sender descriptors to RERR message should be packed
         into a PATH message.  For each sender in the list, the
         SENDER_TEMPLATE object defines forwarded towards
         all receivers that may have caused the format of data packets; error being reported.
         More specifically:

         o    The node that detects an error in
         addition, a SENDER_TSPEC object may specify the traffic flow, reservation request
              sends a
         POLICY_DATA object may specify user credential and accounting
         information, and an ADSPEC object may carry advertising (OPWA)
         data.

         Each sender host RERR message to the next hop from which the
              erroneous reservation came.

              The message must periodically send PATH message(s)
         containing a sender descriptor for each its own data stream(s).
         Each sender descriptor is forwarded contain the information required to
              define the error and replicated as necessary to follow route the delivery path(s) for error message.  Routing
              requires at least a data packet STYLE object and one or more
              FILTER_SPEC object(s) from the same
         sender, finally reaching erroneous RESV message.
              For an admission control failure, for example, the applications on all receivers
         (except that it is not looped back
              erroneous FLOWSPEC must be included.

         o    Succeeding nodes forward the RERR message using their
              local reservation state, to a receiver included in the same application process as next hops of reservations
              that match the sender).

         It FILTER_SPEC(s) in the message.  For
              reservations with wildcard scope, there is an error to send ambiguous path state, i.e., two or more
         Sender Templates that are different but overlap, due additional
              limitation on forwarding RERR messages, to
         wildcards.  For example, if we represent avoid loops;
              see Section 3.3.

         When the error is an admission control failure, a Sender Template node is
         allowed (but not required) to match the FLOWSPEC as
         (IP address, sender port, protocol id and use `*' well as the
         FILTER_SPEC object(s), to represent
         a wildcard, then each of limit the following pairs distribution of Sender
         Templates would be 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 a RERR
         message received at to those receivers that `caused' the error.  Suppose
         that a node RERR message contains a FLOWSPEC Qerr that is processed to create path
         state for all senders defined by SENDER_TEMPLATE objects in being
         matched against the
         sender descriptor list.  If present, any POLICY_DATA,
         SENDER_TSPEC, and ADSPEC objects are also saved FLOWSPEC Qlocal in the path
         state.  If an error is encountered while processing local reservation
         state in node N.  Qerr, which originated in a PATH
         message, node upstream
         from N, resulted from merging of flowspecs that included
         Qlocal.  Generally, a PERR RERR message is sent can be forwarded to all senders implied by the
         SENDER_TEMPLATEs.

         Periodically,
         receiver(s) that specified the path state is scanned to create new PATH
         messages `biggest' flowspec.  The
         comparison of Qerr against a particular Qlocal to determine
         whether Qlocal qualifies as (one of) the `biggest', may be forwarded downstream.  A node must independently
         compute
         called `de-merging'.  As with merging, the route for each sender descriptor being forwarded.
         These routes, obtained from uni-/multicast routing, generally  details of de-
         merging depend upon the (sender host address, DestAddress) pairs service and
         consist of a list of outgoing interfaces.  The descriptors
         being forwarded through the same outgoing interface may be
         packed into as few PATH messages as possible.  Note FLOWSPEC format, and
         are outside RSVP itself.

         A RERR message that
         multicast routing of path information is based on forwarded should carry the sender
         address(es) FILTER_SPEC
         from the sender descriptors, not corresponding reservation state (thus `de-merging' the IP source
         address; this is necessary to prevent routing loops; see
         Section 4.3.

         Multicast routing may also report
         filter spec).

         When a RERR or RACK message reaches a receiver, the expected incoming
         interface (i.e., STYLE
         object, flow descriptor list, and ERROR_SPEC object (which
         contains the shortest path back LUB-Used flag) should be delivered to the sender).  If so,
         any PATH message receiver
         application.  In the case of an Admission Control error, the
         flow descriptor list will contain the FLOWSPEC object that arrives on a different interface
         failed.  If the LUB-Used flag is off, this should be discarded immediately.

         It is possible that routing will report no routes for a
         (sender, DestAddress) pair;
         semantically equivalent (but not necessarily identical) to the
         FLOWSPEC originated by this application; otherwise, they may
         differ.

      3.1.6 Teardown Messages

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

         o    A PTEAR message deletes 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 senders, along (which in turn deletes
              the reverse paths of data flow reservation state for that sender, if there is any)
              and travels towards all receivers that are downstream from
              the session.  The IP destination address point of a RESV initiation.  A PTEAR message is
         the unicast address of routed like a previous-hop node, obtained from the
         path state.  The
              PATH message, and its IP source destination address is an address of the node
         that sent the message.  The NHOP (i.e.,
              DestAddress for the RSVP_HOP) object
         must contain session.

         o    A RTEAR message deletes reservation state and travels
              towards all matching senders upstream from the IP address point of the (incoming) interface through
         which the RESV
              teardown initiation.  A RTEAR message is sent.

         The routed in the
              same way as a corresponding RESV message format is as follows:

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

                                     [ <INTEGRITY> ] [ <TIME_VALUES> ]

                                     [ <S_POLICY_DATA> ] [ <SCOPE> ]

                                     <STYLE> <flow descriptor list>

           <S_POLICY_DATA> ::=  <POLICY DATA>

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

                              <flow descriptor list>  <flow descriptor>

         Here (using the S_POLICY_DATA object is a POLICY_DATA object that same
              scope rules).  Its IP destination address is
         associated with the session, i.e., with all the flows that may
         be listed.  There may also be flow-specific POLICY_DATA
         objects, as described below.

         The BNF above defines a flow descriptor list as simply a list
         of flow descriptors.  The following style-dependent rules
         specify more exactly the composition of a valid flow descriptor
         list.

         o    WF Style:

                <flow descriptor list> unicast
              address of a previous hop.

             <PathTear Message> ::=  <WF flow <Common Header> <SESSION> <RSVP_HOP>
                                         [ <INTEGRITY> ]

                                         <sender descriptor>

                <WF flow

             <sender descriptor> ::=

                              <FLOWSPEC> (see earlier definition)

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

                                         [ <F_POLICY_DATA> <INTEGRITY> ] <FILTER_SPEC>

                <F_POLICY_DATA> ::=  <POLICY_DATA>

         o    FF style: [ <SCOPE> ]

                                         <STYLE> <flow descriptor list> ::=   <FF flow descriptor>  |

             <flow descriptor list> <FF flow descriptor>

                <FF flow descriptor> ::=

                          [ <FLOWSPEC> ] [ <F_POLICY_DATA> ] <FILTER_SPEC>

              Each elementary FF style request is defined by a single
              (FLOWSPEC, FILTER_SPEC) pair, and multiple such requests
              may be packed into (see earlier definition)

         FLOWSPEC or POLICY_DATA objects in the flow descriptor list of
         a single
              RESV message.  A FLOWSPEC or POLICY_DATA object can RTEAR message will be
              omitted if ignored and may be omitted.

         Note that, unless it is identical to the most recent such object
              that appeared in accidentally dropped along the list.

         o    SE style:

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

                             | <flow descriptor list> <SE flow descriptor>

                <SE flow descriptor> ::=

                         <FLOWSPEC> [ <F_POLICY_DATA> ] <filter spec list>

                <filter spec list> ::=  <FILTER_SPEC>

                                  |  <filter spec list> <FILTER_SPEC>

              Each elementary SE style request is defined by a single SE
              descriptor, which includes way, a FLOWSPEC defining
         PTEAR message will reach all the shared
              reservation, possibly a POLICY_DATA object, and receivers down stream from its
         origination.  On the other hand, a list RTEAR message will cease to
         be forwarded at the same node where merging suppresses
         forwarding of
              FILTER_SPEC objects.  Multiple elementary requests, the corresponding RESV messages.  In each
              representing an independent shared reservation, node N
         along the way, if the RTEAR message causes the removal of all
         state for this session, N will create a new teardown message to
         be propagated further upstream; otherwise, the RTEAR message
         may be
              packed into result in the flow descriptor list immediate forwarding of a single modified RESV
         refresh message.  A POLICY_DATA object

         Deletion of path state as the result of a PTEAR message or a
         timeout may be omitted if it is
              identical force adjustments in related reservation state, to the most recent such object that appeared
         maintain state consistency in the list. local node.  The adjustment
         in reservation scope, i.e., state depends upon the set of style.  For example,
         suppose a PTEAR deletes the path state for a sender hosts towards
         which S.  If the
         style specifies explicit sender selection (FF or SE), delete
         any reservation with a particular filter spec matching S; otherwise, the
         style is wildcard sender selection (WF) and the reservation
         should be deleted if S is the last sender to the session.
         These reservation changes should not trigger an immediate RESV
         refresh message, since the PTEAR message have already made the
         required changes upstream.  However, at the node in which a
         RTEAR message stops, the change of reservation state may
         trigger a RESV refresh starting at that node.

   3.2 Sending RSVP Messages

      RSVP messages are sent hop-by-hop between RSVP-capable routers as
      "raw" IP packets with protocol number 46.  Raw IP packets are
      intended to be forwarded, used between an end system and the first/last hop
      router, although it is
         determined also possible to encapsulate RSVP messages
      as follows:

         o    For a style UDP datagrams for end-system communication, as described in
      Appendix C.  UDP encapsulation is needed for systems that cannot
      do raw network I/O.

      PATH, PTEAR, and RACK messages must be sent with explicit scope, match each FILTER_SPEC
              object against the Router Alert
      IP option [Katz95] in their IP headers.  This option may be used
      by in the fast forwarding path state created from SENDER_TEMPLATE
              objects to select a particular sender.  It is an error if of a FILTER_SPEC matches more than one SENDER_TEMPLATE, due high-speed router to wildcarding.  A SCOPE object, if present, should be
              ignored.

         o    For a style with wildcard scope, detect
      datagrams that require special processing.

      Upon the arrival of an RSVP message M that changes the state, a SCOPE object, if
              present, defines
      node must forward the scope with modified state immediately.  However, this
      must not trigger sending an explicit list of sender
              IP addresses (see Section 4.3 below).  If there is no
              SCOPE object, message out the scope is determined by interface through
      which M arrived (as could happen if the relevant set implementation simply
      triggered an immediate refresh of senders in all state for the path state.  A SCOPE object session).
      This rule is necessary to prevent packet storms on broadcast LANs.

      An RSVP message must be sent
              in any wildcard scope RESV message that is forwarded fragmented when necessary to
              more than one previous hop.  See Section 4.3 below.

      4.1.5 Error Messages

         There are two types fit into the
      MTU of RSVP error messages.

         o    PERR messages result from PATH messages and travel towards
              senders.  PERR messages are routed hop-by-hop using the
              path state; at each hop, interface through which it will be sent.  All fragments
      of the IP destination address is message should carry the
              unicast address same unique value of a previous hop.

         o    RERR messages result from RESV messages and travel towards the Message
      ID field, as well as appropriate Fragment Offset and MF bits, in
      their common headers.  When an RSVP message arrives, it must be
      reassembled before it can be processed.  The refresh period R can
      be used as an appropriate receivers.   They reassembly timeout time.

      Since RSVP messages are routed hop-by-hop normally generated and sent hop-by-hop,
      using the reservation state; RSVP-level fragmentation mechanism should avoid further
      fragmentation at each hop, the IP
              destination address is the unicast address of a next-hop
              node.

         Errors encountered while processing error level.  However, IP fragmentation may
      still occur when RSVP messages must not
         create further error messages.

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

                                       [ <INTEGRITY> ]  <ERROR_SPEC>

                                       <sender descriptor>

           <sender descriptor> ::= (see earlier definition)
           <ResvErr Message> ::= <Common Header> <SESSION>

                                       [ <INTEGRITY> ]  [S_POLICY_DATA]

                                       <ERROR_SPEC>

                                      <STYLE> <error flow descriptor>

         The following style-dependent rules define the composition of travel through a
         valid error flow descriptor in terms non-RSVP cloud.
      In case of sequences defined
         earlier:

         o    WF Style:

                  <error flow descriptor> ::= <WF flow descriptor>

         o    FF style:

                  <error flow descriptor> ::= <FF flow descriptor>

         o    SE style:

                  <error flow descriptor> ::= <SE flow descriptor>

         POLICY_DATA objects need be included in error messages only for
         information when they are relevant (i.e., when an
         administrative failure is being reported).

         The ERROR_SPEC object specifies the error and includes the IP6, which does not support IP
         address of the node that detected the error (Error Node
         Address).

         When a PATH fragmentation at
      routers, an RSVP implementation must use Path MTU Discovery or RESV message has been "packed" with multiple
         sets
      hand configuration to obtain an appropriate MTU between adjacent
      RSVP neighbors.

      RSVP recovers from occasional packet losses by its periodic
      refresh mechanism.  Under network overload, however, substantial
      losses of RSVP messages could cause a failure of elementary parameters, resource
      reservations.  To control the RSVP implementation should
         process each set independently queueing delay and return a separate error
         message for each that is in error.

         In general, error messages dropping of RSVP
      packets, routers should be delivered configured to offer them a preferred
      class of service.  If RSVP packets experience noticeable losses
      when crossing a congested non-RSVP cloud, a larger value can be
      used for the
         applications on all the session nodes timeout factor K (see section 3.5 below).

      Some multicast routing protocols provide for "multicast tunnels",
      which encapsulate multicast packets for transmission through
      routers that (may have)
         contributed to this error. do not have multicast capability.  A PERR message multicast tunnel
      looks like a logical outgoing interface that is forwarded to all
         previous hops for all senders listed in the Sender Descriptor
         List. mapped into some
      physical interface.  A RERR message is generally forwarded towards all
         receivers that may have caused the error being reported.  More
         specifically:

         o    The node multicast routing protocol that detects an error in supports
      tunnels will describe a reservation request
              creates and sends an RERR message to the next hop from
              which the erroneous reservation came.

              The message must contain the information required to
              define the error and to route the error message.  Routing
              requires at least a STYLE object and one or more
              FILTER_SPEC object(s) from the erroneous RESV message.
              For an admission control failure, for example, the
              erroneous FLOWSPEC must be included.

         o    Succeeding nodes forward the RERR message using their
              local reservation state, to the next hops a list of reservations
              that match the FILTER_SPEC(s) logical rather than
      physical interfaces.  RSVP can run through multicast tunnels in
      the message.  For
              reservations with wildcard scope, there is an additional
              limitation on forwarding RERR messages, to avoid loops;
              see Section 4.3. following manner:

      1.   When the error is an admission control failure, a node is
         allowed (but not required) to match the FLOWSPEC as well as the
         FILTER_SPEC object(s), to limit the distribution of N forwards a RERR PATH message to those receivers that `caused' the error.  Suppose
         that out a RERR logical outgoing
           interface L, it includes in the message contains a FLOWSPEC Qerr that is being
         matched against some encoding of the FLOWSPEC Qlocal in
           identity of L, called the local reservation
         state "logical interface handle" or LIH.
           The LIH value is carried in the RSVP_HOP object.

      2.   The next hop node N.  Qerr, which originated N' stores the LIH value in its path state.

      3.   When N' sends a node upstream
         from RESV message to N, resulted it includes the LIH value
           from merging of flowspecs that included
         Qlocal.  Generally, a RERR the path state (again, in the RSVP_HOP object).

      4.   When the RESV message can be forwarded arrives at N, its LIH value provides
           the information necessary to attach the
         receiver(s) reservation to the
           appropriate logical interface.  Note that specified N creates and
           interprets the `biggest' flowspec.  The
         comparison of Qerr against a particular Qlocal LIH; it is an opaque value to determine
         whether Qlocal qualifies as (one of) the `biggest', may be
         called `de-merging'.  As with merging, N'.

   3.3 Avoiding RSVP Message Loops

      Forwarding of RSVP messages must avoid looping.  In steady state,
      PATH and RESV messages are forwarded only once per refresh period
      on each hop.  This avoids looping packets, but there is still the  details
      possibility of de-
         merging depend upon an " auto-refresh" loop, clocked by the service and refresh
      period.  Such auto-refresh loops keep state active "forever", even
      if the FLOWSPEC format, and
         are outside RSVP itself.

         A RERR message that is forwarded should carry end nodes have ceased refreshing it, until either the FILTER_SPEC
         from
      receivers leave the corresponding reservation state (thus `un-merging' multicast group and/or the
         filter spec).

         When a RERR message reaches a receiver, senders stop
      sending PATH messages.  On the STYLE object, flow
         descriptor list, other hand, error and ERROR_SPEC object (which contains teardown
      messages are forwarded immediately and are therefore subject to
      looping.

      Consider each message type.

      o    PATH Messages

           PATH messages are forwarded in exactly the
         LUB-Used flag) same way as IP
           data packets.  Therefore there should be delivered to the receiver application.
         In the case no loops of an Admission Control error, the flow descriptor
         list will contain the FLOWSPEC object that failed.  If PATH
           messages, even in a topology with cycles.

      o    PTEAR Messages

           PTEAR messages use the
         LUB-Used flag is off, this should be `equal' to (but same routing as PATH messages and
           therefore cannot loop.

      o    PERR Messages
           Since PATH messages do not
         necessarily identical to) the FLOWSPEC originated by this
         application; otherwise, loop, they may differ.

      4.1.6 Teardown Messages

         There create path state
           defining a loop-free reverse path to each sender.  PERR
           messages are two types of RSVP Teardown message, PTEAR always directed to particular senders and RTEAR.
           therefore cannot loop.

      o    RESV Messages

           RESV messages directed to particular senders (i.e., with
           explicit sender selection) cannot loop.  However, RESV
           messages with wildcard sender selection (WF style) have a
           potential for auto-refresh looping.

      o    A PTEAR message deletes path state (which may, in turn,
              delete reservation state) and travels towards all
              receivers that    RTEAR Messages

           Although RTEAR messages are downstream from the point of
              initiation.  A PTEAR message is routed like the same as RESV messages,
           during the second pass around a PATH
              message, and its IP destination address loop there will be no state
           so any RTEAR message will be dropped.  Hence there is DestAddress no
           looping problem here.

      o    RERR Messages

           RERR messages for WF style reservations may loop for
           essentially the session. same reasons that RESV messages loop.

      o    A RTEAR message deletes reservation state and travels    RACK Messages

           RACK messages are forwarded towards all matching senders upstream from a fixed unicast receiver
           address and cannot loop.

      If the point topology has no loops, then looping of
              teardown initiation.  A RTEAR message "wildcard" RESV and
      RERR messages, i.e., messages with wildcard sender selection, can
      be avoided by simply enforcing the rule given earlier: state that
      is routed like received through a
              corresponding RESV message (using particular interface must never be forwarded
      out the same scope rules).
              Its IP destination address is interface.  However, when the unicast address topology does have
      cycles, further effort is needed to prevent auto-refresh loops 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> ] [ <SCOPE> ]

                                         <STYLE> <flow descriptor list>

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

         FLOWSPEC or POLICY_DATA objects in the flow descriptor
      wildcard RESV messages and fast loops of wildcard RERR messages.
      The solution to this problem adopted by this protocol
      specification is for such messages to carry an explicit sender
      address list of in a RTEAR SCOPE object.

      When a RESV message will be ignored and may with WF style is to be omitted.

         Note forwarded to a
      particular previous hop, a new SCOPE object is computed from the
      SCOPE objects that were received in matching RESV messages.  If
      the computed SCOPE object is empty, the RTEAR message will cease to be is not forwarded at
      to the
         same node where merging suppresses forwarding of previous hop; otherwise, the
         corresponding RESV messages. message is sent containing the
      new SCOPE object.  The change will be propagated as rules for computing a new teardown message if the result has been to remove all
         state SCOPE object for this session at this node; otherwise, it may result
         in the immediate forwarding of
      a modified RESV refresh message.

         Deletion of path state, whether message are as the result follows:

      1.   The union is formed of a teardown
         message or because the sets of timeout, may force adjustments sender IP addresses listed
           in related
         reservation state to maintain consistency all SCOPE objects in the local node.

         The adjustment in reservation state depends upon the style.
         For example, suppose a PTEAR deletes for the path given
           session.

           If reservation state for from some NHOP does not contain a SCOPE
           object, a substitute sender S.  If the style specifies distinct reservations (FF),
         only reservations for sender S should list must be deleted; if the style
         specifies shared reservations (WF or SE), delete the
         reservation if this was the last filter spec.  These
         reservation changes should not trigger an immediate RESV
         refresh message, since the teardown message will have already
         made the required changes upstream.  However, at the node created and included
           in
         which the union.  For a RTEAR message stops, that arrived on outgoing
           interface OI, the change substitute list is the set of reservation state
         may trigger a RESV refresh starting at senders 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
           route to OI.

      2.   Any local senders (i.e., any sender applications on this
           node) are
      similarly intended removed from this set.

      3.   If the SCOPE object is to be used between sent to PHOP, remove from the
           set any senders that did not come from PHOP.

      Figure 11 shows an end system and example of wildcard-scoped (WF style) RESV
      messages.  The address lists within SCOPE objects are shown in
      square brackets.  Note that there may be additional connections
      among the
      first/last hop router; however, it nodes, creating looping topology that is also possible to encapsulate
      RSVP messages as UDP datagrams for end-system communication, as
      described 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 11: SCOPE Objects in Appendix C.  UDP encapsulation Wildcard-Scope Reservations

      SCOPE objects are not necessary if the multicast routing uses
      shared trees or if the reservation style has explicit sender
      selection.  Furthermore, attaching a SCOPE object to a reservation
      may simplify
      installation of RSVP on current end systems, particularly when
      firewalls be deferred to a node which has more than one previous hop
      upstream.

      The following rules are used for SCOPE objects in use.

      Upon RERR messages
      with WF style:

      1.   The node that detected the arrival of error initiates an RSVP RERR message M that changes the state,
           containing a
      node must forward the modified state immediatly.  If this is
      implemented as an immediate refresh copy of all the state for the
      session, then no refresh messages should be sent out SCOPE object associated with the interface
      through which M arrived.  This rule is necessary to prevent packet
      storms on broadcast LANs.

      An RSVP
           reservation state or message must be fragmented when necessary to fit into the
      MTU of in error.

      2.   Suppose a wildcard-scoped RERR message arrives at a node with
           a SCOPE object containing the interface through which it will be sent.  All fragments
      of sender host address list L.
           The node forwards the RERR message should carry using the same unique value rules of Section
           3.1.5.  However, the Message
      ID field, as well as appropriate Fragment Offset and MF bits, in
      their common headers.  When an RSVP RERR message arrives, it forwarded out OI must be
      reassembled before it can be processed.  The refresh period R is
      appropriate as a ressembly timeout time.

      Since RSVP messages are normally expected to be generated and sent
      hop-by-hop, using the RSVP-level fragmentation mechanism should
      result in no IP fragmentation.  However, IP fragmentation may
      occur through
           contain a non-RSVP cloud.  For IP6, which does not support
      router fragmentation, this case will require SCOPE object derived from L by including only those
           senders that the RSVP
      implementation use Path MTU Discovery or hand configuration route to
      obtain an appropriate MTU.

      Under overload conditions, lost RSVP control messages could cause
      a failure of resource reservations.  Routers OI.  If this SCOPE object is empty, the
           RERR message should not be configured
      to give sent out OI.

   3.4 Local Repair

      When a preferred class of service route changes, the next PATH or RESV refresh message will
      establish path or reservation state (respectively) along the new
      route.  To provide fast adaptation to RSVP packets.  RSVP should
      not use significant bandwidth, but queueing delay and dropping routing changes without the
      overhead of short refresh periods, the local routing protocol
      module can notify the RSVP messages needs to be controlled.   Loss daemon of RSVP packets
      through a congested non-RSVP cloud may still be a problem.  The
      simplest solution is to adopt a larger value route changes for the timeout
      factor K (see section 4.5 below).  If this does not suffice,
      neighboring particular
      destinations.  The RSVP routers could daemon should use a TCP connection this information to pass RSVP
      messages through
      trigger a non-RSVP cloud.  The current protocol contains
      no automatic mechanism to setting up such connections; hand
      configuration is assumed.

      Some multicast routing protocols provide for "multicast tunnels",
      which encapsulate multicast packets quick refresh of state 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 these destinations, using a list of logical rather than
      physical interfaces.  RSVP can support multicast tunnels in the
      following manner:

      1.
      new route.

      More specifically, the rules are as follows:

      o    When routing detects a node N forwards a PATH message out a logical outgoing
           interface L, it includes in the message some encoding change of the
           identity set of L.  This information outgoing
           interfaces for destination G, RSVP should wait for a short
           period W, and then send PATH refreshes for all sessions G/*
           (i.e., for any session with destination G, regardless of
           destination port).

           The short wait period before sending PATH refreshes is carried (in to
           allow the HOP
           object) as a value called routing protocol getting settled with the "logical interface handle" or
           LIH.

      2.   The next hop node N' stores new
           change(s), and the LIH exact value in its path state.

      3. for W should be chosen
           accordingly.  Currently W = 2 sec is suggested; however, this
           value should be configurable per interface.

      o    When N' sends a RESV PATH message to N, it includes the LIH value arrives with a Previous Hop address that
           differs from the path state (again, one stored in the HOP object).

      4.   When the path state, RSVP should
           send immediate RESV message arrives at N, its LIH value provides
           the information necessary to attach the reservation to the
           appropriate logical interface.  Note refreshes for that N creates and
           interprets the LIH; it is an opaque value session.

   3.5 Time Parameters

      There are two time parameters relevant to N'.

   4.3 Avoiding each element of RSVP Message Loops

      We must ensure that
      path or reservation state in a node: the rules for forwarding RSVP control messages
      avoid looping.  In steady state, PATH and RESV messages are
      forwarded only once per refresh period on each hop.  This avoids
      directly looping packets, but there is still the possibility R between
      generation of an
      " auto-refresh" loop, clocked successive refreshes for the state by the refresh period.  The effect
      of such neighbor
      node, and the local state's lifetime L.  Each RSVP RESV or PATH
      message may contain a loop TIME_VALUES object specifying the R value
      that was used to generate this (refresh) message.  This R value is
      then used to keep state active "forever", even if the end
      nodes have ceased refreshing it (but determine the state will be deleted value for L when the receivers leave the multicast group and/or the senders
      stop sending PATH messages).  On the other hand, error state is received
      and
      teardown messages are forwarded immediately stored.  The values for R and are therefore
      subject L may vary from hop to direct looping.

      o    PATH Messages

           PATH hop.

      In more detail:

      1.   Floyd and Jacobson [FJ94] have shown that periodic messages are forwarded using routes determined
           generated by independent network nodes can become
           synchronized.  This can lead to disruption in network
           services as the
           appropriate routing protocol.  For routing periodic messages contend with other network
           traffic for link and forwarding resources.  Since RSVP sends
           periodic refresh messages, it must avoid message
           synchronization and ensure that any synchronization that may
           occur is source-
           dependent (e.g., some multicast routing algorithms), not stable.

           For this reason, the RSVP
           daemon must route each sender descriptor separately using refresh timer should be randomly set to
           a value in the
           source addresses found range [0.5R, 1.5R].

      2.   To avoid premature loss of state, L must satisfy L >= (K +
           0.5)*1.5*R, where K is a small integer.  Then in the SENDER_TEMPLATE objects.  This
           should ensure that there will worst
           case, K-1 successive messages may be lost without state being
           deleted.  To compute a lifetime L for a collection of state
           with different R values R0, R1, ..., replace R by max(Ri).

           Currently K = 3 is suggested as the default.  However, it may
           be no auto-refresh loops of
           PATH messages, even in necessary to set a topology larger K value for hops with cycles.

           Consider each high loss
           rate.  K may be set either by manual configuration per
           interface, or by some adaptive technique that has not yet
           been specified.

      3.   Each message type.

      o    PTEAR Messages

           PTEAR messages use the same routing as PATH messages and
           therefore cannot loop.

      o    PERR Messages

           Since PATH messages don't loop, they create path that creates state
           defining (PATH or RESV message)
           carries a loop-free reverse path to each sender.  PERR
           messages are always directed TIME_VALUES object containing the R used to particular senders and
           therefore cannot loop.

      o    RESV Messages

           Like PERR message, RESV messages directed
           generate refreshes; the recipient node uses this R to particular
           senders (i.e., with explicit scope) cannot loop.  However,
           there is a potential for auto-refresh
           determine L of RESV messages with
           wildcard scope; the solution stored state.

      4.   R is presented below.

      o    RTEAR Messages

           RTEAR messages are routed chosen locally by each node.  If the same as RESV messages and have
           an analogous looping problem for wildcard scope.

      o    RERR Messages

           RERR messages for wildcard scope node does not
           implement local repair of reservations have disrupted by route
           changes, a smaller R speeds up adaptation to routing changes,
           while increasing the same
           potential for looping as RSVP overhead.  With local repair, a
           router can be more relaxed about R since the reservations themselves, and periodic refresh
           becomes only a backstop robustness mechanism.  A node may
           therefore adjust the
           solution presented below effective R dynamically to control the
           amount of overhead due to refresh messages.

           The current suggested default for R is 30 seconds.  However,
           the default should be configurable per interface.

      5.   When R is required.

      If changed dynamically, there is a limit to how fast
           it may increase.  Specifically, the topology has no loops, then looping ratio of wildcard-scoped
      messages can two successive
           values R2/R1 must not exceed 1 + Slew.Max.

           Currently, Slew.Max is 0.30.  With K = 3, one packet may be avoided by simply enforcing the rule given
      earlier:
           lost without state that timeout while R is received through increasing 30 percent
           per refresh cycle.

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

      7.   The values of Rdef, K, and Slew.Max used in an implementation
           should be forwarded out the same interface.  However, when the
      topology does have cycles then further effort is needed easily modifiable per interface, as experience may
           lead to prevent
      auto-refresh loops in wildcard-scope RESV, RTEAR, and RERR
      messages. different values.  The solution possibility of dynamically
           adapting K and/or Slew.Max in response to measured loss rates
           is for such messages future study.

   3.6 Traffic Policing and TTL

      RSVP is required to carry an explicit
      sender address list in a SCOPE object.

      When compute and pass several service-related flags
      to traffic control: policing flags and a RESV non-RSVP flag.

      Some QoS services may require traffic policing at some or RTEAR message with wildcard scope is all of
      (1) the edge of the network, (2) a merging point for data from
      multiple senders, and/or (3) a branch point where traffic flow
      from upstream may be greater than the downstream reservation.
      RSVP knows where such points occur and must so indicate to the
      traffic control mechanism.  On the other hand, RSVP does not
      interpret the service embodied in the flowspec and therefore does
      not know whether policing will actually be
      forwarded to a applied in any
      particular previous hop, case.

      The RSVP daemon passes to traffic control a new SCOPE object separate policing flag
      for each of these three situations.

      o    E_Police_Flag -- Entry Policing

           This flag is
      computed from set in the SCOPE objects first-hop RSVP node that were received (in messages implements
           traffic control (and is therefore capable of policing).

           For example, sender hosts must implement RSVP but currently
           many of them do not implement traffic control.  In this case,
           the same type).  If E_Police_Flag should be off in the computed SCOPE object is empty, sender host, and it
           should only be set on when the
      message first hop capable of traffic
           control is not forwarded to the previous hop; otherwise, the
      message reached.  This is sent containing controlled by the new SCOPE object.  The rules E_Police flag
           in SESSION objects.

      o    M_Police_Flag -- Merge Policing

           This flag should be set on for
      computing a new SCOPE object for reservation using a RESV shared
           style (WF or RTEAR message are as
      follows:

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

           If reservation state SE) when flows from some NHOP does not contain a SCOPE
           object, a substitute more than one sender list must are
           being merged.

      o    B_Police_Flag -- Branch Policing

           This flag should be created and included
           in set on when the union.  For flowspec being installed
           is smaller than, or incomparable to, a wildcard scope (WF) message that arrived
           on outgoing interface OI, FLOWSPEC in place on
           any other interface, for the substitute list is same FILTER_SPEC and SESSION.

      RSVP must also detect and report to receivers the set presence of
           senders that route to OI.
      non-RSVP hops in the path.  For this purpose, an explicit scope (SE)
           message, RSVP daemon must
      place into each PATH message that it is sends the set value of senders explicitly listed in the
           message.

      2.   Any local senders (i.e., any sender applications on this
           node) are removed from this set.

      3.   If the SCOPE object is to be sent to PHOP, remove from IP TTL
      with which the
           set any senders that did not come from PHOP.

      Figure 12 shows an example of wildcard-scoped (WF style) RESV
      messages. message was sent.  The address lists within SCOPE objects are shown in
      square brackets.  Note RSVP-capable node that there may be additional connections
      among
      receives this message compares this field to the 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 TTL with which
      the multicast routing uses
      shared trees or message was actually received, and if the reservation style has explicit scope.
      Furthermore, attaching a SCOPE object they differ it turns on
      the Non_RSVP flag.  This flag is carried forward to a reservation may be
      deferred receivers in
      the ADSPEC [??].

   3.7 Multihomed Hosts

      Accommodating multihomed hosts requires some special rules in
      RSVP.  We use the term `multihomed host' to a node which has cover both hosts (end
      systems) with more than one previous hop upstream.

      The following rules network interface [could ref. section
      3.3.4 of RFC-1122], and routers that are used supporting local
      application programs.

      An application executing on a multihomed host may explicitly
      specify which interface any given flow will use for SCOPE objects in wildcard-scoped
      RERR messages:

      1. sending and/or
      for receiving data packets, to override the system-specified
      default interface.  The node that detected RSVP daemon must be aware of the error initiates default,
      and if an RERR message
           containing application sets a copy specific interface, it must also pass
      that information to RSVP.

      o    Sending Data

           A sender application uses an API call (SENDER in Section
           3.9.1) to declare to RSVP the characteristics of the SCOPE object associated with data
           flow it will originate.  This call may optionally include the
           reservation state or message
           local IP address of the sender. If it is set by the
           application, this parameter must be the interface address for
           sending the data packets; otherwise, the system default
           interface is implied.

           The RSVP daemon on the host then sends PATH messages for this
           application out the specified interface (only).

      o    Making Reservations

           A receiver application uses an API call (called RESERVE in error.

      2.   Suppose a wildcard-scoped RERR message arrives at a node with
           Section 3.9.1) to request a SCOPE object containing reservation from RSVP.  This call
           may optionally include the sender host local IP address list L.
           The node forwards of the RERR message using receiver,
           i.e., the interface address for receiving data packets.  In
           the rules case of Section
           4.1.5.  However, multicast sessions, this is the RERR message forwarded out OI must
           contain a SCOPE object derived from L by including only those
           senders that route to OI. interface on
           which the group has been joined.  If this SCOPE object the parameter is empty,
           omitted, the
           RERR message system default interface is used.

           In general, the RSVP daemon should not be sent send RESV messages for
           application out OI.

   4.4 Local Repair

      When the specified interface.  However, when the
           application is executing on a route changes, router and the next PATH or RESV refresh will establish
      path or reservation state (respectively) along session is
           multicast, a more complex situation arises.   Suppose in this
           case that a receiver application joins the new route.  To
      provide fast adaptation to routing changes without group on an
           interface Iapp that differs from Isp, the overhead of
      short refresh periods, shortest-path
           interface to the local sender.  Then there are two possible ways
           for multicast routing protocol module can
      notify to deliver data packets to the RSVP daemon of route changes for particular
      destinations.
           application.  The RSVP daemon should use this information must determine which case holds
           by examining the path state, to
      trigger an immediate refresh of state decide which incoming
           interface to use for these destinations,
      using the new route.

      More specifically, the rules are as follows:

      o    When sending RESV messages.

           1.   The multicast routing detects protocol may create a change separate
                branch of the set of outgoing
           interfaces for sending PATH messages for destination G, RSVP
           sends immediate PATH refreshes for all sessions G/* (i.e.,
           for any session with destination G, regardless of destination
           port).  Such refresh messages are multicast distribution `tree' to be sent deliver
                to at least the
           new outgoing interfaces Iapp.  In this case, there will be path state for these sessions.

      o    When a PATH message arrives with
                both Isp and Iapp.  The path state on Iapp should only
                match a Previous Hop address that
           differs reservation from the one stored in local application; it must
                be marked "Local_only" by the path state, RSVP should
           send immediate RESV refreshes daemon.  If
                "Local_only" path state for Iapp exists, the RESV
                message should be sent out Iapp.

                Note that session.

   4.5 Time Parameters

      There are two time parameters relevant to each element of RSVP it is possible for the path or reservation state blocks for
                Isp and Iapp to have the same next hop, if there is an
                intervening non-RSVP cloud.

           2.   The multicast routing protocol may forward data within
                the router from Isp to Iapp.  In this case, Iapp will
                appear in a node: the refresh period R between
      receiving successive refreshes for list of outgoing interfaces of the state, path
                state for Isp, and its lifetime L.
      Each RSVP the RESV or PATH message should be sent out
                Isp.

   3.8 Future Compatibility

      We may contain a TIME_VALUES expect that in the future new object
      specifying C-Types will be
      defined for existing object classes, and perhaps new object
      classes will be defined.  It will be desirable to employ such new
      objects within the R value Internet using older implementations that was used do
      not recognize them.  Unfortunately, this is only possible to generate a
      limited degree with reasonable complexity.  The rules are as
      follows.

      1.   Unknown Class

           There are two possible ways that an RSVP implementation can
           treat an object with unknown class.  This choice is
           determined by the high-order bit of the Class-Num octet, as
           follows.

           o    Class-Num >= 128

                In this refresh
      message; case, the entire message should be rejected and
                an "Unknown Object Class" error returned.

           o    Class-Num < 128

                In this is used to determine case, the L when node should ignore the state is
      received object but
                forward it, unexamined and stored.

      In more detail:

      1.   To avoid premature loss of state, we require that L >= (K +
           0.5)* R, where K is a small integer.  Then K-1 successive unmodified, in all messages may be lost without
                resulting from the state being deleted.  Currently
           K = 3 is suggested.

      2.   Each message will generally carry contained in this message.

                For example, suppose that a TIME_VALUES RESV message that is
                received contains an object
           containing the R used to generate refreshes; the recipient
           node uses this R to determine L of unknown class.  Such an
                object should be saved in the stored state.

           However, if a default R = Rdef is used, reservation state without
                further examination; however, only the TIME_VALUES latest object may
                with a given (unknown class, C-Type) pair should be omitted from
                saved.  When a message.  Rdef RESV message is currently
           defined forwarded, it should
                include copies of such saved unknown-class objects from
                all reservations that are merged to be 30 seconds.

      3.   This document does not specify form the interval R to new RESV
                message.

                Note that objects with unknown class cannot be used for
           generating refresh messages.  If the merged;
                however, unmerged objects may be forwarded until they
                reach a node does not implement
           local repair that knows how to merge them.  Forwarding
                objects with unknown class enables incremental
                deployment of reservations disrupted by route changes, a
           smaller R improves new objects; however, the speed scaling
                limitations of adapting to routing changes
           (but increases overhead).  With local repair, doing so must be carefully examined
                before a router can new object class is deployed with Class-Num <
                128.

           These rules should be
           more relaxed about R since the periodic refresh becomes only
           a backstop robustness mechanism.  A node may therefore adjust
           the effective R dynamically to limit considered when any new Class-Num is
           defined.

      2.   Unknown C-Type for Known Class

           One might expect the overhead due known Class-Num to
           refresh messages.

      4.   The TIME_VALUES object provide information
           that could contain, in addition to the
           hop-by-hop R value, allow intelligent handling of such an end-to-end upper bound on R, called
           Rmax.  When Rmax is specified, a node cannot set R > Rmax. object.
           However, a node in practice such class-dependent handling is allowed to refuse
           complex, and in many cases it is not useful.

           Generally, the appearance of an RSVP object with unknown C-Type
           should result in rejection of the entire message (i.e.,
           drop it and return an error) when it specifies
           generation of an Rmax value error message (RERR or PERR as appropriate).
           The error message will include the Class-Num and C-Type that is so small
           failed (see Appendix B); the end system that it would create unacceptable overhead.
           This refusal would look like a kind of admission control
           failure.

      5.   However, when R is changed dynamically, there is a limit to
           how fast it may increase.  Specifically, originated the ratio of two
           successive values R2/R1 must not exceed 1 + Slew.Max.

           Currently, Slew.Max is 0.30.  With K = 3, one packet
           failed message may be
           lost without state timeout while R is increasing 30 percent
           per refresh cycle.

      6.   To improve robustness, able to use this information to retry
           the request using a node different C-Type object, repeating this
           process until it runs out of alternatives or succeeds.

           Objects of certain classes (FLOWSPEC, ADSPEC, and
           POLICY_DATA) are opaque to RSVP, which simply hands them to
           traffic control or policy modules.  Depending upon its
           internal rules, either of the latter modules may temporarily send refreshes
           more often than R after reject a state change (including initial
           state establishment).

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

      8.   The values of Rdef, K, inform the RSVP daemon; RSVP should then reject the
           message and Slew.Max used in send an implementation
           should be easily modifiable, error, as experience may lead to
           different values.  The possibility of dynamically changing K
           and/or Slew.Max described in response to measured loss rates is for
           future study.

   4.6 the previous
           paragraph.

   3.9 RSVP Interfaces

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

      4.6.1

      3.9.1 Application/RSVP Interface

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

         o    Register Session

              Call: REGISTER( SESSION( DestAddress , DestPort

                         [ , SESSION_object ]  , SND_flag , RCV_flag

                         [ , Source_Address ]  [ , Source_Port ]

                         [ , Source_ProtID ]  [ , Sender_Template ]

                         [ , Sender_Tspec ]   [ ProtocolId, DstPort , Data_TTL ]

                         [ , Sender_Policy_Data SESSION_object ]

                         [ , Upcall_Proc_addr ] )  -> Session-id

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

              The Upcall_Proc_addr parameter defines the address of an
              upcall procedure to receive asynchronous error or event
              notification; see below.  The SESSION_object parameter is
              included as an escape mechanism to support some more
              general definition of the session ("generalized
              destination port"), should that be necessary in the
              future.  Normally SESSION_object will be
              omitted; if it is supplied, it should be an
              appropriately-formatted representation of a SESSION
              object.

              SND_flag should be set true if omitted.

         o    Define Sender

              Call: SENDER( Session-id,

                         [ , Source_Address ]  [ , Source_Port ]

                         [ , Sender_Template ]

                         [ , Sender_Tspec ]   [ , Data_TTL ]

                         [ , Sender_Policy_Data ] )
              A sender uses this call to define, or to modify the host will send data,
              and RCV_flag should be set true if
              definition of, the attributes of 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 stream.  The
              first SENDER call for the session registered as `Session-
              id' will cause RSVP to begin sending PATH messages for
              this session using
              these parameters, which session; later calls will modify the path
              information.

              The SENDER parameters 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. omitted.

              -    Sender_Tspec

                   This optional parameter is a Tspec describing describes 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, [ receiver_address , ]

                        [ ACK_flag, ] style, style-dependent-parms )

              A receiver uses this call to make or to modify 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 existing reservations may result in
              admission control failure, depending failure).

              The optional `receiver_address' parameter may be used by a
              receiver on a multihomed host (or router); it is the IP
              address of one of the node's interfaces.  The ACK_flag
              should be set on if a reservation ACK is desired, off
              otherwise.  The `style' parameter indicates the
              reservation style.  The rest of the parameters depend upon
              the style). style, but generally these will include appropriate
              flowspecs, filter specs, and possibly receiver policy data
              objects.

              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 removes RSVP state for the session specified by
              session-id.  It may send  The node then sends appropriate teardown
              messages and will cease ceases sending refreshes for this session-id.

         o    Error/Event Upcalls

              Upcall: <Upcall_Proc>( ) -> session-id, Info_type,

                            [ Error_code , Error_value ,

                                 Error_Node , 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 SESSION call.

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

              1.   Info_type = Path Event

                   A Path Event upcall indicates results from receipt of the first
                   PATH message for this session, indicating 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  `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 and
                   Policy_data parameters will be undefined in this
                   upcall.

              2.   Info_type = Resv Event

                   A Resv Event upcall is triggered by the receipt of
                   the first reservation message or by modification of a
                   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 a SENDER call.

                   The Error_code parameter will define the error, and
                   Error_value may supply some additional (perhaps
                   system-specific) data about the error.  The
                   Error_Node parameter will specify the IP address of
                   the node that detected the error.

                   `List_count' will be 1, and Filter_spec_list and Flowspec_list will
                   contain the Sender_Template supplied in the
                   REGISTER SENDER
                   call; Sender_Tspec Flow_Spec_list and Advert_list will each
                   contain one NULL object.  The Policy_data parameter
                   will be undefined contain any POLICY_DATA objects in this upcall. the PERR
                   message.

              4.   Info_type = Resv Error Error/Confirmation

                   An Resv Error Error/Confirmation event indicates an error
                   in processing a reservation message to which this application
                   contributed.
                   contributed, or the receipt of a RACK message.  The
                   Error_code parameter will define the error or
                   confirmation.  For an error, and Error_value may supply
                   some additional (perhaps system-specific) data on data.  The
                   Error_Node parameter will specify the error. IP address of
                   the node that detected the event being reported.

                   Filter_spec_list and Flowspec_list will contain the
                   FILTER_SPEC and FLOWSPEC objects from the error flow
                   descriptor (see Section 4.1.5). 3.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  For an error, the Policy_data
                   parameter will be
                   undefined contain any POLICY_DATA objects 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.
                   RERR message.

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

      4.6.2  All error and confirmation events
              should be reported to the application.

      3.9.2 RSVP/Traffic Control Interface

         In each router and host, an RSVP-capable node, 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.

         o    Make a Reservation

              Call: Rhandle =  TC_AddFlowspec( Interface, Flowspec

                                     [ , Sender_Tspec]

                                     , E_Police_Flag , M_Police_Flag TC_Flowspec,

                                     TC_Tspec, E_Police_Flag,

                                     M_Police_Flag, B_Police_Flag )

              This call passes a Flowspec defining a

              The TC_Flowspec parameter defines the desired effective
              QoS to admission control.  It may also pass Sender_Tspec, control; its value is computed as the
              maximum traffic characteristics computed over the
              SENDER_TSPECs flowspecs 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 different next hops (see the
              Compare_Flowspecs call below).  It contains the effective
              reservation style.  These flags are
              used Tspec Resv_Te (although the RSVP daemon itself
              has no means to enable extract the Tspec).  The TC_Tspec
              parameter defines the effective sender Tspec Path_Te (see
              Section 2.3).  We assume that traffic policing or shaping when
              appropriate, in accordance with control takes the service.

              This
              min of Resv_Te and Path_Te (see step (4) in Section 2.3).

              E_Police_Flag, M_Police_Flag, and B_Police_Flag are
              Boolean parameters whose values should be set as described
              in Section 3.6.

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

         o    Modify Reservation

              Call: TC_ModFlowspec( Rhandle, new_Flowspec

                                  [ , Sender_Tspec] , Police_flag new_Flowspec,

                                    Sender_Tspec,  E_Police_flag,

                                     M_Police_Flag, B_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.  The other parameters are defined as in
              TC_AddFlowspec.

         o    Delete Flowspec

              Call: TC_DelFlowspec( Rhandle )

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

         4.

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

         o    Delete Filter Spec

              Call: TC_DelFilter( FHandle )

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

         6.

         o    OPWA Update

              Call: TC_Advertise( interface, Adspec Adspec,

                              [ ,Sender_TSpec , Non_RSVP_flag ] ) -> 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.

         o    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

      3.9.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 Receive Mode for RSVP messages Messages

              Any datagram packet received for IP protocol 46 must be diverted to
              the RSVP program for processing, without being forwarded.  The
              On a router, the identity of the interface interface, real or
              virtual, on which it is received should must also be available to
              the RSVP daemon.

         o    Route Query

              To forward PATH and PTEAR messages, an RSVP daemon must be
              able to query the routing daemon daemon(s) for the
              route(s) for forwarding a specific datagram. routes.

                 Ucast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag )

                                        -> OutInterface

                 Mcast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag )

                                        -> [ IncInterface, ] OutInterface_list

              Depending upon the routing protocol, the query may or may
              not depend upon SrcAddress, i.e., upon the sender host IP
              address, which is also the IP source address of the
              message.  Here IncInterface is the interface through which
              the packet is expected to arrive; some multicast routing
              protocols may not provide it.

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

              A multicast route query may return an empty
              OutInterface_list if there are no receivers downstream of
              a particular router.  A route query may also return a `No
              such route' error, probably as a result of a transient
              inconsistency in the routing (since a PATH or PTEAR
              message for the requested route did arrive at this node).
              In either case, the local state should be updated as
              requested by the message, although it cannot be forwarded
              further.  Updating local state will make path state
              available immediately for a new local receiver, or it will
              tear down path state immediately.

         o    Route Change Notification

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

                 Ucast_Route_Change( ) -> DestAddress, OutInterface

                 Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,

                               [ IncInterface, ] 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 to send different versions of
              an outgoing PATH messages for the same source and
              destination addresses message on different interfaces.  It is
              also necessary in some cases to avoid routing loops.

         o    Discover    Source Address Specification

              RSVP must be able to specify the IP source address to be
              used when sending PATH messages.

         o    Interface List Discovery

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

5.

      3.9.4 Service-Dependent Manipulations

         Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP;
         their contents are defined in service specification documents.
         In order to manipulate these objects, RSVP daemon must have
         available to it the following service-dependent routines.

         o    Compare Flowspecs
                 Compare_Flowspecs( Flowspec_1, Flowspec_2 ) -> result_code

              The possible result_codes indicate: flowspecs are equal,
              Flowspec_1 is greater, Flowspec_2 is greater, flowspecs
              are incomparable but LUB can be computed, or flowspecs are
              incompatible.

              Note that comparing two flowspecs implicitly compares the
              Tspecs that are contained.  Although the RSVP daemon
              cannot itself parse a flowspec to extract the Tspec, it
              can use the Compare_Flowspecs call to implicitly calculate
              Resv_Te (see Section 2.3).

         o    Compute LUB of Flowspecs

                 LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
                   Flowspec_LUB

         o    Compare Tspecs

                 Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code

              The possible result_codes indicate: Tspecs are equal, or
              Tspecs are unequal.

         o    Sum Tspecs

                 Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum

              This call is used to compute Path_Te (see Section 2.3).

4. Message Processing Rules

   This section provides a generic description of the rules for RSVP operation
   operation.  It is intended to outline a set of algorithms that will
   accomplish the needed function.  An actual implementation may use
   different but equivalent algorithms.  This section assumes the
   generic interface calls defined in Section 3.9 and the following data
   structures.  An actual implementation may use additional or different
   data structures and interfaces.

   [NOTE: This section is always the last to optimize processing. be updated when changes are
   made, and it is neither correct nor complete at the present time.
   Therefore, when this section disagrees with the rest of the text, you
   should believe the rest of the text!]

   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.
        respectively, received in a PATH message.

        PSB contents include the following values from a PATH message:

        -    The previous hop IP address from a PHOP object (required)

        -    LIH, the Logical Interface Handle from the previous hop,
             from a PHOP object and possibly
        SENDER_TSPEC, POLICY_DATA, (required).

        -    The remaining IP TTL (required)

        -    SENDER_TSPEC (required)

        -    POLICY_DATA and/or ADSPEC objects from PATH
        messages. (optional)

        -    Non_RSVP flag (required); see Section 3.6.

        In addition, the PSB contains the following information provided
        by routing: OutInterface_list, the list of outgoing interfaces
        for this (sender, destination), and IncInterface, the expected
        incoming interface.  For a unicast destination,
        OutInterface_list contains one entry and IncInterface is
        undefined.

   o    RSB -- Reservation State Block

        Each RSB holds a reservation state for request that arrived in a
        particular 4-tuple: RESV message, corresponding to the triple:  (session,
        next hop, style, filterspec), which are defined in
        SESSION, NHOP, STYLE, and filter_spec_list).  Here "filter_spec_list" may be a
        list of FILTER_SPECs (for SE style), a single FILTER_SPEC objects, respectively. (FF
        style), or empty (WF style).  We use the symbol "FILTER_SPEC*"
        to indicate such a FILTER_SPEC list.

        RSB contents also include a include:

        -    The outgoing (logical) interface OI on which the
             reservation is to be made or has been made (required).

        -    FLOWSPEC*, list of FLOWSPEC objects (required)

        -    The style (required)

        -    A POLICY_DATA object (optional)

        -    A SCOPE object (optional, depending on style)

        -    A RESV_CONFIRM object (optional)

   o    TCSB -- Traffic Control State Block

        TCSB's hold the reservation specifications that have been handed
        to traffic control for specific outgoing interfaces.  In
        general, information in TCSB's is derived from RSB's for the
        same outgoing interface.  Each TCSB defines a single reservation
        for a particular triple: (session, OI, filter_spec_list).   TCSB
        contents include:

        -    TC_Flowspec, the effective flowspec, i.e., the maximum over
             the corresponding FLOWSPEC values from matching RSB's.
             TC_Flowspec is passed to traffic control to make the actual
             reservation.  The Tspec part of TC_Flowspec is the
             effective reservation Tspec Resv_Te (Section 2.3).

        -    TC_Tspec, equal to the effective sender Tspec Path_Te.

        -    Police Flags

             The flags E_Police_Flag, M_Police_Flag,and B_Police_Flag
             are defined in Section 3.6.

        -    Rhandle, F_Handle_list

             Handles returned by the traffic control interface,
             corresponding to the reservation (flowspec) and to the list
             of filter specs.

   Boolean flags Path_Refresh_Needed, Resv_Refresh_Needed, and may include
   Tear_Needed will also be used in this section.

   [LZ: It might be very helpful to have a
        POLICY_DATA object.  We assume that RSB contents include short section to summarize
   the
        outgoing interface OI that is implied by NHOP. management of all the timers.]

   MESSAGE ARRIVES

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

   Reassemble a fragmented message.

   Parse the sequence of objects in the message to verify the length
   field of the common header; discard message if there is a mismatch.

   If the message type is not PATH or PTEAR and if the IP destination
   address does not match any of the addresses of the local interfaces,
   then forward the message to IP destination address and return.

   Verify the INTEGRITY object, if any.  If the check fails, discard the
   message and return.

   Further processing depends upon message type.

   PATH MESSAGE ARRIVES

        Each

        Process the sender descriptor object sequence in the message defines message as
        follows.  The flags Path_Refresh_Needed and Resv_Refresh_Needed
        flags are initially off.

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

        o    If the DstPort in the SESSION object is zero but the
             SrcPort in the SENDER_TEMPLATE object is non-zero, build a
             send a "Conflicting Src Port"  PERR message, drop the PATH
             message, and return.

        o    Search for a path state block (PSB) whose (SESSION,
             SENDER_TEMPLATE) pair matches the corresponding objects in
             the message, considering any wildcard ports.

        o    If, during the PSB search, a PSB is found whose session
             matches the DestAddress and Protocol Id fields of the
             received SESSION object, but the DstPorts differ and one is
             zero, then build and send a "Conflicting Dst Port" PERR
             message, drop the PATH message, and return.

        o    If, during the PSB search, a
        sender.  Process each PSB is found with a matching
             sender as follows, starting host (in SENDER_TEMPLATE) but the
        Path_Refresh_Needed SrcPorts differ
             and Resv_Refresh_Needed flags off.

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

        o    If there was no matching PSB, then:

             1.   Create a new PSB.

             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  Store the values of
                  OutInterface_list and (for a multicast destination) an
             EXPECTED_INTERFACE.

        3.   If IncInterface into the message arrived on an interface different PSB.
                  However, if the sender is from
             EXPECTED_INTERFACE, drop it and return.

        4.   Search for a path state block (PSB) the local API, then
                  instead of invoking routing, set OutInterface_List to
                  the single interface whose (SESSION,
             SENDER_TEMPLATE) pair address matches the corresponding objects sender
                  address; IncInterface is undefined in
             the message. this case.

             3.   If there IncInterface is a match considering wildcards in the
             SENDER_TEMPLATE objects, but the two SENDER_TEMPLATEs
             differ, build defined and send if a "Ambiguous Path" PERR message, multicast message
                  arrived on an interface different from IncInterface,
                  drop the PATH message, message and return.

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

             o    Create a new PSB.

             o

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

             o

             5.   Copy contents of the SESSION, TIME_VALUES, SENDER_TEMPLATE,
                  SENDER_TSPEC, and PHOP (IP address and LIH) objects
                  into the PSB.  Store the received TTL into the PSB.
                  Copy into the PSB any either of the following objects that
                  are present: POLICY_DATA, SENDER_TSPEC, POLICY_DATA and ADSPEC.

             6.   Turn on the Path_Refresh_Needed flag.

        o    Store ROUTE_MASK    Otherwise (there is a matching PSB and EXPECTED_INTERFACE there is no dest
             port conflict):

             1.   If there is no route change notification in place,
                  call the PSB.

             o    Turn appropriate Route_Query routine using
                  DestAddress from SESSION and (for multicast routing)
                  SrcAddress from SENDER_TEMPLATE.

                  -    If the OutInterface_list that is returned differs
                       from that in the PSB, execute the PATH LOCAL
                       REPAIR event sequence below.

                  -    If a multicast message arrived on an interface
                       different from IncInterface, drop the Path_Refresh_Needed flag.

        6.   Otherwise (there is a matching PSB):

             o    Restart cleanup timer.

             o message and
                       return.

             2.   If the PHOP IP address, the LIH, or SENDER_TSPEC and/or ADSPEC values differ
                  differs between the message and the PSB, copy the new values
                  value into the PSB and turn on PSB, execute 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 REFRESH event
                  sequence for the new ROUTE_MASK differs from that stored in sender defined by the PSB, and turn
                  on the Path_Refresh_Needed flag, flag.

                  [LZ: [When] should ADSPEC change trigger a refresh?]

                  However, if the PATH message being processed came from
                  a local application and store if there is reservation state
                  for this session, then make a Resv Event upcall to
                  that application instead of executing the new ROUTE_MASK into RESV REFRESH
                  sequence.

                      Call: <Upcall_Proc>( session-id, Resv Event, 1,
                                  {Flowspec}, NULL, NULL, NULL )

             3.   Restart the PSB. cleanup timer.

        o    If the new EXPECTED_INTERFACE differs message arrived with a TTL different from that stored Send_TTL
             in the PSB, turn on RSVP common header, set the Resv_Refres_Needed Non_RSVP flag and
                  store the new EXPECTED_INTERFACE value into the PSB.

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

        8.
             PSB.

        o    If the Path_Refresh_Needed flag is now set, execute the
             PATH REFRESH event sequence (below); however, send no set then:

             1.   If this PATH
             refresh messages out the message came from a network interface through which and
                  not from a local application, make a Path Event upcall
                  for each local application for this session:

                      Call: <Upcall_Proc>( session-id, Path Event, 1,
                                  {SENDER_TSPEC}, {SENDER_TEMPLATE},
                                  {ADSPEC}, {POLICY_DATA} )

             2.   Execute the PATH
             message arrived.

        9.   If the Resv_Needed flag is now set, execute the RESV REFRESH event sequence (below). (below) for
                  the sender defined by the PSB.

   PATH TEAR MESSAGE ARRIVES

        o    Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
             matches the corresponding objects in the message.  If there is no path state for this destination,
             matching PSB is found, drop the PTEAR message and return.

        o    Forward a copy of the PTEAR message using to each outgoing
             interface listed in OutInterface_list of the same rules as
             for a PATH message (see PATH REFRESH). PSB.

        o    Each sender descriptor in    Find each RSB that matches this PSB, i.e., whose
             FILTER_SPEC object matches the PTEAR message contains a SENDER_TEMPLATE object defining a sender S; process it as
             follows.

             1.   Locate in 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 whose OI is associated with sender S and included in OutInterface_list.

             If this RSB matches no other sender.

             3. PSB, then tear down the RSB,
             as described below under RESV TEAR MESSAGE ARRIVES.

        o    Delete the PSB.

        o    Drop the PTEAR message and return.

   PATH ERROR MESSAGE ARRIVES

        o    If there are no existing PSB's    Search for SESSION then drop a PSB whose (SESSION, SENDER_TEMPLATE) pair
             matches the
             PERR message and return.

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

        o    If PHOP the previous hop address in the PSB is the local API, deliver
             make an error upcall to application
             via an upcall: the application:

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

             Any POLICY_DATA, SENDER_TSPEC, or ADSPEC object in the
             message is ignored.  [LZ: Why we don't send these objects
             up to application?  They might of some help to understand
             the errors.]  Drop the PERR message and return.

        o    Otherwise (PHOP is not local API), forward    Otherwise, send a copy of the PERR message to the PHOP node. IP
             address, drop the PERR message, and return.

   RESV MESSAGE ARRIVES

        A RESV message arrives through

        Initially, the Resv_Refresh_PHOP* list is empty and the
        Resv_Refresh_Needed flag is off.  These variables are used to
        control immediate reservation refreshes.

        o    Process the NHOP object

             The logical outgoing interface OI. OI is taken from the LIH in
             the NHOP object.  (If the physical interface is not implied
             by the LIH, it can be learned from the interface matching
             the IP destination address).

        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.

             [LZ: Explain this?]

        o    Check the STYLE S_POLICY_DATA object.

             If the style in the message conflicts with the style of any
             reservation for this session there is an S_POLICY_DATA object 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. reservation for the session.  If it is unacceptable, the
             check fails, build and send an "Administrative rejection"
             RERR message, drop the RESV message, and return.

        o    Make reservations

             Process
             Otherwise, copy the S_POLICY_DATA object into the RSB.

        Now process the STYLE object and the flow descriptor list. list to
        make reservations, as follows.

        For FF style, execute the following steps independently for each
        b flow descriptor, i.e., for each (FLOWSPEC, FILTER_SPEC) pair.
        For FF style, FILTER_SPEC* consists of the single FILTER_SPEC
        from the flow descriptor.

        For SE style, execute the following steps for each
             FILTER_SPEC in once, with
        FILTER_SPEC* consisting of the list, using list of FILTER_SPEC objects from
        the given FLOWSPEC. flow descriptor.

        For WF style, execute the following steps once, using an with
        FILTER_SPEC* consisting of a single internal placeholder "WILD_FILTER" for FILTERSPEC if it
        "WILD_FILTER".

        o    If the DstPort in the SESSION object is omitted.

             1. zero but the
             SrcPort in the FILTER_SPEC object is non-zero, build a send
             a "Conflicting Src Port" RERR message, drop the RESV
             message, and return.

        o    Find or create a reservation state block (RSB) for the
                  4-tuple:
             triple: (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 FILTER_SPEC*).  Call this set is empty, build and send an error
                       message specifying "No sender information", and
                       continue with the next flow descriptor.

                  -
             "active RSB".

        o    If this set contains more than one PSB the RSB is not new and if the its style has is incompatible with
             the explicit option (e.g., FF or SE), STYLE object in the message, build and send an error a RERR
             message specifying
                       "Ambiguous filter spec" "Conflicting Style", drop the RESV
             message, and return.

        o    Start or restart the cleanup timer on the the active RSB.

        o    If the active RSB is not new, check whether FLOWSPEC or
             SCOPE objects have changed.  If not, continue with the next
             flow descriptor.

                  -    Set K_E_Police_flag on if any of these PSBs have descriptor in the E_Police flag on, otherwise set
                       K_E_Police_flag off.  Set K_M_Police_flag on RESV message, if any.

        o    If the style has wildcard scope and there active RSB 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 new, 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 its OI and style, and copy
             any FLOWSPEC, POLICY_DATA, and/or SCOPE objects in these
                       RSB's.

             6. into it.

        o    If this reservation has wildcard scope and this there is not
                  the first flow descriptor a RESV_CONFIRM in the message, one of turn on
             Resv_Refresh_Needed and save the
                  filter specs object in the RSB.

        o    The active RSB must have changed; delete be new or changed.  Compute the old one and
                  install traffic
             control parameters, using the new:

                         TC_DelFilter( old_Fhandle );

                         Fhandle = TC_AddFilter( Rhandle, SESSION, K_filter)

                  Then continue with following steps.

             1.   Locate the next flow descriptor.

             7.   Otherwise, if there was no previous kernel reservation set of PSBs (senders) whose
                  SENDER_TEMPLATEs match FILTER_SPEC* 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 ) active RSB
                  and whose OutInterface_list includes OI.

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

                     TC_AddFilter( Rhandle, SESSION, K_Filter)

                  to RESV message.

             2.   If this set the filter, contains more than one PSB and continue with the next flow
                  descriptor.

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

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

                  If this call fails, explicit sender selection (e.g., FF or SE),
                  build and send a RERR an error message specifying "Admission control failed".  In any case,
                  drop the RESV message and return.

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

                     TC_DelFilter( old_Fhandle )
                        Fhandle = TC_AddFilter( Rhandle, SESSION, K_filter)
                  Then spec" and 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

             3.   Add the IP address of OI, and PHOP from the message is sent unicast to NHOP.

   RESV TEAR MESSAGE ARRIVES

        A RTEAR message arrives on outgoing interface OI.

        o    Initialize flag Tear_Needed PSB to False.

        o    Execute the following steps for each flow descriptor, i.e.,
             each (FLOWSPEC, FILTERSPEC) pair, in the flow descriptor
             list:

             1.   Find matching RSB for the 4-tuple: (SESSION, NHOP,
                  style, FILTER_SPEC).  If no RSB Resv_Refresh_PHOP*
                  list, if the PHOP is found, continue
                  with next flow descriptor.

             2.   Delete not already on the RSB.

             3.   If list.

             4.   Set TC_E_Police_flag on if any of these PSBs have
                  their E_Police flag on.  Set TC_M_Police_flag on if it
                  is a shared style and there are no is more RSBs for than one PSB in
                  the same (SESSION, OI,
                  FILTER_SPEC) triple, call set.

             5.   Compute Path_Te as the kernel interface to
                  delete sum of the reservation:

                     TC_DelFlowspec( K_handle )

                  and SENDER_TSPEC objects
                  in this set Tear_Needed to True.

             4.   Otherwise (there are other of PSBs.

             6.   Scan all RSB's for matching the same
                  reservation), recompute K_Flowspec SESSION and call the kernel
                  interface module:

                     TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec)

                  to update the reservation.  If this kernel call fails,
                  return;
                  Filter_Spec_list from the prior reservation will remain in place.

        o message.

                  -    If Tear_Needed is False (the resulting merged state may
             have changed but any of these RSB's has a style that is still in place), then execute
                       incompatible with the RESV
             REFRESH sequence below, specifying "Conflicting
                       Style", drop RTEAR the RESV message, delete the RSB if
                       it has just been created, and return.

        o    Otherwise, need to create new RTEAR message for each PHOP,
             and perhaps some RESV refresh messages.

                  -    Set Refresh_Needed flag to False.  Do TC_B_Police_flag on if TC_Flowspec is smaller
                       than, or incomparable to, any FLOWSPEC in those
                       RSB's.

             7.   Consider the following set of RSB's for
             each sender Si (in the path stat) whose ROUTE_MASK includes same (SESSION, OI,
                  Filter_Spec_list) triple from the outgoing interface OI and for each PHOP:

             1.   Pick each flow descriptor Fj message.

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

                  -    Compute the RTEAR message
                  whose FILTER_SPEC matches Si, and do effective kernel filter spec (list),
                       TC_Filter*. by merging the FILTER_SPEC* object
                       (lists) from these RSB's.

        o    Search for a TCSB matching the following.

                  - triple (SESSION, OI,
             FILTER_SPEC*), taken from the RSB.

             1.   If there none is no RSB whose FILTER_SPEC matches Si,
                       then add Fj to the new RTEAR message being built.

                  -    Otherwise (there found but style is SE, search for a TCSB
                  matching RSB), note (SESSION, OI).  If find one and if TCSB's
                  TC_Flowspec, Path_Te, and police flags match the
                       incoming interface of Si as
                  computed values, then

                  -    Make an interface needing
                       a RESV refresh message and appropriate set the Refresh_Needed
                       flag True.

             2.   If the new RTEAR message contains any flow
                  descriptors, forward it of TC_DelFilter and
                       TC_AddFilter calls to PHOP.

                  If transform the scope is wildcard, include only a single flow
                  descriptor
                       Filter_Spec_list in the message.

        o    If the Refresh_Needed flag is true, then execute TCSB into the
             RESV_REFRESH sequence below, for
                       Filter_Spec_list from the incoming interfaces
             that have been noted.

   RESV ERROR MESSAGE ARRIVES

        o    If there is no state for SESSION, then message.

                  -    Set Resv_Refresh_Needed on, drop the RERR
             mesasge RESV
                       message, and return.

        o    For each RSB, do the following.  Note that an RSB implies
             an outgoing interface OI and

             2.   Otherwise, if none is found:

                  -    Create a next hop NHOP.

             1.   If OI differs from new TCSB.

                  -    Store TC_Flowspec, Filter_Spec_list, Path_Te, and
                       the incoming interface through
                  which police flags into TCSB.

                       [SCOPE?]

                  -    Set Resv_Refresh_Needed on.

                  -    Make the traffic control call:

                          Rhandle = TC_AddFlowspec( OI, TC_flowspec, Path_Te,
                                              TC_E_Police_flag, TC_M_Police_flag,
                                              TC_B_Police_flag )

                       If this call fails, build and send a RERR message arrived,
                       specifying "Admission control failed", and
                       continue with the next
                  RSB.

             2.   Compare flow descriptor.
                       Otherwise, record Rhandle in the FILTER_SPEC(s) TCSB.

                  -    For each filter_spec F in Filter_Spec_list, call:

                          Fhandle = TC_AddFilter( Rhandle, SESSION, F)

                       and record the returned Fhandle in the error flow
                  descriptor TCSB.

                  -    Continue with the FILTER_SPEC(s) in next flow descriptor.

             3.   Otherwise (found existing TCSB), check whether
                  TC_Flowspec, Path_Te, and/or any of the police flags
                  has changed, and if so:

                  -    Store TC_Flowspec, Filter_Spec_list, Path_Te, and
                       the police flags into it.

                       [SCOPE?]

                  -    Set Resv_Refresh_Needed on.

                  -    Make the RSB.  If no
                  match, continue traffic control call:

                          TC_ModFlowspec( Rhandle, K_Flowspec, Path_Te,
                                       TC_E_Police_flag, TC_M_Police_flag,
                                       TC_B_Police_flag )

             4.   Continue with the next RSB.

                  Otherwise, form a new error flow descriptor with descriptor.

        o    If the
                  subset of FILTER_SPECs that matched.

             3.   Compare Resv_Refresh_Needed flag is now on, execute the FLOWSPEC RESV
             REFRESH sequence (below) for each PHOP in the
             Resv_Refresh_PHOP* set.

        If processing a RESV message finds an error, a RERR message with the
                  FLOWSPEC in the RSB.  If they don't match along any
                  coordinate (i.e., if is
        created containing flow descriptor and an ERRORS object.  The
        Error Node field of the RSB FLOWSPEC ERRORS object (see Appendix A) is strictly
                  `smaller'), continue with set to
        the next RSB.

                  If they agree on some but not all coordinates, turn on IP address of OI, and the LUB-used flag.

             4.   If NHOP in PSB message is local API, deliver error sent unicast to
                  application via NHOP.

   RESV TEAR MESSAGE ARRIVES

        A RTEAR message arrives with an upcall:

                           Call: <Upcall_Proc>( session-id, Resv Error, k,
                                     Error_code, Error_value, LUB-Used,
                                     Filter_Spec_List, Flowspec_List, NULL,
                             NULL) IP destination address matching
        outgoing interface OI.  Flags Tear_Needed and continue with
        Resv_Refresh_Needed are initially off and Resv_Refresh_PHOP*
        list is empty.

        o    Process the next RSB.  Here k,
                  Filter_Spec_List, STYLE object and Flowspec_List are constructed
                  from the new error flow descriptor.

             5.   If descriptor list in
             the RESV RTEAR message has wildcard scope, use its SCOPE
                  object SC.In to construct tear down local reservation state, as
             follows.

             For FF style, execute the following steps for each b flow
             descriptor, i.e., for each (FLOWSPEC, FILTER_SPEC) pair
             independently, with Filter_Spec_list consisting of a single
             FILTER_SPEC object.

             For SE style, execute the following steps once, with
             Filter_Spec_list consisting of a list of FILTER_SPEC
             objects.

             For WF style, execute the following steps once, with
             Filter_Spec_list consisting of a SCOPE object SC.Out to be
                  forwarded.  SC.Out should contain those sender
                  addresses that appeared in SC.In and that route to OI
                  [LIH?], as determined by scanning single internal
             placeholder "WILD_FILTER".

             1.   Find matching RSB for the PSB's. 4-tuple: (SESSION, NHOP,
                  style, Filter_Spec_list); call this the active RSB.
                  If
                  SC.Out no active RSB is empty, found, continue with the next flow
                  descriptor.

             2.   Delete the active RSB.

             6.   Create a new RERR message containing

             3.   Find TCSB for the new error
                  flow descriptor and send to triple: (SESSION, OI,
                  Filter_Spec_list).

             4.   Consider the NHOP address specified
                  by set of RSB's matching this TCSB.  If
                  there are none:

                  -    Call the RSB.  Include SC.Out if traffic control interface routine:

                          TC_DelFlowspec( Rhandle )

                  -    Delete the scope is wildcard.

             7. TCSB and set Tear_Needed flag on.

                  -    Continue with the next RSB.

        o    Drop flow descriptor.

             5.   Otherwise (there are other RSB's for the RERR message same TCSB),
                  recompute TC_Flowspec and return.

   PATH REFRESH Path_Te (see RESV MESSAGE
                  ARRIVES).  (This also adds the appropriate PHOP
                  addresses to the Resv_Refresh_PHOP* list>) If either
                  changed, update the TCSB, set flag Resv_Refresh_Needed
                  on, and call the traffic control interface module:

                     TC_ModFlowspec( Rhandle, TC_Flowspec, Path_Te)
                                  TC_E_Police_flag, TC_M_Police_flag,
                                  TC_B_Police_flag )

                  This sequence may kernel call should not fail, since the
                  reservation can only be entered by either reduced.

             [LZ: Suppose receiver R has the expiration of credential to make the path
   refresh timer for
             reservation and others took a particular session, or immediately ride on top of R's
             credential.  Now R tears down its request, what should
             happen?  Shouldn't TEAR take policy data as input?]

        o    If Tear_Needed and Resv_Refresh_Needed flags are both off,
             then drop the result
   of processing a PATH RTEAR message turning on the Path_Refresh_Needed flag.

   For and return.

        o    If Tear_Needed is off but Resv_Refresh_Needed is on, then
             execute the RESV REFRESH sequence for each outgoing interface OI, build a PATH message PHOP in the
             Resv_Refresh_PHOP* set, drop the RTEAR message, and send it return.

        o    Otherwise (Tear_Needed is on), need to
   OI.  To build forward RTEAR and/or
             RESV refresh messages.

             Do the message, consider following for each PSB whose ROUTE_MASK OutInterface_list
             includes OI, and do the following:

   o    Pass the ADSPEC and SENDER_TSPEC objects present outgoing interface OI:

             1.   Pick each flow descriptor Fj in the PSB to
        the kernel call TC_Advertise, and get back a modified ADSPEC
        object.  Pack this modified object into the PATH RTEAR message being
        built.

   o    Create a sender descriptor sequence containing
                  whose FILTER_SPEC matches the
        SENDER_TEMPLATE, SENDER_TSPEC, PSB, and POLICY_DATA objects, if
        present in do the PSB.  Pack
                  following.

                  -    If there is no RSB whose FILTER_SPEC matches the sender descriptor into
                       PSB, then add Fj to the PATH new RTEAR message being
                       built.

   o    If

                  -    Otherwise (there is a matching RSB), note the PSB has the E_Police flag on
                       as needing a RESV refresh message and if interface OI is not
        capable of policing, turn set the E_Police
                       Resv_Refresh_Needed flag on in True.

             2.   If the PATH new RTEAR message being built. contains any flow
                  descriptors, send it to PHOP in the PSB.

        o    Compute    If the IP TTL for Resv_Refresh_Needed flag is now on, execute the PATH message as one less than RESV
             REFRESH sequence (below) for each PHOP in the
        maximum of
             Resv_Refresh_PHOP* set.

             If the TTL values from Refresh_Needed flag is true, then execute the senders included in RESV
             REFRESH sequence for the
        message.  However, if PSB's that have been noted.

        o    Drop the result is zero, return without sending RTEAR message and return.

   RESV ERROR MESSAGE ARRIVES

        A RERR message arrives through the PATH message. (real) incoming interface
        In_If.

        o    If there is no path state for SESSION, drop the maximum size of the PATH RERR
             message is reached, send and return.

        o    Do the
        packet out interface following with each RSB for this SESSION whose OI
             does not match In_If and start packing a new one.

   RESV REFRESH

   This sequence may be entered by either whose FILTER_SPEC matches that in
             the expiration of RERR message.

             1.   Copy the
   reservation refresh timer for a particular session, or immediately as error flow descriptor from the result of processing a RESV or RTEAR incoming RERR
                  message.

   For each PHOP defined by the path state, scan

             2.   Compare the RSBs, merge FLOWSPEC in the
   style, FLOWSPECs and FILTER_SPECs appropriately, build a new RESV
   message, and send it to PHOP.  Each RERR message carries a NHOP object
   containing with the local address of
                  FLOWSPEC in the interface through which it RSB.  If they don't match along any
                  coordinate (i.e., if the RSB FLOWSPEC is
   sent.

   The details of building strictly
                  `smaller'), continue with the RESV messages depend upon next RSB.

                  If they agree on some but not all coordinates, turn on
                  the
   shared/distinct option of LUB-used flag.

             3.   If NHOP in RSB is the style.  For each PHOP, do local API, deliver an error
                  upcall to application:

                           Call: <Upcall_Proc>( session-id, Resv Error,
                                     Error_code, Error_value, Node_Addr,
                                        LUB-Used,
                                        Flowspec, Filter_Spec_List,
                                        NULL, NULL)

                  and continue with the
   following:

   o    Distinct style

        Select each sender Si (PSB) for PHOP, next RSB.  Here k,
                  Filter_Spec_List, and do Flowspec_List are constructed
                  from the following:

        1.   Select all RSB's whose FILTER_SPECs match error flow descriptor.

             4.   If the
             SENDER_TEMPLATE RESV message has wildcard sender selection, use
                  its SCOPE object for Si SC.In to construct a SCOPE object
                  SC.Out to be forwarded.  SC.Out should contain those
                  sender addresses that appeared in SC.In and whose that route
                  to OI matches a bit in
             the ROUTE_MASK of [LIH?], as determined by scanning the PSB for Si.

        2.   Compute PSB's.  If
                  SC.Out is empty, continue with the maximum over next RSB.

             5.   Create a new RERR message containing the FLOWSPEC objects of this set
             of RSB's, and merge their FILTER_SPEC, STYLE, error flow
                  descriptor and
             POLICY_DATA objects.

        3.   Append the (FLOWSPEC, FILTER_SPEC pair) send to the RESV message
             being built for destination PHOP.  When NHOP address specified by
                  the packet fills,
             or upon completion of all PSB's RSB.  Include SC.Out if the sender selection is
                  wildcard.

             6.   Continue with the same PHOP, send
             it. next RSB.

        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    Drop the ROUTE_MASK for
             Si, RERR message and (b) contain at least one FILTER_SPEC that matches return.

   RESV CONFIRMATION ARRIVES

        If the SENDER_TEMPLATE (unicast) IP address found in its RESV_CONFIRM object for Si.

        2.   For all selected RSB's for all Si corresponding to
        matches an interface of the node, a given
             PHOP:

             -    Compute confirmation upcall is made
        to the maximum over matching application:

                    Call: <Upcall_Proc>( session-id, Resv Confirm,
                              Error_code, Error_value, Node_Addr,
                              LUB-Used, nlist, Flowspec,
                              Filter_Spec_List, NULL, NULL )

        Otherwise, the FLOWSPEC objects of this
                  set of RSB's.

             -    Merge RACK message is forwarded immediately to the metching FILTER_SPEC objects; this will
        address in
                  general result the IP address in its RESV_CONFIRM object.

   PATH REFRESH

        This sequence sends a list path refresh for a particular sender,
        i.e., a PSB.  This sequence may be entered by either the
        expiration of non-overlapping
                  FILTER_SPECs, but where there are overlaps due to
                  wildcards, use the `wildest'.

             -    Merge path refresh timer or directly as the STYLE and POLICY_DATA objects.

             -    Place result
        of the Path_Refresh_Needed flag being turned on during the resulting merged objects into
        processing of a RESV message
                  and send it to PHOP.

        3.   If received PATH message.

        o    Compute the scope is wildcard, a forwarded RESV must contain a
             SCOPE object.  The set of IP addresses in TTL for the SCOPE object
             sent to a given PHOP is formed PATH message as follows.

             -    Take one less than
             the union maximum of the TTL values from the senders listed in SCOPE objects included in all RSB's.

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

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

APPENDIX A. Object Definitions

   C-Types are defined for zero, return
             without sending 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. PATH message.

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

           +-------------+-------------+-------------+-------------+
           |             IPv4 DestAddress (4 bytes)                |
           +-------------+-------------+-------------+-------------+
           |   //////    |    Flags    |         DestPort          |
           +-------------+-------------+-------------+-------------+    Insert TIME_VALUES and PHOP objects into the PATH message
             being built.

        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    Create a sender descriptor containing the
           session.

      Flags

           0x01 = E_Police flag

                The E_Police flag is used SENDER_TEMPLATE,
             SENDER_TSPEC, and POLICY_DATA objects, if present in PATH messages to determine the effective "edge" of
             PSB, and pack it into the network, PATH message being built.

        o    Pass any ADSPEC and SENDER_TSPEC objects present in the PSB
             to control the traffic
                policing. control call TC_Advertise.  Insert the
             modified ADSPEC object that is returned into the PATH
             message being built.

        o    If the sender host PSB has the E_Police flag on and if interface OI is
             not itself capable of
                traffic policing, it will set this bit turn the E_Police flag on in the
             PATH
                messages it sends.  The first node whose RSVP is capable message being built.

        o    Send a copy of traffic policing will do so (if appropriate the PATH message to each interface in
             OutInterfact_list.  Before sending each copy, insert into
             its PHOP object the
                service) interface address and turn the flag off.

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

      DestPort

           The UDP/TCP destination port LIH for the session.  Zero may be
           used to indicate
             interface.

   RESV REFRESH

        This sequence sends a `wildcard', i.e., any port.

           Other SESSION C-Types could reservation refresh towards a particular
        previous hop with IP address PH.  This sequence may be defined in the future to
           support other demultiplexing conventions in entered
        by either 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 expiration of a reservation refresh timer or
        directly as the IP address result of the interface through which Resv_Refresh_Needed flag being
        turned on as the last RSVP-knowledgeable hop forwarded this result of processing a RESV or RTEAR message.  The
      Logical Interface Handle is

        In general, this sequence considers each of the PSB's with PHOP
        address PH.  For a 32-bit number which may be used given PSB, it scans the RSBs for matching
        reservations and merges the styles, FLOWSPECs and FILTER_SPEC*'s
        appropriately.  It then builds a RESV message and sends it to
      distinguish logical outgoing interfaces as described
        PH.  The details depend upon the attributes of the style(s)
        included in Section
      4.2; it should be identically zero if the reservations.

        o    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. are PSB's from more than one PHOP and if the
             multicast routing protocol does not use shared trees, set
             the Need_Scope flag on, otherwise set it off.

        o    Create an output message containing SESSION, RSVP_HOP,
             INTEGRITY, and TIME_VALUES Object: Class = 5, C-Type = 1

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

      Refresh Period

           The refresh timeout period R used to generate objects.

        o    Select each sender PSB whose PHOP has address PH.

             1.   Select all RSB's whose FILTER_SPEC*'s match the
                  SENDER_TEMPLATE object in the PSB and whose OI appears
                  in the OutInterface_list of the PSB.

             2.   Get a STYLE object from the first RSB and move it into
                  the output message.  (Note that the present set of
                  styles are never themselves merged; if future styles
                  can be merged, these rules will become more complex).

             3.   Compute the maximum/LUB over the FLOWSPEC objects of
                  this message; set of RSB's.

             4.   While computing the maximum/LUB, check for a
                  RESV_CONFIRM object in milliseconds.

      Max Refresh Period

           The largest R value that each RSB.  If a node RESV_CONFIRM
                  object is allowed to apply to the
           downstream state for this session.  A node may refuse to
           accept this requirement, by ignoring found and if the message containing FLOWSPEC in that RSB is
                  larger than all other flowspecs being compared, then
                  save this TIME_VALUES RESV_CONFIRM object.  If a RESV_CONFIRM
                  object is found but the corresponding FLOWSPEC is
                  equal or smaller than the largest, or if the result of
                  merging was a LUB, then create and sending send a "R too small" error RACK message
                  to the address in the RESV_CONFIRM object.

                  -    Include the RESV_CONFIRM object in the RACK
                       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

                  -    Build a confirmation ERROR_SPEC object: Class = 6, C-Type = 2

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

      Error Node Address object and
                       include it in the RACK message.  The Error_Node
                       parameter in this object should be the IP address
                       of OI from the node in which RSB.

                  Then delete 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 RESV_CONFIRM object from the
                error.  Its contents RSB.

             5.   Merge the matching FILTER_SPEC objects from this set
                  of RSB's.  The merging rule depend upon the Error Type.

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

   A.6 SCOPE Class style:

                  Explicit sender selection (FF, SE) styles:

                       Use the SENDER_TEMPLATE as the merged
                       FILTER_SPEC.

                  Wildcard sender selection (WF) style:

                       There is no filter spec to merge.

             6.   If the Need_Scope flag is on, compute a new SCOPE class = 7.

      This
                  object contains a list as the union 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 the SCOPE list object: Class = 7, C-Type = 2

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

      STYLE class = objects found in the
                  RSB's.

             7.   Merge the F_POLICY_DATA objects from the RSB's.

             8.

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

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

      Style ID

           An integer identifying   (All matching RSB's have been processed).  The next
                  step depends upon the style attributes.

                  Distinct reservation (FF) style

                       Pack the merged (FLOWSPEC, FILTER_SPEC,
                       F_POLICY_DATA) triplet into the message as a flow
                       descriptor.

                  Shared reservation (SE, WF) styles

                       Merge (take the maximum) across all PSB's the
                       merged FLOWSPECS from the RSB's.

                       If the sender selection is not wildcard (i.e., if
                       it is SE), form the union of the FILTER_SPECs
                       obtained from the RSB's.  For Wildcard sender
                       selection (WF) style, as follows:

           0 = No ID assigned; use option vector.

           1 = WF

           2 = FF

           3 = SE

      Option Vector

           A there is not filter spec to
                       merge.

             9.   If the Need_Scope flag is on, remove from the merged
                  SCOPE object all sender addresses that do not match
                  the set of bit fields giving values PSB's for PH, and all senders addresses
                  that are local.  If the resulting set is empty, no
                  RESV should be forwarded to this PHOP; return;
                  otherwise (set is not empty), move the new SCOPE
                  object into the message.

        o    (All PSB's have been processed).  If a shared reservation
           options.
             style is being built, move the final merged FLOWSPEC,
             F_POLICY_DATA, and FILTER_SPEC (if SE) objects into the
             message.

        o    If a RESV_CONFIRM object was saved earlier, copy it into
             the new options are added RESV message and delete it from the RSB in which it
             was found.

        o    Set the futre,
           corresponding fields RSVP_HOP object in the option vector will be assigned
           from message to contain the least-significant end.  If a node does not recognize
           a style ID,
             IncInterface address through which it may interpret as much of will be sent and the option vector as
           it can, ignoring new fields that may have been defined.

           The option vector bits are assigned (from
             LIH from (one of) 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 PSB's.

        o    Send the option vector message to the address PH.

APPENDIX A. Object Definitions

   C-Types are determined by defined for the
      style id, two Internet address families IPv4 and
   IP6.  To accommodate other address families, additional C-Types could
   easily be defined.  These definitions are contained as follows:

              WF 10001b
              FF 01010b
              SE 10010b
   A.8 FLOWSPEC an Appendix,
   to ease updating.

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

   A.1 SESSION Class

      SESSION Class

      FLOWSPEC class = 9. 1.

      o    IPv4/UDP SESSION object: Class = 9, 1, C-Type = 1:  int-serv flowspec

           The contents of this object will be specified in documents
           prepared by the int-serv working group. 1

           +-------------+-------------+-------------+-------------+
           |             IPv4 DestAddress (4 bytes)                |
           +-------------+-------------+-------------+-------------+
           | Protocol Id |    Flags    |          DstPort          |
           +-------------+-------------+-------------+-------------+

      o    IP/UDP SESSION object: Class = 9, 1, C-Type = 254:  Unmerged Flowspec List 2

           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 FLOWSPEC object  1                  //
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           +               IP6 DestAddress (16 bytes)              +
           |                                                       |
           //                 FLOWSPEC object  2                  //
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           //                                                     //
           //                                                     //
           +-------------+-------------+-------------+-------------+
           | Protocol Id |
           //                 FLOWSPEC object  k                  //     Flags   |          DstPort          |
           +-------------+-------------+-------------+-------------+

      DestAddress

           The IP unicast or multicast destination address of the
           session.  This parameter must be supplied.

      Protocol Id

           The IP Protocol Identifier for the data flow.  This parameter
           must be supplied.

      Flags

           0x01 = E_Police flag

                The E_Police flag is a container C-Type, 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.]

      DstPort

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

           Other SESSION C-Types could not be merged at the next hop downstream
           because they include unrecognized C-Types.  The node that
           receives this object may merge those it recognizes and
           forward defined in the rest future to
           support other demultiplexing conventions in another Unmerged Flowspec List object.

   A.9 FILTER_SPEC the transport-
           layer or application layer.

   A.2 RSVP_HOP Class

      FILTER_SPEC

      RSVP_HOP class = 10. 3.

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

           +-------------+-------------+-------------+-------------+
           |             IPv4 SrcAddress (4 bytes) Next/Previous Hop Address            |
           +-------------+-------------+-------------+-------------+
           | Protocol Id |    //////   |          SrcPort                 Logical Interface Handle              |
           +-------------+-------------+-------------+-------------+

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

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +             IP6 SrcAddress (16 bytes) Next/Previous Hop Address             +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           | Protocol Id                 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
      3.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

           +-------------+-------------+-------------+-------------+
           |          SrcPort                    Refresh Period                     |
           +-------------+-------------+-------------+-------------+

      Refresh Period

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

   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 Flow-label FILTER_SPEC ERROR_SPEC object: Class = 10, 6, C-Type = 3 2

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +           IP6 SrcAddress Error Node Address (16 bytes)           +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |   ///////    Flags    |         Flow Label (24 bits)  Error Code |        Error Value        |
           +-------------+-------------+-------------+-------------+

      SrcAddress

      Error Node Address

           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 of the packet classifier to efficiently identify node in which 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 error was detected.

      Flags

           0x01 = 12. LUB-Used

                The only current form use of Tspec this flag 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 described in section 3.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

      POLICY_DATA

      SCOPE class = 14. 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    Type 1 POLICY_DATA    IPv4 SCOPE List object: Class = 14, 7, C-Type = 1

           [TBD]

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

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

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

           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 POLICY_DATA object  1              //
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           +                IP6 Src Address (16 bytes)             +
           |                                                       |
           //                 POLICY_DATA object  2              //
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           //                                                      //
           //                                                     //
           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 POLICY_DATA object  k              //
           +                                                       +
           |                                                       |
           +                IP6 Src Address (16 bytes)             +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+

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:

           ussr cccc cccc cccc

        where the bits are:

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

        u = 1: RSVP may use message to update local state and forward
             it.

        ss
   A.7 STYLE Class

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

        ss 8.

      o    STYLE object: Class = 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.

        ss 8, C-Type = 11: Low order 12 bits contain a sub-code that is specific
             to 1

           +-------------+-------------+-------------+-------------+
           |                    Option Vector                      |
           +-------------+-------------+-------------+-------------+

      Option Vector

           A set of bit fields giving values for the service.  RSVP is not expected to reservation
           options.  If new options are added in the future,
           corresponding fields in the option vector will be able to
             interpret this except as a numeric value.  Since assigned
           from the
             traffic control mechanism might substitute least-significant end.  If a different
             service, this encoding node does not recognize
           a style ID, it may include some representation interpret as much of the service in use.

        r: Reserved bit, should be zero.

        cccc cccc cccc: 12 bit code.

        The following globally-defined sub-codes option vector as
           it can, ignoring new fields that 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 have been defined.

           The option vector bits should be 000r, so
             that RSVP will reject are assigned (from the message. left) as
           follows:

           27 bits: Reserved

           2 bits: Sharing control

                00b: Reserved

                01b: Distinct reservations

                10b: Shared reservations

                11b: Reserved

           3 bits: Sender selection control

                000b: Reserved

                001b: Wildcard

                010b: Explicit

                011b -    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 111b: Reserved

      The low order 4 bits of the Error Value
        field option vector are assigned determined by the
      style, as for Code follows:

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

      FLOWSPEC class = 01 (above).  For 9.

      o    Class = 9, C-Type = 1:  int-serv flowspec

           The contents of this case, the
        following global sub-codes may object will be used:

        -    Sub-code specified in documents
           prepared by the int-serv working group.

      o    Class = 1: Required credential(s) not presented.

        -    Sub-code 9, C-Type = 2: Request too large

             Reservation request exceeds allowed value for 254:  Unmerged Flowspec List

           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 FLOWSPEC object  1                  //
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 FLOWSPEC object  2                  //
           |                                                       |
           +-------------+-------------+-------------+-------------+
           //                                                     //
           //                                                     //
           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 FLOWSPEC object  k                  //
           |                                                       |
           +-------------+-------------+-------------+-------------+

           This is a container C-Type, used to enclose a set of FLOWSPEC
           objects that could not be merged at the next hop downstream
           because they include unrecognized C-Types.  The node that
           receives this user
             class.

        -    Sub-code object may merge those it recognizes and
           forward the rest in another Unmerged Flowspec List object.

   A.9 FILTER_SPEC Class

      FILTER_SPEC class = 3: Insufficient quota or balance.

        -    Sub-code 10.

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

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

      o    Error Code    IP6 FILTER_SPEC object: Class = 03: No path information for this Resv

        RSVP should reject the message. 10, C-Type = 2

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

      o    Error Code    IP6 Flow-label FILTER_SPEC object: Class = 04: No sender information 10, C-Type = 3

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

      SrcAddress

           The IP source address for this Resv

        There is path information, but it does not include the a sender
        specified in host, or zero to indicate
           a `wildcard'.

      SrcPort

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

      Flow Label

           A 24-bit Flow Label, defined in IP6.  This value may be used
           by the Resv message.
        RSVP should reject packet classifier to efficiently identify the message.

   o    Error Code packets
           belonging to a particular (sender->destination) data flow.

   A.10 SENDER_TEMPLATE Class

      SENDER_TEMPLATE class = 05: Ambiguous path

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

      o    Error Code    IPv4/UDP SENDER_TEMPLATE object: Class = 06: Ambiguous filter spec

        Filter spec matches more than one sender, in style that requires
        a unique match.  RSVP should reject the message. 11, C-Type = 1

           Definition same as IPv4/UDP FILTER_SPEC object.

      o    Error Code    IP6/UDP SENDER_TEMPLATE object: Class = 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. 11, C-Type = 2

           Definition same as IP6/UDP FILTER_SPEC object.

   A.11 SENDER_TSPEC Class

      SENDER_TSPEC class = 12.

      o    Error Code    Token Bucket SENDER_TSPEC object: Class = 12, C-Type = 11: Missing required object

        RSVP was unable to find or construct required 1

           The contents of this object data from
        message.  Error Value will be Class-Num that is missing.  RSVP
        should reject specified in documents
           prepared by the message.

   o    Error Code int-serv working group.

   A.12 ADSPEC Class

      ADSPEC class = 12: Unknown 13.

      The contents of this 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 specified in documents
      prepared by the message. int-serv working group.

   A.13 POLICY_DATA Class

      POLICY_DATA class = 14.

      o    Error Code    Type 1 POLICY_DATA object: Class = 13: Unknown object 14, C-Type

        Error Value will contain 16-bit value composed of (Class-Num,
        C-Type) = 1

           The contents of object. this object are for further study.

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

           This error should be sent only if RSVP object is
        going to should reject the message. 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 RESV_CONFIRM Class

      RESV_CONFIRM class = 15.

      o    IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |            IPv4 Receiver Address (4 bytes)            |
           +-------------+-------------+-------------+-------------+

      o    IP6 RESV_CONFIRM object: Class = 15, C-Type = 2

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +            IP6 Receiver Address (16 bytes)            +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+

APPENDIX B. Error Code = 14: Object error

        A non-specific error indicating bad format or contents of an
        object. Codes and Values

   The following Error Value will contain 16-bits value (Class-Num,
        C-Type) from header of bad object.  RSVP should reject the
        message. Codes are defined.

   o    Error Code = 21: Traffic Control error

        Some system error was detected and reported 01: Admission failure

        Reservation rejected by the traffic
        control modules.  The admission control.

        For this Error Value will contain a system-specific
        value giving more information about Code, the 16 bits of the error.

   o    Error Code = 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 are:

           ussr cccc cccc cccc

        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 bits are:

        u = 0: RSVP intercept.

   In rejects 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 message without updating local state.

        u = 1: RSVP may use message to the Internet through some arbitrarily complex set of networks update local state and
   routers forward
             the message.

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

        ss = 10: Low order 12 bits contain a sub-code that is labelled the "Corporate cloud".  The border router R specific
             to local organization.  RSVP is assumed not expected to be RSVP-capable, but the corporate cloud is not.

                     _ _ _ _
     ______        (         )      RSVP-capable
    |      |      (           )       router
    |  Hu  |-----(  Corporate  )      ______
    |______|      (           )     a|      |b
                 (    cloud    )-----|  R   |---->Internet
     ______       (           )      |______|
    |      |     (             )
    |  Hr  |------(           )
    |______|       (_ _ _ _ _)

                       Figure 13: End Host Situation

   We assume that Hu is able to
             interpret this except as a "UDP-only" host that requires UDP
   encapsulation, while Hr is numeric value.

        ss = 11: Low order 12 bits contain a "raw-capable" host sub-code 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 specific
             to the next host node
   needs UDP encapsulation, a RESV message can simply service.  RSVP is not expected to be sent able to the
   next-hop node, either in raw mode or with UDP encapsuation.

   UDP encapsulation of PATH messages poses
             interpret this except as a more difficult problem.
   To solve it, we define two new well-known multicast addresses G1 and
   G2, and numeric value.  Since the
             traffic control mechanism might substitute a well-known UDP port Pu.  Then different
             service, this encoding may include some representation of
             the table service in use.

        r: Reserved bit, should be zero.

        cccc cccc cccc: 12 bit code.

        The following globally-defined sub-codes may appear in Figure 14 shows
   the rules.  Under the `Send' column, low-
        order 12 bits when ss = 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 notation is <mode>(destaddr,
   destport, TTL), where TTL is requested service
             nor an acceptable replacement.

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

             Unreasonable request.  High order bit u = 0, i.e., RSVP
             will reject the IP-layer hop count. 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.

        The `Receive'
   column shows high order 4 bits of the group that is joined and, where relevant, Error Value field are assigned as
        for Error Code = 01 (above).  For Error Code = 02, the UDP
   Listen port.  T1 and T2 following
        global sub-codes are configured IP TTL values used defined:

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

        -    Sub-code = 2: Request too large

             Reservation request exceeds allowed value for
   encapsulation, while Tr this user
             class.

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

        -    Sub-code = 4: Administrative preemption

   o    Error Code = 03: No path information for this Resv

        RSVP should reject the message.

   o    Error Code = 04: No sender information for this Resv

        There is path information, but it does not include the local TTL value sender
        specified in one of the specific PATH
   message.  Finally, D is Filterspecs listed in the DestAddress for Resv message.
        RSVP should reject 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 message.

   o    Error Code = 05: Ambiguous path

        Sender port appears both zero and once non-zero 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 same session.
        RSVP should reject the duplicates, but this redundancy actually has no
   ill effect other message.

   o    Error Code = 06: Ambiguous filter spec

        Filter spec matches more than overhead for processing one sender, in a style that
        requires a unique match.  RSVP should reject the extra messages.

   A router must keep track of which message.

   o    Error Code = 07: Conflicting or unknown style

        Reservation style conflicts with style(s) 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 existing
        reservation state, or it receives a UDP-encapsulated
   PATH message, mark is unknown.  If the corresponding path state as UDP-needed.  Then
   matching RESV messages will be correctly encapsulated.

   Two provisions are necessary for this automatic determination high-order bit of
   encapsulation to work.

   C1   A router must use different groups G1 and G2
        Error Value is zero, RSVP should reject the message.

   o    Error Code = 08: Conflicting dest port

        Sessions for sending same destination address and
        receiving, as already shown.

   C2 protocol have appeared
        with both zero and non-zero dest port fields.

   o    Error Code = 09: Conflicting source port

        The TTL value T1 used by source port is non-zero in a host must be exactly enough filter spec or sender template
        for a session with destination port zero.

   o    Error Code = 11: Missing required object

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

   If T1 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 too small going to pass through reject the corporate cloud, of course
   PATH messages message.

   o    Error Code = 13: Unknown object C-Type

        Error Value will not contain 16-bit value composed of (Class-Num,
        C-Type) of object.  This error should be forwarded.  If T1 sent only if RSVP is too large, multicast
   routing in R will forward the UDP packet into
        going to reject the Internet until its
   hop count expires.  This message.

   o    Error Code = 14: Object error

        A non-specific error indicating bad format or contents of an
        object.  The Error Value will turn on UDP encapsulation between
   routers within contain 16-bits value (Class-Num,
        C-Type) from header of bad object.  RSVP should reject the Internet, causing bogus UDP traffic.  (Note that
   UDP packets addressed to G2 by a router will not be received
        message.

   o    Error Code = 21: Traffic Control error

        Some system error was detected and reported by a
   neighboring router).

   However, there are possible situations where it the traffic
        control modules.  The Error Value will be impossible to
   find contain a system-specific
        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 giving 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 information about the hosts' error.  RSVP daemons with
        the IP address for R; the daemons could then "unicast" PATH
        messages is not
        expected to be able to interpret this address.  This solution value.

   o    Error Code = 22: RSVP System error

        The Error Value field will be feasible as
        long as the number of Hr and Hu hosts is small.

   2.   A particular host provide implementation-dependent
        information on the LAN including Hu could be designated as
        an "RSVP relay host".  This system would listen on (G1,Pu) and error.  RSVP is not expected to be configured with able to
        interpret this value.

APPENDIX C. UDP Encapsulation

   An RSVP implementation will generally require the IP address of R.  It could then forward
        any (PATH) messages it received directly ability to R, and T1 could be
        set only large enough perform
   "raw" network I/O, i.e., to reach local hosts send and the relay.

   Finally, manual configuration receive IP datagrams using
   protocol 46.  However, some important classes of T1 could be replaced by an expanding
   ring search conducted by host systems may not
   support raw network I/O.  To use RSVP, such hosts must encapsulate
   RSVP daemons.  This possibility messages in UDP.

   The basic UDP encapsulation scheme makes two assumptions:

   1.   All hosts are capable of sending and receiving multicast
        packets.

   2.   The first/last-hop routers are RSVP-capable.

   A method of relaxing the second assumption is for
   future study.

APPENDIX D. Experimental given later.

   Let Hu be a "UDP-only" host that requires UDP encapsulation, and Open Issues
   D.1 Reservation Compatability

      How strong is the requirement for compatability Hr a
   host that can do raw network I/O.  The UDP encapsulation scheme must
   allow RSVP interoperation among an arbitrary topology of reservations in
      different directions?  For example, see Figure 11; should it be
      possible Hr hosts, Hu
   hosts, and routers.

   RESV, RERR, RTEAR, and PERR messages are sent to have incompatible unicast addresses
   learned from the path or reservation styles on state in the two
      interfaces? node.  If R1 requests a WF reservation the node
   keeps track of which previous hops and R2 requests a FF
      reservation, it is logically possible which interfaces need UDP
   encapsulation, these messages message can be sent using UDP
   encapsulation when necessary.

   On the other hand, PATH and PTEAR messages are send to make the corresponding
      reservations on unicast or
   multicast destination address for the two different interfaces. session.  The current
      implementation does NOT allow this; instead, it prevents mixing of
      incompatible styles table in Figure
   12 shows the same session on a node, even if they
      are on different interfaces.

   D.2 Session Groups (Experimental)

      Section 1.2 explained that a distinct destination address, and
      therefore a distinct session, will be used basic rules for each UDP encapsulation of such messages.
   Under the
      subflows in a hierarchically encoded flow.  However, these
      separate sessions are logically related.  For example it may be
      necessary to pass reservations for all subflows to Admission
      Control at `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 same time (since it would be nonsense to admit high
      frequency components but reject UDP Listen
   port.  The following symbols are also used:

   o    D is the baseband component of DestAddress for the
      session data).  Such a logical grouping particular session.

   o    G* is indicated in RSVP by
      defining a "session group", an ordered set of sessions.

      To declare that a set well-known group address of sessions the form 224.0.0.x, i.e., a session group, a receiver
      includes a data structure we call a SESSION_GROUP object in
        group that is limited to the
      RESV message local connected network.  [TO BE
        DEFINED]

   o    Pu is the well-known UDP port for each UDP encapsulation of the sessions.  A SESSION_GROUP object
      contains four fields: a reference address, a session group ID, a
      count, and a rank. RSVP:
        3455.

   o    The reference address    Ra is an agreed-upon choice from among the
           DestAddress values IP address of the sessions in router interface `a'.

   o    Tr is the group, for example TTL value of the smallest numerically. specific PATH message.

   o    The    Router interface `a' is on the local network connected to Hu and
        Hr, while interface `b' is connected only to another router.

                            RSVP             RSVP
   Node  Node Type          Send             Receive
   ___   __________     _____________     _______________
   Hu   UDP-only host    UDP(G*,Pu,1)     UDP(G*,Pu)
                        or UDP(Ra,Pu,1)   and UDP(D,Pu)
                        [Note 1]          [Note 3]

   Hr   Raw-mode host    UDP(G*,Pu,1)     UDP(G*,Pu)
                        and Raw(D,,Tr)    and Raw()

   R    Router
         Interface a:    UDP(D,Pu,Tr)     UDP(G*,Pu) [Note 2]
                        and Raw(D,,Tr)    and UDP(Ra,Pu)
                                          and Raw()

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

           Figure 12: UDP Encapsulation Rules for Path Messages

   [Note 1] Hu sends a PATH message to Ra only if session group ID destination
   address D is used unicast.

   [Note 2] R ignores PATH messages addressed to distinguish different groups
           with the same reference address.

      o G* if D is unicast.
   (This is necessary to prevent routing and reservation anomalies).

   [Note 3] The count DestAddress D is the number IP address of members Hu in the group.

      o    The rank, an integer between 1 this case.

   R and count, is different Hr send their PATH messages twice, once with UDP encapsulation
   and once in raw mode.  In two cases (Hr -> R and Hr -> Hr), each session of the session group. PATH
   message will be delivered twice.  The SESSION_GROUP objects destination may take steps to
   ignore the duplicates, although this redundancy has no ill effect
   other than overhead for all sessions in processing the group will
      contain extra messages.

   A router may determine if its interface X needs UDP encapsulation by
   listening for UDP-encapsulated PATH messages that were sent to either
   G* (multicast D) or to the same values address of interface X (unicast D).  There
   is one failure mode for this scheme:  if no host on the reference address, the session
      group ID, and the count value.  The rank values establishes the
      desired order among them.

      If connected
   network acts as an RSVP at a given node receives a RESV message containing a
      SESSION_GROUP object, it should wait until RESV sender, there will be no PATH messages for all
      `count' sessions have appeared (or until the end of the refresh
      cycle) and then pass the RESV requests to Admission Control as a
      group.  It is normally expected that all sessions in the group
   trigger UDP encapsulation.  In this (unlikely) case, it will be routed through
   necessary to explicitly configure UDP encapsulation on the same nodes.  However, if not, only a
      subset local
   network interface of the session group reservations may appear at router.

   A UDP-only host Hu supporting unicast RSVP sessions must somehow know
   the address Ra, presumably by configuration.

   When a given
      node; in this case, UDP-encapsulated packet is received, the IP TTL is not
   available to the application on most systems.  The RSVP daemon that
   receives a UDP-encapsulated PATH or PTEAR message should wait until therefore
   use the end Send_TTL field of the
      refresh cycle and then perform Admission Control on the subset of RSVP common header as the session group that it has received.  The rank values will
      identify which are missing.

      Note effective
   receive TTL.

   We have assumed that routing different sessions of the session group
      differently will generally result in delays in establishing or
      rejecting first-hop RSVP-capable router R is on the desired QoS.  A "bundling" facility could be added
      to
   directly-connected network.  There are several possible approaches if
   this is not the case.

   1.   Hu can send both unicast and multicast routing, to force all sessions in a session group to
        UDP(Ra,Pu,Ta).

        Here Ta must be routed along the same path.

      D.2.1 Resv Messages

         Add:

          [ <SESSION_GROUP> ]

         after TTL to exactly reach R.  If Ta is too small,
        the SESSION object.

      D.2.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 PATH message will not reach R.  If Ta is too large,
        multicast routing in above.

   D.3 DF Style (Experimental)

      In addition to R will forward the UDP packet into the
        Internet until its hop count expires.  This will turn on UDP
        encapsulation between routers within the WF Internet, causing bogus
        UDP traffic.  The host Hu must be explicitly configured with Ra
        and FF styles defined Ta.

   2.   A particular host on the LAN connected to Hu could be designated
        as an "RSVP relay host".  A relay host would listen on (G*,Pu)
        and forward any PATH messages directly to R, although it would
        not be in this specification,
      a Dynamic Filter (DF) style has also been proposed. the data path.  The following
      describes this style relay host would have to be
        configured with Ra and gives examples of its usage.  At this
      time, DF style is experimental.

      D.3.1 Ta.

APPENDIX D. Experimental and Open Issues

   D.1 Reservation Styles

         A Dynamic-Filter (DF) style reservation makes "distinct" Compatibility

      How strong is the requirement for compatibility of reservations with "wildcard" scope, but in
      different directions?  For example, see Figure 10; should it decouples
         reservations from filters.

         o    Each DF be
      possible to have incompatible reservation request specifies styles on the two
      interfaces?  If R1 requests a number D of
              distinct reservations using WF reservation and R2 requests a FF
      reservation, it is logically possible to make the same specified flowspec.
              These corresponding
      reservations are distributed with wildcard  scope,
              i.e., to all senders. on the two different interfaces.  The number current
      implementation does NOT allow this; instead, it prevents mixing of reservations that are actually made
      incompatible styles in a
              particular node is D' = min(D,Ns), where Ns is the total
              number of senders upstream same session on a node, even if they
      are on different interfaces.

   D.2 Session Groups (Experimental)

      Section 1.2 explained that a distinct destination address, and
      therefore a distinct session, will be used for each of the node.

         o    In addition to D and the flowspec,
      subflows in a DF style reservation hierarchically encoded flow.  However, these
      separate sessions are logically related.  For example it may also specify a list of K filterspecs, be
      necessary to pass reservations for some K in
              the range: 0 <= K <= D'.  These filterspecs define
              particular senders all subflows to use Admission
      Control at the D' reservations, and this
              list establishes same time (since it would be nonsense to admit high
      frequency components but reject the scope for baseband component of the filter specs.

              Once
      session data).  Such a DF reservation has been established, the receiver
              may change the logical grouping is indicated in RSVP by
      defining a "session group", an ordered set of filterspecs to specify sessions.

      To declare that a different
              selection set of senders, without sessions form a new admission control
              check (assuming D' and session group, a receiver
      includes a data structure we call a SESSION_GROUP object in the common flowspec remain
              unchanged).  This
      RESV message for each of the sessions.  A SESSION_GROUP object
      contains four fields: a reference address, a session group ID, a
      count, and a rank.

      o    The reference address is known as "channel switching", an agreed-upon choice from among the
           DestAddress values of the sessions in
              analogy with a television set.

         In order to provide assured channel switching, each node along the path must reserve enough bandwidth group, for all D' channels,
         even though some of this bandwidth may be unused at any one
         time.  If D' changes (because example
           the smallest numerically.

      o    The session group ID is used to distinguish different groups
           with the receiver changed D or because same reference address.

      o    The count is the number Ns of upstream sources changed), or if the common
         flowspec changes, members in the refresh message is treated as a new
         reservation that is subject to admission control and may fail. group.

      o    The DF style allows a receiver to switch channels without
         danger of rank, 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 integer between 1 and count, is different in turn implies that
           each session of the DF style creates
         reservations that may not be in use at any given time. session group.

      The DF style is compatible with SESSION_GROUP objects for all sessions in the FF style but not group will
      contain the WF or
         SE style.

      D.3.2 Examples

         To give an example same values of the DF style, we use reference address, the following
         notation:

         o    DF Style

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

         This message carries session
      group ID, and 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 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. value.  The rank values establishes the
      desired order among them.

      If RSVP at a given node
         reserves min(2,3) = 2 channels 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 size B on interface (d), the refresh
      cycle) and
         it then applies any specified filters pass the RESV requests to these channels.  Since
         only one sender was specified, one channel has no corresponding
         filter, Admission Control as shown by `?'.

         Similarly, a
      group.  It is normally expected that all sessions in the receivers downstream group
      will be routed through the same nodes.  However, if not, only a
      subset of interface (c) have
         requested two channels and selected senders S1 the session group reservations may appear at a given
      node; in this case, the RSVP should wait until the end of the
      refresh cycle and S2. then perform Admission Control on the subset of
      the session group that it has received.  The two
         channels might have been one channel each from R1 and R2, or
         two channels requested by one rank values will
      identify which are missing.

      Note that routing different sessions of them, for example.

                           |
            Send           |      Reserve              Receive
                           |
                           |       ________
    DF( 1,{B}; S1) <- (a) the session group
      differently will generally result in delays in establishing or
      rejecting the desired QoS.  A "bundling" facility could be added
      to multicast routing, to force all sessions in a session group to
      be routed along the same path.

      D.2.1 Resv Messages

         Add:

          [ <SESSION_GROUP> ]

         after the SESSION object.

      D.2.2 SESSION_GROUP Class

         SESSION_GROUP class = 2.

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

              +-------------+-------------+-------------+-------------+
              |  (c)               IPv4 Reference DestAddress              |  S1{B}
              +-------------+-------------+-------------+-------------+
              |  (c) <- DF( 2,{B}; S1, S2)      Session_Group ID     |      |________|    Count    |     Rank    |  S2{B}
              +-------------+-------------+-------------+-------------+

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

              +-------------+-------------+-------------+-------------+
              |                                                       |      |________|
              +                                                       +
              |
   ------------------------|-------------------------------------------                                                       |       ________
    DF( 2,{B}; S2) <- (b)
              +               IP6 Reference DestAddress               +
              |  (d)                                                       |  S1{B}
              +                                                       +
              |   (d) <- DF( 2,{B}; S1)                                                       |      |________|
              +-------------+-------------+-------------+-------------+
              |      Session-Group ID     |   ?{B}    Count    |     Rank    |      |________|

               Figure 15: Dynamic-Filter Reservation Example

         A router should not reserve more Dynamic-Filter channels than
         the number of upstream sources (three,
              +-------------+-------------+-------------+-------------+

         The variables are defined in the router of Figure
         15).  Since there is only one source upstream from previous hop
         (a), the first parameter of the above.

   D.3 DF message (the count of
         channels to be reserved) was decreased Style (Experimental)

      In addition to 1 in the forwarded
         reservations.  However, WF and FF styles defined in this is unnecessary, because the
         routers upstream will reserve only one channel, regardless.

         When 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 reservation is received, it style is labeled experimental.

      D.3.1 Reservation Styles

         A Dynamic-Filter (DF) style reservation makes "distinct"
         reservations with the IP
         address of the next hop (RSVP-capable) router, downstream "wildcard" scope, but it decouples
         reservations 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 filters.

         o    Each DF RESV messages for reservation request specifies a given
         session.  The number N' D of DF channels reserved on an outgoing
         interface
              distinct reservations using the same specified flowspec.
              These reservations are distributed with wildcard  scope,
              i.e., to all senders.

              The number of reservations that are actually made in a
              particular node is given by the formula:

         N' D' = min( D1+D2+...Dn, Ns), min(D,Ns), where Di Ns is the D value (channel reservation count) in a RESV
         from total
              number of senders upstream of the ith next-hop node.

         For

         o    In addition to D and the flowspec, a DF style reservation request with
              may also specify a Dynamic Reservation Count =
         C, RSVP should call TC_AddFlowspec C times.

      D.3.3 Resv Messages

         Add the following sequence:

             <flow descriptor list> ::=

                         <FLOWSPEC> <filter spec list>

      D.3.4 STYLE Class

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

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

              Style ID

                   4 = Dynamic-Filter (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 list of channels K filterspecs, for some K in
              the range: 0 <= K <= D'.  These filterspecs define
              particular senders to be reserved use the D' reservations, and this
              list establishes the scope for the filter specs.

              Once a Dynamic
                   Filter style reservation.  This integer value must
                   not less than DF reservation has been established, the number receiver
              may change the set of FILTER_SPEC objects in
                   filter spec list.

   D.4 Semantic Fragmentation

      Long RSVP messages are fragmented into MTU-sized packets when they
      are sent filterspecs to specify a different
              selection of senders, without a new admission control
              check (assuming D' and reassembled upon receipt. the common flowspec remain
              unchanged).  This is normally expected known as "channel switching", in
              analogy with a television set.

         In order to be done at provide assured channel switching, each node along
         the RSVP layer, but path must reserve enough bandwidth for all D' channels,
         even though some of this bandwidth may also occur be unused at any one
         time.  If D' changes (because the IP layer
      (when fragmentation occurs within a non-RSVP cloud).  It is well
      known that such "linear fragmentation" amplifies receiver changed D or because
         the effect number Ns of
      packet loss.  There upstream sources changed), or if the common
         flowspec changes, the refresh message is some concern treated as a new
         reservation that this could result in lost
      RSVP state across congested paths through non-RSVP clouds.

      One way is subject to avoid this problem would be admission control and may fail.

         The DF style allows a receiver to use "semantic"
      fragmentation, exploiting the structure switch channels without
         danger of an RSVP message.  With
      semantic fragmentation, admission denial due to limited resources (unless
         a topology change reroutes traffic along a lower-capacity path
         or new senders appear), once the state information that would initial reservations have been
      packed into one large message is sent
         made.  This in multiple packets, each of
      which is constructed to be logically complete.  Upon receipt, each
      packet can be processed independently of turn implies that the other packets, DF style creates
         reservations that may not be in use at any given time.

         The DF style is compatible with
      no explicit reassembly required.

      Semantic fragmentation causes some redundancy of information; for
      example, each packet of a RESV message must include SESSION,
      NHOP/PHOP, TIME_VALUES, and STYLE objects.  More importantly, the
      rules for semantic fragmentation are complex, since a single RESV
      message may contain two unbounded lists, and different styles
      require different rules.  Finally, FF style but not the largest atomic message must
      still fit into WF or
         SE style.

      D.3.2 Examples

         To give an MTU-sized packet, leading to a complex set example of
      limits on the sizes 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 individual objects.  At present, most
      objects are known channels to be small, but POLICY_DATA objects are
      variable and may reserved,
         each using common flowspec r.  It also carries a list, perhaps grow large.
         empty, of filterspecs defining senders.

         Figure 13 shows an example of Dynamic-Filter reservations.  The text
         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 this section describes (some of) the rules for
      semantic fragmentation.  It 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 removed 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 13: Dynamic-Filter Reservation Example

         A router should not reserve more Dynamic-Filter channels than
         the main body number of upstream sources (three, in the document, but is kept here for futur consideration.

      D.4.1 Semantic Fragmentation router of RESV Messages

         An outgoing RESV message that Figure
         13).
          Since there is too large for only one source upstream from previous hop (a),
         the MTU first parameter of the
         interface can be sent as multiple messages, as follows:

         o    For FF style, the flow descriptor list can DF message (the count of channels to
         be split as
              required reserved) was decreased to fit; 1 in the rest of forwarded reservations.
         However, this is unnecessary, because the message should be
              replicated into each packet.

         o    For WF style, routers upstream will
         reserve only one channel, regardless.

         When a SCOPE object containing an explicit list
              of sender IP addresses  can be split as required to fit; DF reservation is received, it is labeled with the rest IP
         address of the message should be replicated into each
              packet.

         o    For SE style, the flow descriptor list can be split as
              required to fit; next hop (RSVP-capable) router, downstream from
         the rest of current node.  Since the message should outgoing interface may be
              replicated into each packet.

              If directly
         connected to a single SE descriptor is too large shared medium network or to fit, its filter
              spec list can similarly be split as required.  However,
              the subsets of a particular filter spec list must each non-RSVP-capable
         router, there may be
              enclosed in TAG objects carrying 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 same tag value, so formula:

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

         where Di is the receiver will be able to match each FILTER_SPEC object
              to D value (channel reservation count) in a RESV
         from the appropriate shared reservation.

      D.4.2 TAG class

         TAG class ith next-hop node.

         For a DF reservation request with a Dynamic Reservation Count = 15.
         C, RSVP should call TC_AddFlowspec C times.

      D.3.3 Resv Messages

         Add the following sequence:

             <flow descriptor list> ::=

                         <FLOWSPEC> <filter spec list>

      D.3.4 STYLE Class

         o    TAG    STYLE-DF object: Class = 15, 8, C-Type = 1 2

              +-------------+-------------+-------------+-------------+
              |                       Tag Value Style ID=4  |
              +-------------+-------------+-------------+-------------+   Attribute Vector  0...0101001b        |
              +-------------+-------------+-------------+-------------+
              |
              //                   Tagged Sublist                    //    //////       ///////   |    Dynamic Resv Count     |
              +-------------+-------------+-------------+-------------+

              Tag Value
              +-------------+-------------+---------------------------+

              Style ID

                   4 = Dynamic-Filter (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 value number of the tag being attached channels to the objects in
                   the Tagged Sublist.  The tag value is unique be reserved 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).

              A TAG object encloses a list of one or more objects and
              attaches a logical name or "tag" value to them.  The tag Dynamic
                   Filter style reservation.  This integer value is unique to the next/previous hop and the session
              (specified by HOP and SESSION objects, respectively).  The
              enclosed object list is the "tagged sublist", and the
              objects in it said to be "tagged" with the tag value.
              Objects in a particular tagged sublist must all have the
              same class-num.

              Tagged objects with the same tag value are declared to be
              logically related, i.e., to be members of some larger
              logical set of objects.  Note that the tagged sublist
              implies no ordering; it defines only a set of objects.

              The meaning of the logical relationship depends upon
                   not less than the
              class-num number of the tagged objects. 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.

[FJ94]  Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing
    Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2,
    April, 1994.

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

[Katz95]  Katz, D., "IP Router Alert Option", Internet Draft draft-
    katz-router-alert-01.txt, Cisco Systems, November 16, 1995.

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

Security Considerations

   See Section 2.5. 2.7.

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