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

                Resource ReSerVation Protocol (RSVP) --

                   Version 1 Functional Specification

                           November 22, 1995

                           February 12, 1996

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 ........................................................4
   1.1 Data Flows ......................................................8 ......................................................7
   1.2 Reservation Model ...............................................9 ...............................................8
   1.3 Reservation Styles ..............................................11 ..............................................10
   1.4 Examples of Styles ..............................................14 ..............................................13
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 ..........................................................25
   2.7 Confirmation ....................................................27
   2.8 Policy and Security .............................................27
   2.8
   2.9 Automatic RSVP Tunneling ........................................28
   2.9
   2.10 Host Model ......................................................28 .....................................................29
3. RSVP Functional Specification .......................................30 .......................................31
   3.1 RSVP Message Formats ............................................30 ............................................31
   3.2 Sending RSVP Messages ...........................................42 ...........................................44
   3.3 Avoiding RSVP Message Loops .....................................44 .....................................45
   3.4 Blockade State ..................................................49
   3.5 Local Repair ....................................................48
   3.5 ....................................................51
   3.6 Time Parameters .................................................48
   3.6 .................................................52
   3.7 Traffic Policing and TTL ........................................50
   3.7 Non-Integrated Service Hops ................53
   3.8 Multihomed Hosts ................................................51
   3.8 ................................................54
   3.9 Future Compatibility ............................................52
   3.9 ............................................56
   3.10 RSVP Interfaces .................................................55 ................................................58
4. Message Processing Rules ............................................65 ............................................70
5. Acknowledgments .....................................................89
APPENDIX A. Object Definitions .........................................82 .........................................90
APPENDIX B. Error Codes and Values .....................................97 .....................................106
APPENDIX C. UDP Encapsulation ..........................................101
APPENDIX D. Experimental and Open Issues ...............................103 ..........................................111
   What's Changed

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

      o    The role and interpretation handling of reservation errors has been fundamentally
           changed, to prevent the IP Protocol Id is changed.
           The Protocol Id "second killer reservation problem".
           A new kind of state has been introduced into a node,
           "blockade state", which is now created by a required part of the session
           definition, RERR message with
           Error Code = 01, and filter specs which controls the merging process for
           generating reservation refresh messages [Sections 2.6 and sender templates
           3.4].

      o    RSVP now assume carries two flag bits in the Protocol Id from SESSION object to
           indicate to a receiver whether there are non-RSVP-capable
           nodes along the session rather than stating it
           explicitly. path to a given sender [Sections 2.9 and
           3.7].

      o    A "soft" reservation confirmation message    The optional INTEGRITY object is added. now specified to immediately
           follow the common header and to appear in every fragment
           [Section 3.1].

      o    There are now two flag bits in an ERROR_SPEC object: InPlace
           and NotGuilty [Section 3.10].

      o    The text now states explicitly that an erroneous reservation implementations should be as
           permissive as possible in accepting objects in any order
           within a message (and required ordering is not forwarded.  A mechanism to allow specified), but
           they should follow the BNF-implied order in creating a receiver
           more flexible control over forwarding
           message.

      o    The text now states that IP fragmentation of its messages after
           an admission control failure has not been designed and data packets is
           therefore
           generally not included possible when RSVP is in this version of use, since the protocol. TCP/UDP
           port fields may be required for classification [Section 1.2].

      o    A terminology confusion is eliminated.    The term "scope" was
           used both rules for a set of senders and for a set of sender hosts.
           A new term "sender selection" is introduced for the first,
           leaving "scope" for the second.

      o    The FILTER_SPEC handling an unrecognized object is dropped from a wildcard sender
           selection (WF) style reservation, which now selects "all
           senders" without qualification.

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

      o    An SE style flow descriptor is simplified class are
           changed to include a single
           flowspec.

      o    The IP Router Alert option is now required in PATH, PTEAR,
           and RACK messages.

      o    The TIME_VALUES object is now required in RESV third possibility: ignore and PATH
           messages; there is no default.

      o    Policing at branch points is now defined in a new section on
           policing (3.6).

      o    A 2-second delay is inserted into local repair.

      o    Merging of SE with WF objects is no longer allowed.

      o    The Rmax end-to-end bound on do not
           forward the refresh rate R is removed,
           since its utility was unclear.

      o    A rule for randomizing refresh timeouts is included.

      o    The suggestion that TCP could be used for carrying RSVP state
           through a congested non-RSVP cloud is removed.

      o    SENDER_TSPECS are now required in PATH| messages. object [Section 3.9].

      o    There    All generic Traffic Control calls are new sections on multihomed hosts (3.7) and future
           compatibility (3.8).  The latter section makes clear that a
           message containing modified to include an object with unknown C-Type should
           interface specification, allowing the Thandle to be
           rejected.  Any more forgiving treatment seems too complex.
           interface-specific [Section 3.10.2].

      o    Appendix C on UDP encapsulation    Disabling an interface for RSVP is completely changed.

      o    Some text was rearranged in Sections 1 and 2. allowed [Section 3.10.3].

1. Introduction

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

   On

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

   RSVP requests resources for simplex data streams, i.e., it requests
   resources in only one direction.  Therefore, RSVP treats a sender is as
   logically distinct from a receiver, although the same application
   process may act as both a sender and a receiver at the same time.
   RSVP operates on top of 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.
   protocol, like ICMP, IGMP, or routing protocols.  Like the
   implementations of routing and management protocols, an
   implementation of RSVP will typically execute in the background, not
   in the data forwarding path, as shown in Figure 1.

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

            HOST                             ROUTER

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

                  Figure 1: RSVP in Hosts and Routers

   Each router node that is capable of resource reservation passes incoming
   data packets through a packet classifier and then queues them as
   necessary in a packet scheduler.  The packet classifier "packet classifier", which determines the
   route and the QoS class for each packet.  There is  For each outgoing
   interface, a scheduler " packet scheduler" then makes forwarding decisions for
   each interface, packet to allocate resources for transmission achieve the promised QoS on the particular link-layer
   medium used by 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.
   This mapping to the link layer QoS may be accomplished in a number of
   possible ways; the details will be medium-dependent.  On a QoS-
   passive medium such as a leased 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, RSVP makes receivers responsible for
   requesting resource reservations QoS [RSVP93].  A QoS request, which typically originates
   from a receiver host application, is passed to the local RSVP
   implementation, shown as a user daemon process in Figure 1.  The RSVP
   protocol then carries the request to all the nodes (routers and
   hosts) along the reverse data path(s) to the data source(s).

   At each node, the RSVP daemon communicates with a two local decision
   module, called
   modules, "admission control", to determine if control" and "policy control".  Admission control
   determines whether the router can node has sufficient available resources to
   supply the requested QoS.  If the admission  Policy control check determines whether the user
   has administrative permission to make the reservation.  If both
   checks succeeds, the RSVP daemon sets parameters in the packet
   classifier and scheduler to obtain the desired QoS.  If the admission control either check
   fails, the RSVP program immediately returns an error 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 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.  That is, RSVP sends periodic refresh messages to
   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 Appendix A
   for more details.

   In summary, RSVP has the following attributes:

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

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

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

   o    RSVP maintains "soft state" in the routers, providing graceful
        support for dynamic membership changes and 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.  Section 3 contains the functional specification of RSVP,
   while Section 4 presents explicit message processing rules.  Appendix
   A defines the variable-length typed data objects used in the RSVP
   protocol.  Appendix B defines error codes and values.  Appendix C
   defines 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

      RSVP defines a "session" as a data flow with a particular
      destination and transport-layer protocol.  The destination for of a
      particular
      session is generally defined by DestAddress, the IP destination
      address of the data packets, and perhaps by DstPort, a
      " generalized
      "generalized destination port", i.e., some further demultiplexing
      point in the transport or application protocol layer.  RSVP treats
      each session independently, and this document often assumes the
      qualification "for the same session".

      DestAddress is a group address for multicast delivery or the
      unicast address of a single receiver.  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
      extensible for greater generality, the present version supports
      only UDP/TCP ports as generalized ports.

      Note that it is not strictly necessary to include ports in the
      session definition when DestAddress is multicast, since different
      sessions can always have different multicast addresses.  However,
      destination ports are necessary to allow more than one unicast
      session to the same receiver host.

      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
      multicast routing.  Multicast distribution forwards a copy of each
      data packet from a sender Si to every receiver Rj; a unicast
      distribution session has a single receiver R.  Each sender Si and
      each receiver Rj may
      be running in a unique Internet host, or a single host may contain
      multiple senders and/or receivers, senders, distinguished by generalized source ports.

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

                 Figure 2: Multicast Distribution Session

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

   1.2 Reservation Model

      An elementary RSVP reservation request consists of a "flowspec"
      together with a "filter spec"; this pair is called a "flow
      descriptor".  The flowspec specifies a desired QoS.  The filter
      spec, together with a session definition, specifies specification, defines the set of
      data packets -- the "flow" -- to receive the QoS defined by the
      flowspec.  The flowspec is used to set parameters to the 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 QoS occurs at the place where the
      data enters the medium, i.e., at the upstream end of the link,
      although an RSVP reservation request originates from receiver(s)
      downstream.  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. flow.

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

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

      Because the UDP/TCP port numbers are used for packet
      classification, each router must be able to examine these fields.
      As a result, it is generally necessary to avoid IP fragmentation
      of a data stream for which a resource reservation is desired.

      RSVP reservation request messages originate at receivers and are
      passed upstream towards the sender(s).  When a reservation request
      is received at a  At each intermediate node,
      two general actions are taken. taken on the request.

      1.   Make a reservation

           The flowspec and the filter spec are request is passed to traffic
           control.  Admission admission control determines the admissibility of
           the request (if it's new); if this and policy
           control.  If either test fails, the reservation is rejected
           and RSVP returns an error message to the appropriate
           receiver(s).  If admission control succeeds, both succeed, 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.   Forward the 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 from downstream, for two
      reasons.  First, it is possible in theory for the traffic control
      mechanism to modify the flowspec hop-by-hop, although none of the
      currently defined services does so.  Second, reservations for the
      same sender, or the same set of senders, from different downstream
      branches of the multicast tree(s) are "merged" as reservations
      travel upstream; that is, a node forwards upstream only the reservation
      request with the "maximum" flowspec.

      When a receiver originates a reservation request, it can also
      request a confirmation message to indicate that its request was
      (probably) installed in the network.  A successful reservation
      request propagates as far as the closest point(s) upstream along the sink multicast tree to the sender(s) until it
      reaches a point where there is an existing reservation level is equal or greater
      than that being requested.  At that point, the arriving request will be dropped in favor of is
      merged with the equal or larger reservation in place; place, and need not be forwarded
      further, and 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
      guarantee, that the requested service is in place all the way to
      the sender(s), as explained in Section 2.6. 2.7.

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

   1.3 Reservation Styles

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

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

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

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

                 Figure 3: Reservation Attributes and Styles

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

      o    Wildcard-Filter (WF) Style

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

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

               WF( * {Q})

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

      o    Fixed-Filter (FF) Style

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

           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 be merged
           to share a single reservation.

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

               FF( S{Q})

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

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

      o    Shared Explicit (SE) Style

           The SE style implies the options: "shared" reservation and "
           explicit" sender selection.  Thus, an SE-style reservation
           creates a single reservation into which flows from all
           upstream senders are mixed.  However, like the FF 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 S1, S2, etc.

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

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

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

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

   1.4 Examples of Styles

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

      Figure 4 shows schematically illustrates a router with two incoming interfaces through
      which data streams will 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 examples that
      follow.  There are three upstream senders; packets from sender S1
      (S2 and S3) arrive through previous hop (a) ((b), respectively).
      There are also three downstream receivers; packets bound for R1
      (R2 and R3) are routed via outgoing interface (c) ((d),
      respectively).  We furthermore assume that R2 and R3 arrive via
      different next hops, e.g., via the two routers D and D' in Figure
      9.  This illustrates the effect of a non-RSVP cloud or a broadcast
      LAN on interface (d).

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

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

                        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 reservation requests received over outgoing
      interfaces (c) and (d), and the "Reserve" column shows the
      resulting reservation state for each interface.   The "Send"
      column shows the reservation requests that are sent upstream to
      previous hops (a) and (b).  In the "Reserve" column, each box
      represents one reserved "pipe" on the outgoing link, with the
      corresponding flow descriptor.

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

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

              Figure 5: Wildcard-Filter (WF) Reservation Example

      Figure 6 shows Fixed-Filter (FF) style reservations.  The flow
      descriptors for senders S2 and S3, received from outgoing
      interfaces (c) and (d), are packed into the request forwarded to
      previous hop (b).  On the other hand, the three different flow
      descriptors for sender S1 are merged into the single request FF(
      S1{4B} ), which is sent to previous hop (a).  For each outgoing
      interface, there is a separate reservation for each source that
      has been requested, but this reservation is shared among all the
      receivers that made the 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 example of Shared-Explicit (SE) style
      reservations.  When SE-style reservations are merged, the
      resulting filter spec is the union of the original filter specs.

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

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

                       Router Configuration

                             |
               Send          |       Reserve              Receive
                             |
                             |       _______
         WF( *{rB} *{4B} ) <- (a)  |  (c) | * {B} | {4B}|   (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)".
      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). 2.9).  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 are 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 "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 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 specified for the session.

      o    Sender Tspec

           A PATH message is required to carry a Sender Tspec, which
           defines the traffic characteristics of the data 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. upstream links.

      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 in PATH messages sent downstream.

      For protocol efficiency, RSVP also allows multiple sets of
      reservation information for

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

   2.2 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 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 specify 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- UDP/TCP-
           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 requests from different next hops for the same session
      and with the same filter spec, but RSVP should install only one
      reservation on that interface.  This  The installed  reservation should
      have an effective flowspec that is the "maximum" "largest" 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"
      "largest" of the flowspecs requested by the different next hops.
      Both hops
      (however, in certain cases the "smallest" is taken rather than the
      largest, see Section 3.4).  These cases all represent flowspec
      merging.

      Merging flowspecs

      Flowspec merging requires calculating calculation of the "largest" of a set of
      flowspecs, which are otherwise opaque to RSVP.  Since
      flowspecs.  However, since flowspecs are multi-dimensional generally multi-
      dimensional vectors (they may contain both Tspec and Rspec
      components, each of which may itself be multi-dimensional),
      generally speaking they cannot it may
      not be possible to strictly ordered.  However, in
      many cases one can easily determine the "larger" of order two flowspecs,
      such as when both request the same bandwidth but one requests a
      tighter delay, or when flowspecs.  For example, if
      one of the two requests both request calls for a higher bandwidth and another calls for a
      tighter delay bound.  When the bound, one is not "larger" than the other.  In such
      a case, instead of taking the two
      cannot be determined, larger, RSVP must compute and use a
      third flowspec that is at least as large as each, i.e., a "least each.  Mathematically,
      RSVP merges flowspecs using the " least upper bound"
      (LUB).  If (LUB) instead
      of the two flowspecs maximum.  Typically, the LUB is calculated by creating a
      new flowspec whose components are incomparable, their comparison
      will treated as an error. individually either the max or
      the min of corresponding components of the flowspecs being merged.
      For example, the LUB of Tspecs defined by token bucket parameters
      is computed by taking the maximums of the bucket size and the rate
      parameters.  In several cases, the GLB (Greatest Lower Bound) is
      used instead of the LUB; this simply interchanges max and min
      operations.

      We can now give the complete rules for calculating the effective
      flowspec (Te, Re) to be installed on an interface.  Here Te is the
      effective Tspec and Re is the effective Rspec.  As an example,
      consider interface (d) in Figure 9.

      1.   Re is calculated as the largest (using an 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 of A, B, and B' in Figure 9)
           are summed; call this sum Path_Te.

      3.   The maximum Tspec supplied in RESV messages 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
           take the smaller of the bucket size and the rate parameters.

      Flowspecs, Tspecs, and Adspecs are opaque to RSVP.  Therefore, the
      last of these steps is actually performed by traffic control.  The
      definition and implementation of the rules for comparing
      flowspecs, calculating LUB's, LUBs and GLBs, and summing Tspecs are
      outside the definition of RSVP [ServTempl95a].  Section 3.9.4 3.10.4
      shows generic calls that an RSVP daemon could use for these
      functions.

   2.4 Soft State

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

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

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

      The state maintained by RSVP is dynamic; to change the set of
      senders Si or to change any QoS request, a host simply starts
      sending revised PATH and/or RESV messages.  The result should will be an
      appropriate adjustment in the RSVP state in all nodes along the
      path.

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

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

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

                         ________________
                      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 "teardown" messages remove path and reservation
      state immediately.  Although it is not necessary to explicitly
      tear down an old reservation, we recommend that all end hosts send
      a teardown request as soon as an application finishes.

      There are two types of RSVP teardown message, PTEAR and RTEAR.  A
      PTEAR message travels towards all receivers downstream from its
      point of initiation and deletes path state state, as well as all
      dependent reservation state, along the 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 reversed-sense Path message (Resv message,
      respectively).

      A teardown request may be initiated either by an application in an
      end system (sender or receiver), or by a router as the result of
      state timeout.  Once initiated, a teardown request must be
      forwarded hop-by-hop without delay.  A teardown message deletes
      the specified state in the node where it is received.  As always,
      this state change will be propagated immediately to the next node,
      but only if there will be a net change after merging.  As a
      result, an RTEAR message will prune the reservation state 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 unused state will eventually time out
      even though it is not explicitly deleted.  If a teardown message
      is lost, the router that failed to receive that message will time
      out its state and initiate a new teardown message beyond the loss
      point.  Assuming that RSVP message loss probability is small, the
      longest time to delete state will seldom exceed one refresh
      timeout period.

   2.6 Errors and Acknowledgments

      There are two RSVP error messages, RERR and PERR, PERR.  PERR messages
      are very simple.  They are simply sent upstream to the sender that
      created the error, and a
      reservation confirmation message RACK. they do not change path state in the nodes
      though which they pass.  There are only a few possible causes of
      path errors.

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

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

      2.   Administrative policy may prevent the requested reservation.

      3.   There may be no matching path state, so that the request
           cannot be forwarded towards the sender(s).

      4.   A reservation style that requires the explicit selection of a
           unique sender may have a filter spec that is ambiguous, i.e.,
           that matches more than one sender in the path state, due to
           the use of wildcard fields in the filter spec.

      5.   The requested style may be incompatible with the style(s) of
           existing reservations.  The incompatibility may occur among
           reservations for the same session on the same outgoing
           interface, or among effective reservations on different
           outgoing interfaces.

      In any of these cases, a RERR message is returned to the
      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 affected receivers.  An error
      message does not modify state in the nodes through which it
      passes.  Therefore, any reservations established downstream of the
      node where the failure occurred will persist until the responsible
      receiver(s) explicitly tear down the state or allow it to time
      out.

      In this version of RSVP, detection

      The handling of an error in a reservation
      request not only generates a RERR message, it also prevents the messages is somewhat complex (Section 3.4).
      Since a request from being forwarded further.  This that fails may not always be the
      desirable behavior; for example, result of merging a receiver may want number
      of requests, a reservation
      request error must be reported to propagate all of the way to
      responsible receivers.  In addition, merging heterogeneous
      requests creates a potential difficulty known as the sender despite an
      admission control failure at "killer
      reservation" problem, in which one request could deny service to
      another.  There are actually two killer-reservation problems.

      1.   The first killer reservation problem (KR-I) arises when there
           is already a particular link along reservation Q0 in place.  If another receiver
           now makes a larger reservation Q1 > Q0, the path.
      However, design result of the appropriate mechanism has proved difficult, merging
           Q0 and therefore this version take the simplest approach.

      When Q1 may be rejected by admission control in some
           upstream node.  This must not deny service to Q0.

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

      2.   The second killer reservation from disrupting problem (KR-II) is the existing QoS by merging
      with an existing reservation and then failing admission control
      (this has been called
           converse: the "killer reservation" problem).

      To request receiver making a confirmation for its reservation request, Q1 is persistent
           even though Admission Control is failing for Q1 in some node.
           This must not prevent a different receiver
      Rj includes in the RESV message from now
           establishing a confirmation-request object
      containing its IP address.  At smaller reservation Q0 that will succeed.

           To solve this problem, a RERR message establishes additional
           state, called "blockade state", in each merge point, only node through which it
           passes.  Blockade state in a node modifies the largest merging
           procedure to omit the offending flowspec and any accompanying confirmation-request object is
      forwarded upstream.  If (Q1 in the reservation request example)
           from Rj is equal
      to or smaller than the reservation in place on merge, allowing a node, its RESV
      are not smaller request to be forwarded further,
           and if the RESV included an
      confirmation-request object, a RACK message established.  The Q1 reservation state is sent back said to Rj.
      This mechanism has the following consequences:

      o be
           "blockaded".  Detailed rules are presented in Section 3.4.

      A new reservation request with a flowspec larger than any that fails Admission Control creates
      blockade state but is left in place for a session will normally result in either a RERR or
           a RACK message back to nodes downstream of the receiver
      failure point.  It has been suggested that these reservations
      downstream from each sender.  In
           this case, the RACK message failure represent "wasted" reservations and
      should be timed out if not actively deleted.  However, in general
      the downstream reservations will not be an end-to-end
           confirmation. "wasted".

      o    The receipt of    There are two possible reasons for a RACK gives no guarantees.  Assume receiver persisting in a
           failed reservation: (1) it is polling for resource
           availability along the first
           two reservation requests from receivers R1 and R2 arrive at entire path, or (2) it wants to obtain
           the node where they are merged.  R2, whose reservation was desired QoS along as much of the path as possible.
           Certainly in the second case, and perhaps in the first case,
           the receiver will want to arrive at that node, may receive a RACK from
           that node while R1's request hold onto the reservations it has
           made downstream from the failure.

      o    If these downstream reservations were not yet propagated all retained, the
           way
           responsiveness of RSVP to certain transient failures would be
           impaired.  For example, suppose a matching sender and may still fail.  In this case,
           R2 will receive a RACK although there route "flaps" to an
           alternate route that is no end-to-end congested, so an existing reservation
           suddenly fails, then quickly recovers to the original route.
           The blockade state in place.  Furthermore, if each downstream router must not remove
           the two flowspecs are
           equal, R2 may receive a RACK followed by a RERR.  However, if state or prevent its flowspec is smaller, R2 will receive only the RACK. immediate refresh.

      o    Despite these uncertainties, receipt of    If we did not refresh the downstream reservations, they might
           time out, to be restored every Td seconds.  Such on/off
           behavior might be very distressing for users.

   2.7 Confirmation

      To request a RACK indicates confirmation for its reservation request, a
           high probability that receiver
      Rj includes in the RESV message a confirmation-request object
      containing Rj's IP address.  At each merge point, only the largest
      flowspec and any accompanying confirmation-request object is
      forwarded upstream.  If the reservation request from Rj is equal
      to or smaller than the reservation in place. place on a node, its RESV
      are not forwarded further, and if the RESV included a
      confirmation-request object, a RACK message is sent back to Rj.
      This mechanism has the following consequences:

      o    Finally, note that    A new reservation request with a flowspec larger than any in
           place for a session will normally result in either a RERR and/or or
           a RACK messages may message back to the receiver from each sender.  In
           this case, the RACK message will be lost.

   2.7 an end-to-end
           confirmation.

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

   2.8 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 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" 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, there will be policy control as well as admission
      control at each node is likely to contain a
      policy component in addition to a resource reservation component. over the establishment of reservations.  As input to the policy-based admission decision,
      policy control, RSVP messages may carry policy data.  This  Policy data
      may include credentials identifying users or user classes, account
      numbers, limits, quotas, etc.  Like flowspecs, policy data will be
      opaque to RSVP, which will simply pass it to a "Local Policy
      Module" (LPM) for a decision.

      To protect the integrity of the policy-based admission policy 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 neighbor RSVP-capable nodes.  These objects are expected to contain an encrypted part use a
      keyed cryptographic digest technique and to assume that RSVP
      neighbors share a
      shared secret between neighbors. [Baker96].

      User policy data in reservation request messages presents a
      scaling problem.  When a multicast group has a large number of
      receivers, it will be impossible or undesirable to carry all
      receivers' policy data upstream to the sender(s).  The policy data
      will have to be administratively merged at places near the
      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 fields will allow upstream
      nodes to accept these tokens.

      In summary, different administrative domain domains 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.8 Automatic RSVP Tunneling

      This document does not specify the contents of policy data, the
      structure of an LPM, or any generic policy models.  These will be
      defined in the future.

   2.9 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.  However, if such a cloud has sufficient
      capacity, it may still provide acceptable realtime service.

      RSVP automatically 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 next RSVP-capable node the IP
      address of the last RSVP-capable router before entering the cloud.
      This effectively constructs a 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.

      Even though RSVP operates correctly through a non-RSVP cloud, the
      non-RSVP-capable nodes will in general perturb the QoS provided to
      a receiver.  Therefore, RSVP tries to inform the receiver when
      there are non-RSVP-capable hops in the path to a given sender, by
      means of two flag bits in the SESSION object of a PATH message;
      see Section 3.7 and Appendix A.

      Some interconnection topologies of RSVP routers and non-RSVP routers can cause
      RESV messages to arrive at the wrong RSVP-capable node, or to
      arrive at the wrong interface at of 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
      address of one of the local interfaces.  If so, the reservation
      should be made on the addressed interface, even if it is not the
      one on which the message arrived.  If the destination
      address does not match any local interface and the message is not
      a PATH or PTEAR, it should the message must be forwarded without further
      processing by this node.

   2.9  When a RESV message does arrive at the
      addessed node, the IP destination address (or the LIH, defined
      later) must be used to determine the interface to receive the
      reservation.

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

      H3   A receiver application receives a PATH message.

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

      H5   A sender application receives a RESV message.

      H6   A sender starts sending data packets.

      There are several synchronization considerations.

      o    H1 and H2 may happen in either order.

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

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

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

           The receiver may simply choose to ignore such error messages,
           or it may avoid them by waiting for PATH messages before
           sending RESV messages.  [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 3.9.1 3.10.1 discusses the general requirements and
      presen
      outlines a generic interface.

3. RSVP Functional Specification

   3.1 RSVP Message Formats

      An RSVP message or message fragment consists of a common header followed by header,
      an optional integrity-check data structure, and a body consisting
      of a variable number of variable-length, typed "objects".  The
      integrity-check data structure is itself an object, of class
      INTEGRITY [Baker96].  In a fragmented message, INTEGRITY objects
      must occur either in every fragment or else in no fragment.
      Fragmentation of a message allows division of an object across two
      (or more) successive fragments.

      The following subsections that
      follow define the formats of the common header,
      the object structures, and each of the RSVP message types. For
      each RSVP message type, there is a set of rules for the
      permissible choice and ordering of object types.  These rules are specified
      using Backus-Naur Form (BNF) augmented with square brackets
      surrounding optional sub-sequences.

      3.1.1 Common Header

                0             1              2             3
         +-------------+-------------+-------------+-------------+
         | Vers | Flags|    Type  The BNF implies an order for
      the objects in a message.  However, in many (but not all) cases,
      object order makes no logical difference.  An implementation
      should create messages with the objects in the order shown here,
      but accept the objects in any order except where the order is
      logically required (as noted in the following).

      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 is version 1.

         Flags: 4 bits

              (None defined yet)
              0x01 = INTEGRITY object present

                   This flag indicates that an INTEGRITY object follows
                   immediately after the common header.  The use of the
                   INTEGRITY object is described in [Baker96].

              0x02 = UDP': UDP encapsulation marker flag

                   This flag is reserved for use by UDP encapsulation
                   [Appendix C].

         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 one's complement of the contents one's complement sum of the RSVP
              message,
              message (fragment), with the checksum field replaced by zero.
              zero for the purpose of computing the checksum.  An all-
              zero value means that no checksum was transmitted.

         RSVP Length: 16 bits

              The total length of this RSVP packet in bytes, including
              the common header and the variable-length objects that
              follow.  If the MF flag is on or the Fragment Offset field
              is non-zero, this is the length of the current fragment of
              a larger message.

         Send_TTL: 8 bits

              The IP TTL value with which the 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 low-order bit of a byte; the seven high-
              order bits are reserved.  It is on for all but the last
              fragment of a message.

         Fragment Offset: 24 bits

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

      3.1.2 Object Formats

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

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

         An object header has the following fields:

         Length

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

         Class-Num

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

              NULL

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

              SESSION

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

              RSVP_HOP

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

              TIME_VALUES

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

              STYLE

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

              FLOWSPEC

                   Defines a desired QoS, in a RESV message.

              FILTER_SPEC

                   Defines a subset of session data packets that should
                   receive the desired QoS (specified by 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 PATH message.

              SENDER_TSPEC
                   Defines the traffic characteristics of a 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
                   administratively permitted.  May appear in a PATH or
                   RESV message.

              INTEGRITY

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

              SCOPE

                   An explicit list of 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 maximum object content length is 65528 bytes.  The Class-
         Num and C-Type fields may be used together as a 16-bit number
         to define a unique type for each object.

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

      3.1.3 Path Message Messages

         Each sender host periodically sends a PATH message containing a
         description of each data stream it originates.  The PATH
         message travels from a sender to receiver(s) along the same
         path(s) used by the data packets.  The IP source address of a
         PATH message is an address of the sender it describes, while
         the destination address is the DestAddress for the session.
         These addresses assure that the message will be correctly
         routed through a 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 application process as
         the sender.

         The format of a PATH message is as follows:

           <Path Message> ::= <Common Header> <SESSION> <RSVP_HOP> [ <INTEGRITY> ]

                                     <SESSION> <RSVP_HOP>

                                     <TIME_VALUES>

                                     <sender descriptor>

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

                                    [ <POLICY_DATA> ]   [ <ADSPEC> ]

         If the INTEGRITY object is present, there must be an INTEGRITY
         object immediately following the common header in every
         fragment of the message, in this and all other messages.  The
         objects included in the sender descriptor must occur after all
         other objects in the message.

         The PHOP (i.e., the RSVP_HOP) object of each PATH message
         contains the address of the interface through which the PATH
         message was most recently sent.  The SENDER_TEMPLATE object
         defines the format of data packets from this sender, while the
         SENDER_TSPEC object specifies the traffic characteristics of
         the flow.  Optionally, there may be a POLICY_DATA object
         specifying user credential and 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 SESSION
         objects.  Any POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are
         also saved in the path state.  If an error is encountered while
         processing a PATH message, a PERR message is sent to the
         originating sender of the PATH message.  PATH messages must
         satisfy the rules on SrcPort and DstPort in Section 2.2.

         Periodically, the RSVP daemon at a node scans the path state to
         create new PATH messages to 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 some
         routing protocols also upon the source (sender's IP) address.
         The routing information generally includes the list of none or
         more outgoing interfaces to which the PATH message to be
         forwarded.  Because each outgoing interface has a different IP
         address, the PATH messages sent out different interfaces
         contain different PHOP addresses.  In addition, any ADSPEC or
         POLICY_DATA objects carried in PATH messages 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 multicast group.  Whenever this
         information is available, RSVP should check the incoming
         interface of each PATH message and immediately discard those
         messages that have arrived on the wrong interface.

      3.1.4 Resv Messages

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

         The RESV message format is as follows:

           <Resv Message> ::= <Common Header> <SESSION>  <RSVP_HOP> [ <INTEGRITY> ]

                                   <SESSION>  <RSVP_HOP>

                                   <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 message is was sent.  The
         appearance of a RESV_CONFIRM object signals a request for a
         reservation confirmation and carries the IP address of the
         receiver to which the RACK should be sent.  The S_POLICY_DATA
         object is a POLICY_DATA object that is associated with the
         entire session.  There may also be flow-specific
         POLICY_DATA F_POLICY_DATA
         objects, as described below.

         The STYLE object followed by the flow descriptor list must
         occur at the end of the message.

         The BNF above defines a flow descriptor list as simply a list
         of flow descriptors.  The following style-dependent rules
         specify in more detail the composition of a valid flow
         descriptor list for each of the reservation styles. styles; the order
         shown must be used.

         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 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 appeared in
              the list; the first FF flow descriptor must contain a
              FLOWSPEC.

              Each flow descriptor in the list must be processed
              independently, and a separate RERR message must be
              generated for each one that is in error.

         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 shared
              reservation, optionally a POLICY_DATA object, and a list
              of FILTER_SPEC objects.

         The reservation scope, i.e., the set of senders towards which a
         particular reservation is to be forwarded, is determined as
         follows:

         o    Explicit sender selection

              Match

              Select a particular sender by matching each FILTER_SPEC
              object against the path state created from SENDER_TEMPLATE objects to select a
              particular sender.
              objects.  An ambiguous match, i.e., a FILTER_SPEC matching
              more than one SENDER_TEMPLATE (e.g. through use of a
              wildcard port), is an error.  Any SCOPE
              object associated with the reservation should be ignored
              in this case.

         o    Wildcard sender selection

              All senders that route to the given outgoing interface
              match this request.  A SCOPE object, if present, contains
              an explicit list of sender IP addresses.  If there is no
              SCOPE object, the scope is determined by the relevant set
              of senders in the path state.

              Whenever a RESV message with wildcard sender selection is
              forwarded to more than one previous hop, a SCOPE object
              must be included in the message.  See Section 3.3 below.

      3.1.5 Error and Confirmation Teardown Messages

         There are three two types of RSVP error/confirmation messages. Teardown message, PTEAR and RTEAR.

         o    PERR messages result from PATH messages    A PTEAR message deletes path state (which in turn deletes
              any reservation state for that sender) and travel travels towards
              senders.  PERR messages
              all receivers that are routed hop-by-hop using the
              path state; at each hop, downstream from the IP destination address initiating
              node.  A PTEAR message is the
              unicast address of routed like a previous hop.

         o    RERR messages result from RESV messages PATH message, and travel towards
              the appropriate receivers.  They are routed hop-by-hop
              using the reservation state; at each hop, the
              its IP destination address is DestAddress for the unicast address of a next-hop
              node. session.

         o    RACK messages are sent to (probabilistically) acknowledge    A RTEAR message deletes reservation requests. state and travels
              towards all matching senders upstream from the initiating
              node.  A RACK RTEAR message is sent as the
              result of the appearance of a RESV_CONFIRM object routed in the same way as a
              corresponding RESV message, and contains a copy of that RESV_CONFIRM.
              The RACK message its IP destination address
              is sent to the unicast address of a
              receiver host; the address is obtained from the
              RESV_CONFIRM object.  A RACK message is forwarded to the
              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 such events may be useful.

         None of these messages modify the state of any node through
         which they pass; instead, they are only reported to the end
         application.

           <PathErr message> previous hop.

             <PathTear Message> ::= <Common Header> [<INTEGRITY>]

                                         <SESSION>

                                       [ <INTEGRITY> ]  <ERROR_SPEC> <RSVP_HOP>

                                         <sender descriptor>

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

           <ResvErr

             <ResvTear Message> ::= <Common Header> [<INTEGRITY>]

                                         <SESSION>

                                       [ <INTEGRITY> ]  <ERROR_SPEC>

                                       [S_POLICY_DATA] <RSVP_HOP>

                                         [ <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 RESV_CONFIRM object

         FLOWSPEC or POLICY_DATA objects in the flow descriptor list of
         a RACK RTEAR message will be ignored and may be omitted.  The order
         requirements for sender descriptor, STYLE object, and flow
         descriptor list are as given earlier for PATH and RESV
         messages.

         Note that, unless it is a copy of accidentally dropped along the
         object way, a
         PTEAR message will reach all receivers down stream from its
         origination.  On the RESV other hand, a RTEAR message that triggered will cease to
         be forwarded at the confirmation.

         The following style-dependent rules define same node where merging suppresses
         forwarding of the composition corresponding RESV messages.  In each node N
         along the way, if the RTEAR message causes the removal of all
         state for this session, N will create a
         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 new teardown message to
         be propagated further upstream; otherwise, the error and includes RTEAR message
         may result in the IP
         address immediate forwarding of a modified RESV
         refresh message.

         Deletion of path state as the node that detected the error (Error Node
         Address).  POLICY_DATA objects are included in error messages
         in cases where they may provide relevant information (i.e.,
         when an administrative failure is being reported).  In result of a RACK
         message, the ERROR_SPEC is used only PTEAR message or a
         timeout must cause any adjustments in related reservation state
         required to carry the IP address of
         the originating node, maintain consistency in the Error Node Address; local node.  The
         adjustment in reservation state depends upon the error
         specification is a special value that indicates a confirmation.

         When a RESV message contains style.  For
         example, suppose a list of flow descriptors (e.g.,
         FF style), PTEAR deletes the RSVP implementation should process each flow
         descritor independently and return a separate RERR message path state for
         each that is in error.

         Generally speaking, a RERR message should be forwarded towards
         all receivers that may have caused sender S.
         If the error being reported.
         More specifically:

         o    The node that detects an error in a style specifies explicit sender selection (FF or SE),
         any reservation request
              sends with a RERR message to filter spec matching S should be
         deleted; if the next hop from which style has wildcard sender selection (WF), the
              erroneous
         reservation came.

              The message must contain should be deleted if S is the information required last sender to
              define the error and to route
         session.  These reservation changes should not trigger an
         immediate RESV refresh message, since the error message.  Routing
              requires PTEAR message have
         already made the required changes upstream.  However, at least the
         node in which a STYLE object and one or more
              FILTER_SPEC object(s) from RTEAR message stops, the erroneous RESV message.
              For an admission control failure, for example, the
              erroneous FLOWSPEC must be included. change of reservation
         state may trigger a RESV refresh starting at that node.

      3.1.6 Error Messages

         There are two types of RSVP error messages.

         o    Succeeding nodes forward    PERR messages result from PATH messages and travel
              upstream towards the RERR message senders.  PERR messages are routed
              hop-by-hop using their
              local reservation state, to the next hops of reservations
              that match the FILTER_SPEC(s) in path state; at each hop, the message.  For
              reservations with wildcard scope, there IP
              destination address is an additional
              limitation on forwarding RERR messages, to avoid loops;
              see Section 3.3.

         When the error is an admission control failure, unicast address of a node is
         allowed (but previous
              hop.  PERR messages do not required) to match the FLOWSPEC as well as the
         FILTER_SPEC object(s), to limit modify the distribution state of a RERR
         message any node
              through which they pass; instead, they are only reported
              to those receivers that `caused' the error.  Suppose
         that a sender application.

         o    RERR message contains a FLOWSPEC Qerr that is being
         matched against messages result from RESV messages and travel
              downstream towards the FLOWSPEC Qlocal in appropriate receivers.  They are
              routed hop-by-hop using the local reservation
         state in node N.  Qerr, which originated in a node upstream
         from N, resulted from merging of flowspecs that included
         Qlocal.  Generally, a RERR message can be forwarded to state; at each
              hop, the
         receiver(s) that specified IP destination address is the `biggest' flowspec.  The
         comparison unicast address of Qerr against
              a particular Qlocal to determine
         whether Qlocal qualifies as (one of) next-hop node.

         An error encountered while processing an error message must
         cause the `biggest', error message to be discarded without creating
         further error messages; however, logging of such events may be
         called `de-merging'.  As with merging, the  details of de-
         merging depend upon the service and the FLOWSPEC format, and
         are outside RSVP itself.

         A RERR message that is forwarded should carry the FILTER_SPEC
         from the corresponding reservation state (thus `de-merging' the
         filter spec).

         When a RERR or RACK message reaches a receiver, the STYLE
         object, flow descriptor list, and ERROR_SPEC object (which
         contains the LUB-Used flag) should be delivered to the receiver
         application.  In the case of an Admission Control error, the
         flow descriptor list will contain the FLOWSPEC object that
         failed.  If the LUB-Used flag is off, this should be
         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 (which in turn deletes
              the reservation state for that sender, if there is any)
              and travels towards all receivers that are downstream from
              the point of initiation.  A PTEAR message is routed like a
              PATH message, and its IP destination address is
              DestAddress for the session.

         o    A RTEAR message deletes reservation state and travels
              towards all matching senders upstream from the point of
              teardown initiation.  A RTEAR message is routed in the
              same way as a corresponding RESV message (using the same
              scope rules).  Its IP destination address is the unicast
              address of a previous hop.

             <PathTear Message>
         useful.

           <PathErr message> ::= <Common Header> <SESSION> <RSVP_HOP> [ <INTEGRITY> ]

                                      <SESSION> <ERROR_SPEC>

                                      <sender descriptor>

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

             <ResvTear

           <ResvErr Message> ::= <Common Header> <SESSION> <RSVP_HOP> [ <INTEGRITY> ]

                                      <SESSION> <ERROR_SPEC>

                                      [S_POLICY_DATA] [ <SCOPE> ]

                                    <STYLE> <flow descriptor list>

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

         FLOWSPEC or POLICY_DATA objects in the <error flow descriptor list of
         a RTEAR message will be ignored and may be omitted.

         Note that, unless it is accidentally dropped along the way, a
         PTEAR message will reach all the receivers down stream from its
         origination.  On descriptor>

         The ERROR_SPEC object specifies the other hand, a RTEAR message will cease to
         be forwarded at error and includes the same node where merging suppresses
         forwarding IP
         address of the corresponding RESV messages.  In each node N
         along that detected the way, if error (Error Node
         Address).  POLICY_DATA objects are included in error messages
         in cases where they may provide relevant information (i.e.,
         when an administrative failure is being reported).  The STYLE
         object is copied from the RTEAR RESV message causes the removal in error.  The use of all
         state for this session, N will create a new teardown message to
         be propagated further upstream; otherwise,
         the RTEAR SCOPE object in a RERR message
         may result is defined below in Section
         3.3.

         The following style-dependent rules define the immediate forwarding composition of a modified
         valid error flow descriptor; the object order requirements are
         as given earlier for a RESV
         refresh message.

         Deletion of path state as the result of

         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>

         Note that a PTEAR RERR message or contains only one flow descriptor.
         Therefore, a
         timeout RESV message that contains N > 1 flow descriptors
         (FF style) may force adjustments in related reservation state, create up to
         maintain state consistency in N separate RERR messages.

         Generally speaking, a RERR message should be forwarded towards
         all receivers that may have caused the local node. error being reported.
         More specifically:

         o    The adjustment node that detects an error in reservation state depends upon the style.  For example,
         suppose a PTEAR deletes the path state for a sender S.  If the
         style specifies explicit sender selection (FF or SE), delete
         any reservation with request
              sends a filter spec matching S; otherwise, RERR message to the
         style is wildcard sender selection (WF) and next hop from which the
              erroneous reservation
         should be deleted if S is came.

              This message must contain the last sender information required to
              define the session.
         These reservation changes should not trigger an immediate RESV
         refresh message, since error and to route the PTEAR error message have already made the
         required changes upstream.  However, at the node in which later
              hops.  It therefore includes an ERROR_SPEC object, a
         RTEAR message stops, the change copy
              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 used between an end system the STYLE object, and the first/last hop
      router, although it appropriate error flow
              descriptor.  If the error is also possible to encapsulate RSVP messages
      as UDP datagrams for end-system communication, as described an admission control failure,
              any reservation already in
      Appendix C.  UDP encapsulation is needed for systems that cannot
      do raw network I/O.

      PATH, PTEAR, and RACK messages must place will be sent with the Router Alert
      IP option [Katz95] left in their IP headers.  This option may place,
              and the InPlace flag bit must be used
      by on in the fast forwarding path ERROR_SPEC of a high-speed router to detect
      datagrams that require special processing.

      Upon the arrival of an RSVP message M that changes
              the state, a
      node must RERR message.

         o    Succeeding nodes forward the modified state immediately.  However, this
      must not trigger sending an RERR message out the interface through
      which M arrived (as could happen if the implementation simply
      triggered an immediate refresh of all state for the session).
      This rule is necessary to prevent packet storms next hops
              that have local reservation state.  For reservations with
              wildcard scope, there is an additional limitation on broadcast LANs.

      An RSVP message must be fragmented when necessary
              forwarding RERR messages, to fit into the
      MTU of avoid loops; see Section 3.3.
              There is also a rule restricting the interface through which it will be sent.  All fragments forwarding of the RESV
              messages for Admission Control failures; see Section 3.4.

              A RERR message that is forwarded should carry the same unique value of
              FILTER_SPEC from the Message
      ID field, as well as appropriate Fragment Offset and MF bits, in
      their common headers. corresponding reservation state.

         o    When an RSVP a RERR message arrives, it must be
      reassembled before it can be processed.  The refresh period R can reaches a receiver, the STYLE object,
              flow descriptor list, and ERROR_SPEC object (including its
              flags) should be used as an appropriate reassembly timeout time.

      Since RSVP delivered to the receiver application.

      3.1.7 Confirmation Messages

         RACK messages are normally generated and sent hop-by-hop,
      using to (probabilistically) acknowledge
         reservation requests.  A RACK message is sent as the RSVP-level fragmentation mechanism should avoid further
      fragmentation at result of
         the IP level.  However, IP fragmentation may
      still occur when RSVP messages travel through appearance of a non-RSVP cloud.
      In case of IP6, which does not support IP fragmentation at
      routers, an RSVP implementation must use Path MTU Discovery or
      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 RESV_CONFIRM object in a failure of resource
      reservations.  To control the queueing delay and dropping of RSVP
      packets, routers should be configured RESV message.

         A RACK message is sent to offer them a preferred
      class the unicast address of service.  If RSVP packets experience noticeable losses
      when crossing a congested non-RSVP cloud, a larger value can be
      used for receiver
         host; the 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 do not have multicast capability.  A multicast tunnel
      looks like a logical outgoing interface that address is mapped into some
      physical interface.  A multicast routing protocol that supports
      tunnels will describe a route using a list of logical rather than
      physical interfaces.  RSVP can run through multicast tunnels in obtained from the following manner:

      1.   When a node N forwards RESV_CONFIRM object.
         However, a PATH RACK message out is forwarded to the receiver hop-by-
         hop, to accommodate the hop-by-hop integrity check mechanism.

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

                                      <ERROR_SPEC>
                                      <RESV_CONFIRM>

                                      <STYLE> <flow descriptor list>

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

         The RESV_CONFIRM object is a logical outgoing
           interface L, it includes copy of that object in the RESV
         message some encoding of that triggered the
           identity of L, called the "logical interface handle" or LIH. confirmation.  The LIH value ERROR_SPEC is carried in the RSVP_HOP object.

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

      3.   When N' sends a RESV message
         used only to N, it includes carry the LIH value
           from IP address of the path state (again, originating node, in
         the RSVP_HOP object).

      4.   When the RESV message arrives at N, its LIH value provides Error Node Address; the information necessary Error Code and Value are zero to attach
         indicate a confirmation.  The object order requirements within
         the reservation to flow descriptor list are the
           appropriate logical interface.  Note that N creates same as those given earlier
         for a RESV message.

   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 used between an end system and
           interprets the LIH; first/last hop
      router, although it is an opaque value also possible to N'.

   3.3 Avoiding RSVP Message Loops

      Forwarding of encapsulate RSVP messages must avoid looping.  In steady state,
      PATH
      as 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 RESV RACK messages are forwarded only once per refresh period
      on each hop. must be sent with the Router Alert
      IP option [Katz95] in their IP headers.  This avoids looping packets, but there is still option may be used
      in the
      possibility fast forwarding path of an " auto-refresh" loop, clocked by a high-speed router to detect
      datagrams that require special processing.

      Upon the refresh
      period.  Such auto-refresh loops keep arrival of an RSVP message M that changes the state, a
      node must forward the modified state active "forever", even immediately.  However, this
      must not trigger sending an message out the interface through
      which M arrived (as could happen if the end nodes have ceased refreshing it, until either implementation simply
      triggered an immediate refresh of all state for the
      receivers leave session).
      This rule is necessary to prevent packet storms on broadcast LANs.

      An RSVP message must be fragmented when necessary to fit into the multicast group and/or
      MTU of the senders stop
      sending PATH messages.  On interface through which it will be sent.  All fragments
      of the other hand, error and teardown
      messages are forwarded immediately and are therefore subject to
      looping.

      Consider each message type.

      o    PATH Messages

           PATH messages are forwarded in exactly should carry the same way unique value of the Message
      ID field, as IP
           data packets.  Therefore there 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 reassembly timeout time.

      Between adjacent RSVP-capable routers, RSVP-level fragmentation
      mechanism should normally be no loops of PATH
           messages, even used in a topology with cycles.

      o    PTEAR Messages

           PTEAR messages use lieu of fragmentation at the same routing as PATH messages and
           therefore cannot loop.

      o    PERR Messages
           Since PATH
      IP level.  However, IP-level fragmentation may still occur when
      RSVP messages do not loop, they create path state
           defining travel through a loop-free reverse path to each sender.  PERR
           messages are always directed non-RSVP cloud.  In case of IP6,
      which does not support IP fragmentation at routers, an RSVP
      implementation must use Path MTU Discovery or hand configuration
      to particular senders and
           therefore cannot loop.

      o    RESV Messages

           RESV messages directed obtain an appropriate MTU between adjacent RSVP neighbors.

      RSVP uses its periodic refresh mechanisms to particular senders (i.e., with
           explicit sender selection) cannot loop.  However, RESV recover from
      occasional packet losses.  Under network overload, however,
      substantial losses of RSVP messages with wildcard sender selection (WF style) have could cause a
           potential for auto-refresh looping.

      o    RTEAR Messages

           Although RTEAR messages are routed the same as RESV messages,
           during failure of
      resource reservations.  To control the second pass around a loop there will be no state
           so any RTEAR message will queueing delay and dropping
      of RSVP packets, routers should be dropped.  Hence there is no
           looping problem here.

      o    RERR Messages

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

      o    RACK Messages

           RACK messages are forwarded towards configured to offer them a fixed unicast receiver
           address and cannot loop.

      If the topology has no loops, then looping
      preferred class of "wildcard" RESV and
      RERR messages, i.e., messages with wildcard sender selection, service.  If RSVP packets experience noticeable
      losses when crossing a congested non-RSVP cloud, a larger value
      can be avoided by simply enforcing used for the rule given earlier: state that
      is received timeout factor K (see section 3.6 below).

      Some multicast routing protocols provide for "multicast tunnels",
      which encapsulate multicast packets for transmission through a particular interface must never be forwarded
      out the same interface.  However, when the topology does
      routers that do not have
      cycles, further effort multicast capability.  A multicast tunnel
      looks like a logical outgoing interface that is needed to prevent auto-refresh loops of
      wildcard RESV messages and fast loops of wildcard RERR messages.
      The solution to this problem adopted by this mapped into some
      physical interface.  A multicast routing protocol
      specification is for such messages to carry an explicit sender
      address that supports
      tunnels will describe a route using a list of logical rather than
      physical interfaces.  RSVP can run through multicast tunnels in a SCOPE object.
      the following manner:

      1.   When a RESV message with WF style is to be forwarded to node N forwards a
      particular previous hop, PATH message out a new SCOPE object is computed from the
      SCOPE objects that were received logical outgoing
           interface L, it includes in matching RESV messages.  If
      the computed SCOPE object is empty, the message is not forwarded
      to some encoding of the previous hop; otherwise,
           identity of L, called the message "logical interface handle" or LIH.
           The LIH value is sent containing carried in the
      new SCOPE RSVP_HOP object.

      2.   The rules for computing a new SCOPE object for next hop node N' stores the LIH value in its path state.

      3.   When N' sends a RESV message are as follows:

      1.   The union is formed of the sets of sender IP addresses listed
           in all SCOPE objects in to N, it includes the reservation state for LIH value
           from the given
           session.

           If reservation path state from some NHOP does not contain a SCOPE
           object, a substitute sender list must be created and included (again, in the union.  For a message that arrived on outgoing
           interface OI, RSVP_HOP object).

      4.   When the substitute list is RESV message arrives at N, its LIH value provides
           the set of senders that
           route information necessary to OI.

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

      3.   If attach the SCOPE object is to be sent reservation to PHOP, remove from the
           set any senders
           appropriate logical interface.  Note that did not come from PHOP.

      Figure 11 shows N creates and
           interprets the LIH; it is an example opaque value to N'.

   3.3 Avoiding RSVP Message Loops

      Forwarding of wildcard-scoped (WF style) 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
      possibility of an "auto-refresh" loop, clocked by the refresh
      period.  Such auto-refresh loops keep state active "forever", even
      if the end nodes have ceased refreshing it, until either the
      receivers leave the multicast group and/or the senders stop
      sending PATH messages.  The address lists within SCOPE objects  On the other hand, error and teardown
      messages are shown forwarded immediately and are therefore subject to
      looping.

      Consider each message type.

      o    PATH Messages

           PATH messages are forwarded in
      square brackets.  Note that exactly the same way as IP
           data packets.  Therefore there may should be additional connections
      among the nodes, creating looping topology that is not shown.

                         ________________ no loops of PATH
           messages, even in 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 Wildcard-Scope Reservations

      SCOPE objects are not necessary if topology with cycles.

      o    PTEAR Messages

           PTEAR messages use the multicast same routing uses
      shared trees or if the reservation style has explicit sender
      selection.  Furthermore, attaching a SCOPE object to as PATH messages and
           therefore cannot loop.

      o    PERR Messages

           Since PATH messages do not loop, they create path state
           defining a reservation
      may be deferred loop-free reverse path to a node which has more than one previous hop
      upstream.

      The following rules each sender.  PERR
           messages are used for SCOPE objects in RERR always directed to particular senders and
           therefore cannot loop.

      o    RESV Messages

           RESV messages directed to particular senders (i.e., with WF style:

      1.   The node that detected the error initiates an RERR message
           containing
           explicit sender selection) cannot loop.  However, RESV
           messages with wildcard sender selection (WF style) have a copy of
           potential for auto-refresh looping.

      o    RTEAR Messages

           Although RTEAR messages are routed the SCOPE object associated with same as RESV messages,
           during the
           reservation second pass around a loop there will be no state or
           so any RTEAR message in error.

      2.   Suppose a wildcard-scoped will be dropped.  Hence there is no
           looping problem here.

      o    RERR message arrives at a node with
           a SCOPE object containing Messages

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

      o    RACK Messages

           RACK messages are forwarded towards a fixed unicast receiver
           address list L.
           The node forwards and cannot loop.

      If the topology has no loops, then looping of RESV and RERR message using
      messages with wildcard sender selection can be avoided by simply
      enforcing the rules of Section
           3.1.5. rule given earlier: state that is received through a
      particular interface must never be forwarded out the same
      interface.  However, when the topology does have cycles, further
      effort is needed to prevent auto-refresh loops of 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 in a SCOPE
      object.

      When a RESV message with WF style is to be forwarded out OI must
           contain to a
      particular previous hop, a new SCOPE object derived is computed from L by including only those
           senders the
      SCOPE objects that route to OI. were received in matching RESV messages.  If this
      the computed SCOPE object is empty, the
           RERR message should is not be forwarded
      to the previous hop; otherwise, the message is sent out OI.

   3.4 Local Repair

      When a route changes, containing the next PATH or
      new SCOPE object.  The rules for computing a new SCOPE object for
      a RESV refresh message will
      establish path or are as follows:

      1.   The union is formed of the sets of sender IP addresses listed
           in all SCOPE objects in the reservation state (respectively) along for the new
      route.  To provide fast adaptation to routing changes without the
      overhead of short refresh periods, the local routing protocol
      module can notify the RSVP daemon of route changes for particular
      destinations.  The RSVP daemon should use this information to
      trigger a quick refresh of given
           session.

           If reservation state for these destinations, using the
      new route.

      More specifically, from some NHOP does not contain a SCOPE
           object, a substitute sender list must be created and included
           in the rules are as follows:

      o    When routing detects union.  For a change of message that arrived on outgoing
           interface OI, the substitute list is the set of outgoing
           interfaces for destination G, RSVP should wait for a short
           period W, and then send PATH refreshes for all sessions G/* senders that
           route to OI.

      2.   Any local senders (i.e., for any session with destination G, regardless of
           destination port).

           The short wait period before sending PATH refreshes is to
           allow the routing protocol getting settled with the new
           change(s), and sender applications on this
           node) are removed from this set.

      3.   If the exact value for W should be chosen
           accordingly.  Currently W = 2 sec SCOPE object is suggested; however, this
           value should to be configurable per interface.

      o    When a PATH message arrives with a Previous Hop address that
           differs sent to PHOP, remove from the one stored in the path state, RSVP should
           send immediate RESV refreshes for
           set any senders that session.

   3.5 Time Parameters

      There are two time parameters relevant to each element did not come from PHOP.

      Figure 11 shows an example of RSVP
      path or reservation state in a node: the refresh period R between
      generation of successive refreshes for the state by the neighbor
      node, and the local state's lifetime L.  Each RSVP wildcard-scoped (WF style) RESV or PATH
      message
      messages.  The address lists within SCOPE objects are shown in
      square brackets.  Note that there may contain a TIME_VALUES object specifying be additional connections
      among the R value nodes, creating looping topology that was used to generate this (refresh) message.  This R value is
      then used to determine 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 Wildcard-Scope Reservations

      SCOPE objects are not necessary if the value for L when multicast routing uses
      shared trees or if the state is received
      and stored.  The values for R and L reservation style has explicit sender
      selection.  Furthermore, attaching a SCOPE object to a reservation
      may vary from hop be deferred to hop.

      In a node which has more detail:

      1.   Floyd and Jacobson [FJ94] have shown that periodic messages
           generated by independent network nodes can become
           synchronized.  This can lead to disruption than one previous hop
      upstream.

      The following rules are used for SCOPE objects in network
           services as the periodic RERR 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 WF style:

      1.   The node that may
           occur is not stable.

           For this reason, detected the refresh timer should be randomly set to error initiates an RERR message
           containing a value in the range [0.5R, 1.5R].

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

           Currently K = 3 is suggested as the default.  However, it may
           be necessary to set a larger K value for hops with 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 that creates
           reservation state (PATH or RESV message)
           carries message in error.

      2.   Suppose a TIME_VALUES wildcard-scoped RERR message arrives at a node with
           a SCOPE object containing the R used to
           generate refreshes; the recipient sender host address list L.
           The node uses this R to
           determine L forwards the RERR message using the rules of Section
           3.1.6.  However, the stored state.

      4.   R is chosen locally RERR message forwarded out OI must
           contain a SCOPE object derived from L by each node. including only those
           senders that route to OI.  If this SCOPE object is empty, the node does
           RERR message should not
           implement local repair of reservations disrupted by route
           changes, be sent out OI.

   3.4 Blockade State

      The basic rule for creating a smaller R speeds up adaptation RESV refresh message is to routing changes,
           while increasing merge the RSVP overhead.  With local repair, a
           router can be more relaxed about R since
      flowspecs of the periodic refresh
           becomes only a backstop robustness mechanism.  A node may
           therefore adjust reservation requests in place in the effective R dynamically to control node, by
      computing their LUB.  However, this rule is modified by the
           amount
      existence of overhead due "blockade state" resulting from RERR messages, to refresh messages.
      solve the KR-II problem (Section 2.6).  The current suggested default for R is 30 seconds.  However, blockade state also
      enters into the default should be configurable per interface.

      5. routing of RERR messages for Admission Control
      failure.

      When R a RERR message for an Admission Control failure is changed dynamically, there received,
      its flowspec Qe is a limit used to how fast
           it may increase.  Specifically, create or refresh an element of local
      blockade state.  Each element of blockade state consists of a
      blockade flowspec Qb taken from the ratio flowspec of two successive
           values R2/R1 must not exceed 1 + Slew.Max.

           Currently, Slew.Max the last RERR, and
      an associated blockade timer Tb.  When the blockade timer expires,
      the blockade state is 0.30.  With K = 3, one packet deleted.

      The granularity of blockade state depends upon the style of the
      RERR message that created it.  For an explicit style, there may be
           lost without
      a blockade state element (Qb(S),Tb(S)) for each sender S.  For a
      wildcard style, blockade state timeout while R is increasing 30 percent per refresh cycle.

      6.   To improve robustness, previous hop P.

      An element of blockade state with flowspec Qb is said to
      "blockade" a node may temporarily send refreshes
           more often reservation with flowspec Qi if Qb is not (strictly)
      greater than R after Qi.  For example, suppose that the LUB of two
      flowspecs is computed by taking the max of each of their
      corresponding components.  Then Qb blockades Qi if for some
      component j, Qb[j] <= Qi[j].

      Suppose that a state change (including initial
           state establishment).

      7.   The values node receives a RERR message from previous hop P
      (or, if style is explicit, sender S) as the result of Rdef, K, and Slew.Max used in an implementation
           should be easily modifiable per interface, as experience may
           lead to different values.  The possibility Admission
      Control failure upstream.  Then:

      1.   An element of dynamically
           adapting K and/or Slew.Max in response to measured loss rates blockade state is created for future study.

   3.6 Traffic Policing and TTL

      RSVP P (or S) if it
           did not exist.

      2.   Qb(P) (or Qb(S)) is required to compute and pass several service-related flags set equal to traffic control: policing flags and a non-RSVP flag.

      Some QoS services may require traffic policing at some or all of
      (1) the edge of flowspec Qe from the network, (2) a merging point
           RERR message.

      3.   A corresponding blockade timer Tb(P) (or Tb(S)) is started or
           restarted 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 time Kb*R.  Here Kb is a fixed multiplier and must so indicate to the
      traffic control mechanism.  On
           R is the other hand, RSVP does refresh interval for reservation state.  Kb should
           be configurable.

      4.   If there is some local reservation state that is not
      interpret the service embodied
           blockaded (see below), an immediate reservation refresh for P
           (or S) is generated.

      5.   The RERR message is forwarded to next hops in the flowspec and therefore does
      not know whether policing will actually be applied in any
      particular case.

      The RSVP daemon passes following
           way.  If the InPlace bit is off, the RERR message is
           forwarded to traffic control a separate policing flag all next hops for each of these three situations.

      o    E_Police_Flag -- Entry Policing

           This flag which there is set in reservation
           state.  If the first-hop RSVP node that implements
           traffic control (and InPlace bit 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 E_Police_Flag should be off in on, the sender host, and it
           should RERR message is
           forwarded only be set on when to the first hop capable of traffic
           control is reached.  This next hops whose Qi is controlled blockaded by Qb.

      Finally, we present the E_Police flag
           in SESSION objects.

      o    M_Police_Flag -- Merge Policing

           This flag should be set on modified rule for merging flowspecs to
      create a reservation using a shared
           style (WF or SE) when flows from more than one sender are
           being merged. refresh message.

      o    B_Police_Flag -- Branch Policing

           This flag should be set on when the flowspec being installed
           is smaller than, or incomparable to, a FLOWSPEC in place on    If there are any other interface, for the same FILTER_SPEC and SESSION.

      RSVP must also detect local reservation requests Qi that are not
           blockaded, these are merged by computing their LUB.  The
           blockaded reservations are ignored; this allows forwarding of
           a smaller reservation that has not failed and report to receivers may perhaps
           succeed, after a larger reservation fails.

      o    Otherwise (all local requests Qi are blockaded), they are
           merged by taking the presence GLB (Greatest Lower Bound) of
      non-RSVP hops in the path.  For this purpose, an RSVP daemon must
      place into Qi's.

      This refresh merging algorithm is applied separately to each PATH message that it sends the value of the IP TTL
      with which the message was sent.  The RSVP-capable node that
      receives this message compares this field flow
      (each sender or PHOP) contributing to a shared reservation (WF or
      SE style).

      Figure 12 shows an example of the TTL with which the message was actually received, application of blockade
      state for a shared reservation (WF style).  There are two previous
      hops labelled (a) and if they differ (b), and two next hops labelled (c) and (d).
      The larger reservation 4B arrived from (c) first, but it turns on failed
      somewhere upstream via PHOP (a), but not via PHOP (b).  The
      figures show the Non_RSVP flag. final "steady state" after the smaller
      reservation 2B subsequently arrived from (d).  This flag steady state
      is carried forward to receivers in
      the ADSPEC [??].

   3.7 Multihomed Hosts

      Accommodating multihomed hosts requires some special rules in
      RSVP.  We use perturbed roughly every Kb*R seconds, when the term `multihomed host' blockade state
      times out.  The next refresh then sends 4B to cover both hosts (end
      systems) with more than one network interface [could ref. section
      3.3.4 of RFC-1122], and routers that are supporting local
      application programs.

      An application executing on a multihomed host may explicitly
      specify which interface any given flow previous hop (a);
      presumably this will use for fail, sending and/or
      for receiving data packets, a RERR message that will re-
      establish the blockade state, returning to override the system-specified
      default interface.  The RSVP daemon must be aware of situation shown in
      the default, figure.  At the same time, the RERR message will be forwarded
      to next hop (c) and if an application sets a 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 all receivers downstream responsible for
      the characteristics of 4B reservations.

               Send      Blockade|   Reserve       Receive
                            State|
                                 |
                                 |   ________
        (a) <- WF(*{2B})    {4B} |  | * {4B} | WF(*{4B}) <- (c)
                                 |  |________|
                                 |
      ---------------------------|-------------------------------
                                 |
                                 |   ________
        (b) <- WF(*{4B})   (none)|  | * {2B} | WF(*{2B}) <- (d)
                                 |  |________|

                   Figure 12: Blockading with Shared Style

   3.5 Local Repair

      When a route changes, the data
           flow it next PATH or RESV refresh message will originate.  This call may optionally include
      establish path or reservation state (respectively) along the
           local IP address of new
      route.  To provide fast adaptation to routing changes without the sender. If it is set by
      overhead of short refresh periods, the
           application, this parameter must be local routing protocol
      module can notify the interface address RSVP daemon of route changes for
           sending the data packets; otherwise, the system default
           interface is implied. particular
      destinations.  The RSVP daemon on the host then sends PATH messages for should use this
           application out the specified interface (only).

      o    Making Reservations

           A receiver application uses an API call (called RESERVE in
           Section 3.9.1) information to request
      trigger a reservation from RSVP.  This call
           may optionally include the local IP address quick refresh of the receiver,
           i.e., the interface address state for receiving data packets.  In these destinations, using the case
      new route.

      The specific rules are as follows:

      o    When routing detects a change of multicast sessions, this is the interface on
           which the group has been joined.  If the parameter is
           omitted, the system default interface is used.

           In general, the set of outgoing
           interfaces for destination G, RSVP daemon should wait for a short
           period W, and then send RESV messages PATH refreshes for
           application out all sessions G/*
           (i.e., for any session with destination G, regardless of
           destination port).

           The short wait period before sending PATH refreshes is to
           allow the specified interface.  However, when routing protocol getting settled with the
           application is executing on a router new
           change(s), and the session exact value for W should be chosen
           accordingly.  Currently W = 2 sec is
           multicast, a more complex situation arises.   Suppose in suggested; however, this
           case that
           value should be configurable per interface.

      o    When a receiver application joins the group on an
           interface Iapp PATH message arrives with a Previous Hop address that
           differs from Isp, the shortest-path
           interface to one stored in the sender.  Then there path state, RSVP should
           send immediate RESV refreshes for that session.

   3.6 Time Parameters

      There are two possible ways
           for multicast routing to deliver data packets time parameters relevant to the
           application.  The each element of RSVP daemon must determine which case holds
           by examining the
      path state, to decide which incoming
           interface to use for sending RESV messages.

           1.   The multicast routing protocol may create or reservation state in a separate
                branch node: the refresh period R between
      generation of successive refreshes for the multicast distribution `tree' to deliver
                to Iapp.  In this case, there will be path state for
                both Isp by the neighbor
      node, and Iapp.  The path state on Iapp should only
                match a reservation from the local application; it must
                be marked "Local_only" by the state's lifetime L.  Each RSVP daemon.  If
                "Local_only" path state for Iapp exists, the RESV or PATH
      message should be sent out Iapp.

                Note may contain a TIME_VALUES object specifying the R value
      that it was used to generate this (refresh) message.  This R value is possible for
      then used to determine the path state blocks value for
                Isp and Iapp to have L when the same next hop, if there state is an
                intervening non-RSVP cloud.

           2. received
      and stored.  The multicast routing protocol values for R and L may forward data within
                the router vary from Isp hop to Iapp. hop.

      In this case, Iapp will
                appear in the list of outgoing interfaces of the path
                state for Isp, more detail:

      1.   Floyd and the RESV message should be sent out
                Isp.

   3.8 Future Compatibility

      We may expect Jacobson [FJ94] have shown that periodic messages
           generated by independent network nodes can become
           synchronized.  This can lead to disruption in network
           services as the future new object C-Types will be
      defined periodic messages contend with other network
           traffic for existing object classes, link and perhaps new object
      classes will be defined.  It will be desirable to employ such new
      objects within the Internet using older implementations forwarding resources.  Since RSVP sends
           periodic refresh messages, it must avoid message
           synchronization and ensure that do any synchronization that may
           occur is not recognize them.  Unfortunately, stable.

           For this is only possible reason, the refresh timer should be randomly set to
           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 value in the Class-Num octet, as
           follows.

           o    Class-Num range [0.5R, 1.5R].

      2.   To avoid premature loss of state, L must satisfy L >= 128

                In this case, (K +
           0.5)*1.5*R, where K is a small integer.  Then in the entire message should be rejected and
                an "Unknown Object Class" error returned.

           o    Class-Num < 128

                In this worst
           case, the node should ignore the object but
                forward it, unexamined and unmodified, in all K-1 successive messages
                resulting from the may be lost without state contained in this message.

                For example, suppose that being
           deleted.  To compute a RESV message that is
                received contains an object lifetime L for a collection of unknown class.  Such an
                object should be saved in the reservation state without
                further examination; however, only the latest object
           with a given (unknown class, C-Type) pair should be
                saved.  When a RESV message different R values R0, R1, ..., replace R by max(Ri).

           Currently K = 3 is forwarded, suggested as the default.  However, it should
                include copies of such saved unknown-class objects from
                all reservations that are merged may
           be necessary to form the new RESV
                message.

                Note that objects set a larger K value for hops with unknown class cannot be merged;
                however, unmerged objects high loss
           rate.  K may be forwarded until they
                reach set either by manual configuration per
           interface, or by some adaptive technique that has not yet
           been specified.

      3.   Each message that creates state (PATH or RESV message)
           carries a TIME_VALUES object containing the R used to
           generate refreshes; the recipient node that knows how uses this R to merge them.  Forwarding
                objects with unknown class enables incremental
                deployment
           determine L of new objects; however, the scaling
                limitations stored state.

      4.   R is chosen locally by each node.  If the node does not
           implement local repair of doing so must reservations disrupted by route
           changes, a smaller R speeds up adaptation to routing changes,
           while increasing the RSVP overhead.  With local repair, a
           router can be carefully examined
                before more relaxed about R since the periodic refresh
           becomes only a new object class backstop robustness mechanism.  A node may
           therefore adjust the effective R dynamically to control the
           amount of overhead due to refresh messages.

           The current suggested default for R is deployed with Class-Num <
                128.

           These rules 30 seconds.  However,
           the default should be considered when any new Class-Num configurable per interface.

      5.   When R is
           defined.

      2.   Unknown C-Type for Known Class

           One might expect changed dynamically, there is a limit on how fast
           it may increase.  Specifically, the known Class-Num to provide information
           that could allow intelligent handling ratio of such an object.
           However, in practice such class-dependent handling two successive
           values R2/R1 must not exceed 1 + Slew.Max.

           Currently, Slew.Max is
           complex, and in many cases it 0.30.  With K = 3, one packet may be
           lost without state timeout while R is not useful.

           Generally, the appearance increasing 30 percent
           per refresh cycle.

      6.   To improve robustness, a 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 object with unknown C-Type implementation
           should result in rejection be easily modifiable per interface, as experience may
           lead to different values.  The possibility of the entire message dynamically
           adapting K and/or Slew.Max in response to measured loss rates
           is for future study.

   3.7 Traffic Policing and
           generation of an error message (RERR Non-Integrated Service Hops

      Some QoS services may require traffic policing at some or PERR as appropriate).
           The error message will include the Class-Num and C-Type that
           failed (see Appendix B); all of
      (1) the end system that originated edge of the
           failed message network, (2) a merging point for data from
      multiple senders, and/or (3) a branch point where traffic flow
      from upstream may be able to use this information to retry greater than the request using a different C-Type object, repeating this
           process until it runs out of alternatives or succeeds.

           Objects of certain classes (FLOWSPEC, ADSPEC, downstream reservation being
      requested.  RSVP knows where such points occur and
           POLICY_DATA) are opaque to RSVP, which simply hands them must so
      indicate to the traffic control or policy modules.  Depending upon its
           internal rules, either of the latter modules may reject a C-
           Type and inform mechanism.  On the other hand,
      RSVP daemon; RSVP should then reject does not interpret the
           message and send an error, as described service embodied in the previous
           paragraph.

   3.9 RSVP Interfaces

      RSVP on a router has interfaces to routing flowspec and to traffic control.
      therefore does not know whether policing will actually be applied
      in any particular case.

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

      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 separate policing flag
      for each of these calls cause information to be returned asynchronously. three situations.

      o    Register Session

              Call: SESSION( DestAddress , ProtocolId, DstPort ,

                         [ , SESSION_object ]

                         [ , Upcall_Proc_addr ] )  -> Session-id    E_Police_Flag -- Entry Policing

           This call initiates RSVP processing for a session, defined
              by DestAddress together with ProtocolId and possibly a
              port number DstPort.  If successful, the SESSION call
              returns immediately with a local session identifier
              Session-id, which may be used flag is set 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 first-hop RSVP node that implements
           traffic control (and is
              included as an escape mechanism to support some more
              general definition 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 session ("generalized
              destination port"), E_Police_Flag should that be necessary off in the
              future.  Normally SESSION_object will be 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
              definition of, the attributes of host, and it
           should only be set on when the data stream.  The first SENDER call for node capable of traffic
           control is reached.  This is controlled by the session registered as `Session-
              id' will cause RSVP to begin sending PATH messages E_Police flag
           in SESSION objects.

      o    M_Police_Flag -- Merge Policing

           This flag should be set on for
              this session; later calls will modify the path
              information.

              The SENDER parameters a reservation using a shared
           style (WF or SE) when flows from more than one sender are interpreted as follows:

              -    Source_Address
           being merged.

      o    B_Police_Flag -- Branch Policing

           This flag should be set on when the flowspec being installed
           is smaller than, or incomparable to, a FLOWSPEC in place on
           any other interface, for the address same FILTER_SPEC and SESSION.

      RSVP must also detect and report to receivers the presence of
      non-RSVP (which implies non-integrated-service compliant) hops in
      the interface from which path.  For this purpose, an RSVP daemon sets the
                   data will be sent.  If it is omitted, Non_RSVP flag
      bit in SESSION object of PATH messages.  With normal IP
      forwarding, RSVP can detect a default
                   interface will be used.  This parameter is needed on non-RSVP hop by comparing the IP TTL
      with which a multihomed sender host.

              -    Source_Port

                   This PATH message is sent to the UDP/TCP port from TTL with which the data will be
                   sent.  If it is omitted or zero,
      received, and set the port Non_RSVP bit on.  For this purpose, the
      transmission TTL is "wild"
                   and can match any port placed in a FILTER_SPEC.

              -    Sender_Template

                   This parameter the common header.

      However, the TTL is included as an escape mechanism to
                   support not always a more general definition reliable indicator of the sender
                   ("generalized source port").  Normally this parameter
                   may non-RSVP
      hops, and other means must be omitted.

              -    Sender_Tspec

                   This optional parameter describes used.  For example, if the traffic flow to
                   be sent.  It may be included routing
      protocol uses IP encapsulating tunnels, then the routing protocol
      must inform RSVP when non-RSVP hops are included.  If no automatic
      mechanism will work, manual configuration will be required.
      Finally, there may still be cases where an RSVP cannot reliably
      determine whether or not a non-RSVP hop was used.  To report this
      to prevent over-
                   reservation on the initial hops.

              -    Data_TTL

                   This is receiver, the (non-default) IP Time-To-Live parameter
                   that is being supplied on SESSION object carries another flag bit,
      Maybe_RSVP.

   3.8 Multihomed Hosts

      Accommodating multihomed hosts requires some special rules in
      RSVP.  We use the data packets.  It is
                   needed term `multihomed host' to ensure cover both hosts (end
      systems) with more than one network interface [could ref. section
      3.3.4 of RFC-1122], and routers that Path messages do not have are supporting local
      application programs.

      An application executing on a
                   scope larger than multicast data packets.

              -    Sender_Policy_Data

                   This optional parameter passes policy data multihomed host may explicitly
      specify which interface any given flow will use for the
                   sender.  This sending and/or
      for receiving data may packets, to override the system-specified
      default interface.  The RSVP daemon must be supplied by a system
                   service, with aware of the default,
      and if an application treating sets a specific interface, it as opaque. must also pass
      that information to RSVP.

      o    Reserve

              Call: RESERVE( session-id, [ receiver_address , ]

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

           A receiver sender application uses this an API call (SENDER in Section
           3.10.1) to make or declare to modify a resource
              reservation for RSVP the session registered as `session-id'.
              The first RESERVE call characteristics of the data
           flow it 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 existing reservations may result in
              admission control failure).

              The optional `receiver_address' parameter may be used by a
              receiver on a multihomed host (or router); it is originate.  This call may optionally include the
           local IP address of one of the node's interfaces.  The ACK_flag
              should be set on if a reservation ACK sender. If it is desired, off
              otherwise.  The `style' parameter indicates set by the
              reservation style.  The rest of
           application, this parameter must be the parameters depend upon interface address for
           sending the style, but generally these will include appropriate
              flowspecs, filter specs, and possibly receiver policy data
              objects. packets; otherwise, the system default
           interface is implied.

           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 removes RSVP state for daemon on the session specified by
              session-id.  The node host then sends appropriate teardown PATH messages and 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
           application out the upcall procedure whose
              address was supplied specified interface (only).

      o    Making Reservations

           A receiver application uses an API call (RESERVE in the SESSION call.

              This upcall may occur asynchronously at any time after Section
           3.10.1) to request a
              SESSION reservation from RSVP.  This call and before a RELEASE call, to indicate an
              error or an event.  Currently there are five upcall types,
              distinguished by may
           optionally include the Info_type parameter:

              1.   Info_type = Path Event

                   A Path Event upcall results from receipt local IP address of the first
                   PATH message receiver,
           i.e., the interface address for receiving data packets.  In
           the case of multicast sessions, this session, indicating to a
                   receiver application that there is at least one
                   active sender.

                   This upcall provides synchronizing information to the
                   receiver application, and it may also provide
                   parallel lists of senders (in Filter_spec_list),
                   traffic descriptions (in Flowspec_list), and service
                   advertisements (in Advert_list).  `List_count' will
                   be interface on
           which 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 group has been joined.  If the parameter is triggered by
           omitted, the receipt of system default interface is used.

           In general, the first reservation message or by modification of a
                   previous reservation state, RSVP daemon should send RESV messages for this session.

                   `List_count' will be 1, and Flowspec_list will
                   contain one FLOWSPEC, an
           application out the effective QoS that would be
                   applicable to specified interface.  However, when the
           application itself.
                   Filter_spec_list and Advert_list will contain one
                   NULL object.  The Error_code, Error_value, LUB-Used
                   flag, is executing on a router and Policy_data parameters will be undefined the session is
           multicast, a more complex situation arises.   Suppose in this upcall.

              3.   Info_type = Path Error

                   An Path Error event indicates an error in sender
                   information
           case that was specified in 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 receiver application joins the node group on an
           interface Iapp that detected differs from Isp, the error.

                   `List_count' will be 1, and Filter_spec_list will
                   contain shortest-path
           interface to the Sender_Template supplied in sender.  Then there are two possible ways
           for multicast routing to deliver data packets to the SENDER
                   call; Flow_Spec_list and Advert_list will each
                   contain one NULL object.
           application.  The Policy_data parameter
                   will contain any POLICY_DATA objects in RSVP daemon must determine which case holds
           by examining the PERR
                   message.

              4.   Info_type = Resv Error/Confirmation

                   An Resv Error/Confirmation event indicates an error
                   in a reservation message path state, to decide which this application
                   contributed, or the receipt of a RACK message. incoming
           interface to use for sending RESV messages.

           1.   The
                   Error_code parameter will define the error or
                   confirmation.  For an error, Error_value multicast routing protocol may supply
                   some additional (perhaps system-specific) data.  The
                   Error_Node parameter will specify the IP address create a separate
                branch of the node that detected the event being reported.

                   Filter_spec_list and Flowspec_list multicast distribution `tree' to deliver
                to Iapp.  In this case, there will contain the
                   FILTER_SPEC be path state for
                both Isp and FLOWSPEC objects Iapp.  The path state on Iapp should only
                match a reservation from the error flow
                   descriptor (see Section 3.1.5).  List_count will
                   specify the number of FILTER_SPECS in
                   Filter_spec_list, while there will local application; it must
                be one FLOWSPEC in
                   Flowspec_list.  For an error, the Policy_data
                   parameter will contain any POLICY_DATA objects in marked "Local_only" by the
                   RERR message.

              Although RSVP messages indicating daemon.  If
                "Local_only" path or resv events may
              be received periodically, state for Iapp exists, the API RESV
                message should make be sent out Iapp.

                Note that it is possible for the
              corresponding asynchronous upcall path state blocks for
                Isp and Iapp to have the application only
              on the first occurrence or when same next hop, if there is an
                intervening non-RSVP cloud.

           2.   The multicast routing protocol may forward data within
                the information router from Isp to be
              reported changes.  All error Iapp.  In this case, Iapp will
                appear in the list of outgoing interfaces of the path
                state for Isp, and confirmation events the RESV message should be reported sent out
                Isp.

   3.9 Future Compatibility

      We may expect that in the future new object 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 application.

      3.9.2 RSVP/Traffic Control Interface

         In an RSVP-capable node, enhanced QoS Internet using older implementations that do
      not recognize them.  Unfortunately, this is achieved by only possible to a group of
         inter-related traffic control functions:
      limited degree with reasonable complexity.  The rules are as
      follows (`b' represents a packet classifier, bit).

      1.   Unknown Class

           There are three possible ways that an admission control module, and a packet scheduler.  This
         section describes a generic RSVP interface to traffic control.

         o    Make a Reservation

              Call: Rhandle =  TC_AddFlowspec( Interface, TC_Flowspec,

                                     TC_Tspec, E_Police_Flag,

                                     M_Police_Flag, B_Police_Flag )

              The TC_Flowspec parameter defines the desired effective
              QoS to admission control; its value implementation can
           treat an object with unknown class.  This choice is computed as the
              maximum over
           determined by the flowspecs two high-order bits of different next hops (see the
              Compare_Flowspecs call below).  It contains the effective
              reservation Tspec Resv_Te (although the RSVP daemon itself
              has no means to extract the Tspec). Class-Num octet,
           as follows.

           o    Class-Num = 0bbbbbbb

                The TC_Tspec
              parameter defines the effective sender Tspec Path_Te (see
              Section 2.3).  We assume that traffic control takes the
              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 entire message should be set as described
              in Section 3.6.

              The TC_AddFlowspec call returns rejected and an "Unknown
                Object Class" error code if Flowspec
              is malformed or if returned.

           o    Class-Num = 10bbbbbb

                The node should ignore the requested resources are
              unavailable.  Otherwise, object, neither forwarding it establishes a new reservation
              channel corresponding to Rhandle.  It returns the opaque
              number Rhandle for subsequent references to this
              reservation.

         o    Modify Reservation

              Call: TC_ModFlowspec( Rhandle, new_Flowspec,

                                    Sender_Tspec,  E_Police_flag,

                                     M_Police_Flag, B_Police_Flag )

              This call can modify
                nor sending 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.  The other parameters are defined as in
              TC_AddFlowspec. error message.

           o    Delete Flowspec

              Call: TC_DelFlowspec( Rhandle )

              This call will delete an existing reservation, including    Class-Num = 11bbbbbb

                The node should ignore the flowspec object but forward it,
                unexamined and unmodified, in all associated filter specs.

         o    Add Filter Spec

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

              This call messages resulting
                from the state contained in this message.

           For example, suppose that a RESV message that is used to associate received
           contains an additional filter spec
              with object of unknown class number 11bbbbbb.  Such an
           object should be saved in the reservation specified by state without
           further examination; however, only the latest object with a
           given Rhandle,
              following (unknown class, C-Type) pair should be saved.  When a successful TC_AddFlowspec call.  This call
              returns a filter handle FHandle.

         o    Delete Filter Spec

              Call: TC_DelFilter( FHandle )

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

         o    OPWA Update

              Call: TC_Advertise( interface, Adspec,

                              [ , Non_RSVP_flag ] ) -> New_Adspec

              This call
           RESV message is used for OPWA forwarded, it should include copies of such
           saved unknown-class objects from all reservations that are
           merged to compute form the outgoing
              advertisement New_Adspec for new RESV message.

           Note that objects with unknown class cannot be merged;
           however, unmerged objects may be forwarded until they reach a specified interface.

         o    Preemption Upcall

              Upcall: TC_Preempt() -> RHandle, Reason_code

              In order
           node that knows how to grant a merge them.  Forwarding objects with
           unknown class enables incremental deployment of new reservation request, objects;
           however, the admission
              control and/or policy modules may scaling limitations of doing so must be allowed
           carefully examined before a new object class is deployed with
           both high bits on.

           These rules should be considered when any new Class-Num is
           defined.

      2.   Unknown C-Type for Known Class

           One might expect the known Class-Num to preempt provide information
           that could allow intelligent handling of such an
              existing reservation.  This might be reflected object.
           However, in an
              upcall to RSVP, passing practice such class-dependent handling is
           complex, and in many cases it is not useful.

           Generally, the RHandle appearance of the preempted
              reservation, and some indication an object with unknown C-Type
           should result in rejection of the reason.

      3.9.3 RSVP/Routing Interface

         An RSVP implementation needs the following support from the
         packet forwarding entire message and routing mechanisms
           generation of an error message (RERR or PERR as appropriate).
           The error message will include the node.

         o    Promiscuous Receive Mode for RSVP Messages

              Any packet received for IP protocol 46 must Class-Num and C-Type that
           failed (see Appendix B); the end system that originated the
           failed message may be diverted able to use this information to retry
           the RSVP program for processing, without being forwarded.
              On request using a router, the identity different C-Type object, repeating this
           process until it runs out of the interface, real alternatives or
              virtual, on succeeds.

           Objects of certain classes (FLOWSPEC, ADSPEC, and
           POLICY_DATA) are opaque to RSVP, which it is received must also be available simply hands them to
           traffic control or policy modules.  Depending upon its
           internal rules, either of the latter modules may reject a C-
           Type and inform the RSVP daemon.

         o    Route Query

              To forward PATH daemon; RSVP should then reject the
           message and PTEAR messages, send an error, as described in the previous
           paragraph.

   3.10 RSVP daemon must be
              able Interfaces

      RSVP on a router has interfaces to query the routing daemon(s) for routes.

                 Ucast_Route_Query( 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).

      3.10.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: SESSION( DestAddress , ProtocolId, DstPort ,

                         [ SrcAddress, , SESSION_object ] DestAddress, Notify_flag )

                                        -> OutInterface

                 Mcast_Route_Query(

                         [ SrcAddress, , Upcall_Proc_addr ] DestAddress, Notify_flag )  -> [ IncInterface, ] OutInterface_list

              Depending upon the routing protocol, the query may or may
              not depend upon SrcAddress, i.e., upon Session-id

              This call initiates RSVP processing for a session, defined
              by DestAddress together with ProtocolId and possibly a
              port number DstPort.  If successful, the sender host IP
              address, SESSION call
              returns immediately with a local session identifier
              Session-id, which is also may be used in subsequent calls.

              The Upcall_Proc_addr parameter defines the IP source address of the
              message.  Here IncInterface is the interface through which
              the packet an
              upcall procedure to receive asynchronous error or event
              notification; see below.  The SESSION_object parameter is expected
              included as an escape mechanism to arrive; support some multicast routing
              protocols may not provide it.

              If more
              general definition of the Notify_flag is True, routing will save state session ("generalized
              destination port"), should that be necessary to issue unsolicited route change notification
              callbacks (see below) whenever in the specified route
              changes.  Such callbacks
              future.  Normally SESSION_object will be enabled until routing
              receives a route query 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 with to define, or to modify 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
              definition of, the attributes of a transient
              inconsistency in the routing (since a PATH or PTEAR
              message data stream.  The
              first SENDER call for the requested route did arrive at this node).
              In either case, the local state should be updated session registered as
              requested by the message, although it cannot be forwarded
              further.  Updating local state `Session-
              id' will make path state
              available immediately cause RSVP to begin sending PATH messages for a new local receiver, or it
              this session; later calls will
              tear down modify the path state immediately.

         o    Route Change Notification

              If requested by a route query with
              information.

              The SENDER parameters are interpreted as follows:

              -    Source_Address

                   This is the Notify_flag True, address of the routing daemon may provide an asynchronous callback to interface from which 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
                   data will be able to force sent.  If it is omitted, a (multicast) datagram to default
                   interface will be
              sent used.  This parameter is needed on
                   a specific outgoing virtual link, bypassing multihomed sender host.

              -    Source_Port

                   This is the
              normal routing mechanism.  A virtual link may UDP/TCP port from which the data will be a real
              outgoing link
                   sent.  If it is omitted or zero, the port is "wild"
                   and can match any port in a multicast tunnel.  Outgoing link
              specification FILTER_SPEC.

              -    Sender_Template

                   This parameter is necessary to send different versions of included as an outgoing PATH message on different interfaces.  It is
              also necessary in some cases to avoid routing loops.

         o    Source Address Specification

              RSVP must be able escape mechanism to specify
                   support a more general definition of the IP sender
                   ("generalized source address to port").  Normally this parameter
                   may 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.

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

              -    Sender_Tspec

                   This optional parameter describes the traffic flow to manipulate these objects, RSVP daemon must have
         available
                   be sent.  It may be included to it prevent over-
                   reservation on 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 initial hops.

              -    Data_TTL

                   This is greater, flowspecs
              are incomparable but LUB can be computed, or flowspecs are
              incompatible.

              Note the (non-default) IP Time-To-Live parameter
                   that comparing two flowspecs implicitly compares is being supplied on the
              Tspecs data packets.  It is
                   needed to ensure that are contained.  Although Path messages do not have a
                   scope larger than multicast data packets.

              -    Sender_Policy_Data

                   This optional parameter passes policy data for the RSVP daemon
              cannot itself parse
                   sender.  This data may be supplied by a flowspec to extract system
                   service, with the Tspec, application treating 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. as opaque.

         o    Sum Tspecs

                 Sum_Tspecs( Tspec_1, Tspec_2    Reserve

              Call: RESERVE( session-id, [ receiver_address , ]

                        [ CONF_flag, ] style, style-dependent-parms ) -> Tspec_sum

              This

              A receiver uses 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.  It is intended make or to outline modify a set of algorithms that resource
              reservation for the session registered as `session-id'.
              The first RESERVE call will
   accomplish initiate the needed function.  An actual implementation periodic
              transmission of RESV messages.  A later RESERVE call may use
   different but equivalent algorithms.  This section assumes
              be given to modify the
   generic interface calls defined in Section 3.9 and parameters of the following data
   structures.  An actual implementation earlier call (but
              note that changing existing reservations may result in
              admission control failures).

              The optional `receiver_address' parameter may use additional or different
   data structures and interfaces.

   [NOTE: This section is always the last to be updated when changes are
   made, and used by a
              receiver on a multihomed host (or router); it is neither correct nor complete at the present time.
   Therefore, when this section disagrees with the rest IP
              address of one of the text, you node's interfaces.  The CONF_flag
              should believe be set on if a reservation confirmation is desired,
              off otherwise.  The `style' parameter indicates the
              reservation style.  The rest of the text!] parameters depend upon
              the style; 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    PSB -- Path State Block

        Each PSB holds path    Release

              Call: RELEASE( session-id )

              This call removes RSVP state for a particular (session, sender)
        pair, defined the session specified by SESSION
              session-id.  The node then sends appropriate teardown
              messages and SENDER_TEMPLATE objects,
        respectively, received in a PATH message.

        PSB contents include the following values from a PATH message:

        - ceases sending refreshes for this session-id.

         o    Error/Event Upcalls

              The previous hop IP address from general form of a PHOP object (required)

        -    LIH, upcall is as follows:

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

                            information_parameters

              Here "Upcall_Proc" represents the Logical Interface Handle from upcall procedure whose
              address was supplied in the previous hop,
             from SESSION call.  This upcall may
              occur asynchronously at any time after a PHOP object (required).

        -    The remaining IP TTL (required)

        -    SENDER_TSPEC (required)

        -    POLICY_DATA and/or ADSPEC objects (optional)

        -    Non_RSVP flag (required); see Section 3.6.

        In addition, the PSB contains SESSION call and
              before a RELEASE call, to indicate an error or an event.

              Currently there are five upcall types, distinguished by
              the following Info_type parameter.  The selection of information provided
        by routing: OutInterface_list,
              parameters depends upon the list type.

              1.   Info_type = PATH_EVENT

                   A Path Event upcall results from receipt of outgoing interfaces the first
                   PATH message for this (sender, destination), and IncInterface, the expected
        incoming interface.  For session, indicating to a unicast destination,
        OutInterface_list contains
                   receiver application that there is at least one entry
                   active sender.

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

                               Info_type=PATH_EVENT,

                               flags,

                               Sender_Tspec, Sender_Template,

                               [ , Advert ] [ , Policy_data ]

                   This upcall presents the Sender_Tspec and IncInterface is
        undefined.

   o    RSB -- Reservation State Block

        Each RSB holds a reservation request that arrived in a
        particular RESV message, corresponding to the triple:  (session,
        next hop, filter_spec_list).  Here "filter_spec_list" may be a
        list of FILTER_SPECs (for SE style),
                   Sender_Template from a single FILTER_SPEC (FF
        style), or empty (WF style).  We use PATH message; it also passes
                   the symbol "FILTER_SPEC*" advertisement and policy data if they are
                   present.  The possible flags correspond to indicate such a FILTER_SPEC list.

        RSB contents include:

        -    The outgoing (logical) interface OI on which Non_RSVP
                   and Maybe_RSVP flags of the
             reservation SESSION object.

              2.   Info_type = RESV_EVENT

                   A Resv Event upcall is to be made or has been made (required).

        -    FLOWSPEC*, list triggered by the receipt 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 first RESV message, or by modification of a
                   previous reservation specifications state, for this session.

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

                               Info_type=RESV_EVENT,

                               Style, Flowspec, Filter_Spec_list,

                               [ , Policy_data ]

                   Here `Flowspec' will be the effective QoS that have has
                   been handed
        to traffic control received.  Note that an FF-style RESV message
                   may result in multiple RESV_EVENT upcalls, one for specific outgoing interfaces.  In
        general,
                   each flow descriptor.

              3.   Info_type = PATH_ERROR

                   An Path Error event indicates an error in sender
                   information that was specified 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 SENDER call.

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

                                 Info_type=PATH_ERROR,

                                 Error_code , Error_value ,

                                 Error_Node , Sender_Template,

                                 [ Policy_data ]

                   The Error_code parameter will define the corresponding FLOWSPEC values from matching RSB's.
             TC_Flowspec is passed to traffic control to make error, and
                   Error_value may supply some additional (perhaps
                   system-specific) data about the actual
             reservation. error.  The Tspec part
                   Error_Node parameter will specify the IP address of TC_Flowspec is
                   the
             effective reservation Tspec Resv_Te (Section 2.3).

        -    TC_Tspec, equal to node that detected the effective sender Tspec Path_Te.

        -    Police Flags error.  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 Policy_data
                   parameter, if present, will contain the traffic control interface,
             corresponding to POLICY_DATA
                   object from the failed PATH message.

              4.   Info_type = RESV_ERR

                   An Resv Error event indicates an error in a
                   reservation (flowspec) and message to which this application
                   contributed.

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

                                 Info_type=RESV_ERROR,

                                 Error_code , Error_value ,

                                 Error_Node , Error_flags ,

                                 Flowspec, Filter_spec_list,

                                 [ Policy_data ]

                   The Error_code parameter will define the list
             of filter specs.

   Boolean flags Path_Refresh_Needed, Resv_Refresh_Needed, error and
   Tear_Needed
                   Error_value may supply some additional (perhaps
                   system-specific) data.  The Error_Node parameter will also be used in this section.

   [LZ: It might be very helpful to have a short section to summarize
                   specify the management IP address of all the timers.]

   MESSAGE ARRIVES

   Verify version number and checksum fields of common header, node that detected the
                   event being reported.

                   There are two Error_flags:

                   -    InPlace

                        This flag may be on for an Admission Control
                        failure, to indicate that there was, and
   discard message if any mismatch is found.

   Reassemble is, a fragmented message.

   Parse the sequence of objects
                        reservation in place at the message failure node.  This
                        flag is set at the failure point and forwarded
                        in RERR messages.

                   -    NotGuilty

                        This flag may be on for an Admission Control
                        failure, to verify indicate that the length
   field of flowspec requested
                        by this receiver was strictly less than the common header; discard message if there is a mismatch.

   If
                        flowspec that got the message type error.  This flag is not PATH or PTEAR and if set
                        at the IP destination
   address does not match any of receiver API.

                   Filter_spec_list and Flowspec will contain the addresses of
                   corresponding objects from 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

        Process the sender error flow descriptor object sequence in
                   (see Section 3.1.6).  List_count will specify the message as
        follows.
                   number of FILTER_SPECS in Filter_spec_list.  The flags Path_Refresh_Needed and Resv_Refresh_Needed
        flags are initially off.

        o    If there is a
                   Policy_data _list parameter will contain any
                   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 objects in the SENDER_TEMPLATE object is non-zero, build a
             send RERR message.

              5.   Info_type = RESV_CONFIRM

                   A Confirmation event indicates that a "Conflicting Src Port"  PERR message, drop RACK message
                   was received.

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

                                 Info_type=RESV_CONFIRM,

                                 Style, List_count,

                                 Flowspec, Filter_spec_list,

                                 [ Policy_data ]

                   The parameters are interpreted as in the PATH
             message, and return.

        o    Search for a Resv Error
                   upcall.

              Although RSVP messages indicating path state block (PSB) whose (SESSION,
             SENDER_TEMPLATE) pair matches or resv events may
              be received periodically, the API should make the
              corresponding objects in asynchronous upcall to the message, considering any wildcard ports.

        o    If, during application only
              on the PSB search, a PSB is found whose session
             matches first occurrence or when the DestAddress information to be
              reported changes.  All error and Protocol Id fields of the
             received SESSION object, but confirmation events
              should be reported to the DstPorts differ and one application.

      3.10.2 RSVP/Traffic Control Interface

         In an RSVP-capable node, enhanced QoS is
             zero, then build and send a "Conflicting Dst Port" PERR
             message, drop the PATH message, and return.

        o    If, during the PSB search, achieved by a PSB is found with group of
         inter-related traffic control functions:  a matching
             sender host (in SENDER_TEMPLATE) but the SrcPorts differ
             and one is zero, then build packet classifier,
         an admission control module, and send a "Ambiguous Path"
             PERR message, drop the PATH message, and return. packet scheduler.  This
         section describes a generic RSVP interface to traffic control.

         o    If there was no matching PSB, then:

             1.   Create    Make a new PSB.

             2.   Call Reservation

              Call: Rhandle =  TC_AddFlowspec( Interface, TC_Flowspec,

                                     TC_Tspec, Police_Flags )

              The TC_Flowspec parameter defines the appropriate Route_Query routine, using
                  DestAddress from SESSION and (for multicast routing)
                  SrcAddress from SENDER_TEMPLATE.  Store desired effective
              QoS to admission control; its value is computed as the values
              maximum over the flowspecs of
                  OutInterface_list and IncInterface into different next hops (see the PSB.
                  However, if
              Compare_Flowspecs call below).  It contains the sender is from effective
              reservation Tspec Resv_Te (although the local API, then
                  instead of invoking routing, set OutInterface_List RSVP daemon itself
              has no means to extract the single interface whose address matches Tspec).  The TC_Tspec
              parameter defines the effective sender
                  address; IncInterface is undefined in this case.

             3.   If IncInterface is defined and if a multicast message
                  arrived on an interface different from IncInterface,
                  drop Tspec Path_Te (see
              Section 2.3).  We assume that traffic control takes the message
              GLB of Resv_Te and return.

             4.   Set a cleanup timer for Path_Te (see step (4) in Section 2.3).
              The Police_Flags parameter carries the PSB.  If this three flags
              E_Police_Flag, M_Police_Flag, and B_Police_Flag; see
              Section 3.7.

              The TC_AddFlowspec call returns an error code if Flowspec
              is malformed or if the first
                  PSB for the session, set a refresh timer for the
                  session.

             5.   Copy contents of the SESSION, 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 either of the following objects that requested resources are present: POLICY_DATA and ADSPEC.

             6.   Turn on
              unavailable.  Otherwise, it establishes a new reservation
              channel corresponding to Rhandle.  It returns the Path_Refresh_Needed flag. opaque
              number Rhandle for subsequent references to this
              reservation.

         o    Otherwise (there    Modify Reservation

              Call: TC_ModFlowspec( Interface, Rhandle, new_Flowspec,

                                    Sender_Tspec,  Police_flags )
              This call is a matching PSB and there used to modify an existing reservation.
              New_Flowspec is no dest
             port conflict):

             1.   If there passed to Admission Control; if it is no route change notification in place,
                  call the appropriate Route_Query routine using
                  DestAddress from SESSION and (for multicast routing)
                  SrcAddress from SENDER_TEMPLATE.

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

                  -    If a multicast message arrived on force.  The
              corresponding filter specs, if any, are not affected.  The
              other parameters are defined as in TC_AddFlowspec.

         o    Delete Flowspec

              Call: TC_DelFlowspec( Interface, Rhandle )

              This call will delete an interface
                       different from IncInterface, drop existing reservation, including
              the message flowspec and
                       return.

             2.   If the PHOP IP address, the LIH, or SENDER_TSPEC
                  differs between all associated filter specs.

         o    Add Filter Spec

              Call: FHandle = TC_AddFilter( Interface, Rhandle,

                                          Session , FilterSpec )

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

         o    Delete Filter Spec

              Call: TC_DelFilter( Interface, FHandle )

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

         o    OPWA Update

              Call: TC_Advertise( Interface, Adspec )

                                                  -> New_Adspec

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

         o    Preemption Upcall

              Upcall: TC_Preempt() -> RHandle, Reason_code
              In order to grant a new
                  value into the PSB, execute reservation request, the RESV REFRESH event
                  sequence for admission
              control and/or policy modules may preempt an existing
              reservation.  This might be reflected in an upcall to
              RSVP, passing the sender defined by RHandle of the PSB, preempted reservation and turn
                  on the Path_Refresh_Needed flag.

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

                  However, if sub-code indicating the PATH message being processed came reason.

      3.10.3 RSVP/Routing Interface

         An RSVP implementation needs the following support from
                  a local application the
         packet forwarding and if there is reservation state
                  for this session, then make a Resv Event upcall to
                  that application instead routing mechanisms of executing the RESV REFRESH
                  sequence.

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

             3.   Restart the cleanup timer. node.

         o    If    Promiscuous Receive Mode for RSVP Messages

              Packets received for IP protocol 46 but not addressed to
              the message arrived with a TTL different from Send_TTL
             in node must be diverted to the RSVP common header, set the Non_RSVP flag on in program for
              processing, without being forwarded.  On a router, the
             PSB.

        o    If
              identity of the Path_Refresh_Needed flag interface, real or virtual, on which it is now set then:

             1.   If this PATH message came from
              received must also be available to the RSVP daemon.

              The RSVP messages to be diverted will carry the Router
              Alert IP option, which can be used to pick them out of a network interface
              high-speed forwarding path.  Alternatively, the node can
              intercept all protocol 46 packets.

         o    Route Query

              To forward PATH and
                  not from a local application, make a Path Event upcall
                  for each local application PTEAR messages, an RSVP daemon must be
              able to query the routing daemon(s) for this session:

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

                 Ucast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag )

             2.   Execute

                                        -> OutInterface

                 Mcast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag )

                                        -> [ IncInterface, ] OutInterface_list

              Depending upon the PATH REFRESH event sequence (below) for routing protocol, the sender defined by query may or may
              not depend upon SrcAddress, i.e., upon the PSB.

   PATH TEAR MESSAGE ARRIVES

        o    Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
             matches sender host IP
              address, which is also the corresponding objects in 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 no
             matching PSB the Notify_flag is found, drop True,
              routing will save state necessary to issue unsolicited
              route change notification callbacks (see below) whenever
              the PTEAR message and return.

        o    Forward specified route changes.

              A multicast route query may return an empty
              OutInterface_list if there are no receivers downstream of
              a copy 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 to each outgoing
             interface listed in OutInterface_list of the PSB.

        o    Find each RSB that matches this PSB, i.e., whose
             FILTER_SPEC object matches the SENDER_TEMPLATE in for the PSB
             and whose OI is included in OutInterface_list.

             If requested route did arrive at this RSB matches no other PSB, then tear down node).
              In either case, the RSB, local state should be updated as described below under RESV TEAR MESSAGE ARRIVES.

        o    Delete the PSB.

        o    Drop
              requested by the PTEAR message and return.

   PATH ERROR MESSAGE ARRIVES

        o    Search message, which cannot be forwarded
              further.  Updating local state will make path state
              available immediately for a PSB whose (SESSION, SENDER_TEMPLATE) pair
             matches the corresponding objects in the message.  If no
             matching PSB is found, drop the PERR message and return. new local receiver, or it will
              tear down path state immediately.

         o    Route Change Notification

              If requested by a route query with the previous hop address in the PSB is Notify_flag True,
              the local API,
             make routing daemon may provide an error upcall to the application:

                 Call: <Upcall_Proc>( session-id, Path Error,
                               Error_code, Error_value, Node_Addr,
                               0, 1, NULL, SENDER_TEMPLATE,
                               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 asynchronous callback to understand
             the errors.]  Drop
              the PERR message and return. RSVP daemon that a specified route has changed.

                 Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,

                                                OutInterface

                 Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,

                               [ IncInterface, ] OutInterface_list

         o    Otherwise, send    Outgoing Link Specification

              RSVP must be able to force a copy of the PERR message (multicast) datagram to be
              sent on a specific outgoing virtual link, bypassing the PHOP IP
             address, drop the PERR message, and return.

   RESV MESSAGE ARRIVES

        Initially, the Resv_Refresh_PHOP* list is empty and the
        Resv_Refresh_Needed flag
              normal routing mechanism.  A virtual link may be a real
              outgoing link or a multicast tunnel.  Outgoing link
              specification is off.  These variables are used necessary to
        control immediate reservation refreshes.

        o    Process the NHOP object

             The logical send different versions of
              an outgoing interface OI PATH message on different interfaces.  It is taken from the LIH
              also necessary in
             the NHOP object.  (If the physical interface is not implied
             by the LIH, it can some cases to avoid routing loops.

         o    Source Address Specification

              RSVP must be learned from the interface matching able to specify the IP destination address). source address to be
              used when sending PATH messages.

         o    Check the SESSION object.

             If there    Interface List Discovery

              RSVP must be able to learn what real and virtual
              interfaces are no existing PSB's active, with their IP addresses.

              It should be possible to logically disable an interface
              for SESSION then build and
             send RSVP.  When an interface is disabled for RSVP, a RERR PATH
              message (as described later) specifying "No
             path information", drop the RESV message, should never be forwarded out that interface, and return.
             However, do not send the RERR message
              if the style has
             wildcard reservation scope and this an RSVP message is received on that interface, the receiver host
             itself.

             [LZ: Explain this?]

        o    Check the S_POLICY_DATA object.

             If there is an S_POLICY_DATA object
              message should be silently discarded (perhaps with local
              logging).

      3.10.4 Service-Dependent Manipulations

         Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP;
         their contents are defined in the message, check
             permission service specification documents.
         In order to create a reservation for the session.  If the
             check fails, build and send an "Administrative rejection"
             RERR message, drop manipulate these objects, RSVP daemon must have
         available to it the RESV message, and return.
             Otherwise, copy 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 S_POLICY_DATA object into
              Tspecs that are contained.  Although the RSB.

        Now process RSVP daemon
              cannot itself parse a flowspec to extract the STYLE object and Tspec, it
              can use the flow descriptor list Compare_Flowspecs call to
        make reservations, as follows.

        For FF style, execute implicitly calculate
              Resv_Te (see Section 2.3).

         o    Compute LUB of Flowspecs

                 LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
                   Flowspec_LUB

         o    Compute GLB of Flowspecs

                 GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
                   Flowspec_GLB

         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 following steps independently for each
        b flow descriptor, i.e., rules for each (FLOWSPEC, FILTER_SPEC) pair.
        For FF style, FILTER_SPEC* consists RSVP
   operation.  It is intended to outline a set of algorithms that will
   accomplish the single FILTER_SPEC
        from needed function, omitting some details.

   This section assumes the flow descriptor.

        For SE style, execute generic interface calls defined in Section
   3.10 and the following steps once, with
        FILTER_SPEC* consisting of the list of FILTER_SPEC objects from
        the flow descriptor.

        For WF style, execute the following steps once, with
        FILTER_SPEC* consisting of data structures.  An actual implementation may
   use additional or different data structures and interfaces.  The data
   structure fields that a single internal placeholder
        "WILD_FILTER". shown are required unless they are explicitly
   labelled as optional.

   o    If the DstPort in the    PSB -- Path State Block

        Each PSB holds path state for a particular (session, sender)
        pair, defined by SESSION object is zero but the
             SrcPort and SENDER_TEMPLATE objects,
        respectively, received in the FILTER_SPEC object is non-zero, build a send
             a "Conflicting Src Port" RERR message, drop PATH message.

        PSB contents include the RESV
             message, and return.

        o    Find or create following values from a reservation state block (RSB) for PATH message:

        -    Session

        -    Sender_Template

        -    Sender_Tspec

        -    The previous hop IP address and the
             triple: (SESSION, NHOP, FILTER_SPEC*).  Call this Logical Interface
             Handle (LIH) from a PHOP object

        -    The remaining IP TTL

        -    POLICY_DATA and/or ADSPEC objects (optional)

        -    Non_RSVP and Maybe_RSVP flags; see Section 3.7.

        -    E_Police flag (Section 3.7)

        -    Local_Only flag (Section 3.8)

        In addition, the
             "active RSB".

        o    If PSB contains the RSB following information provided
        by routing: OutInterface_list, which is not new the list of outgoing
        interfaces for this (sender, destination), and if its style IncInterface,
        which is incompatible with
             the STYLE object in the message, build expected incoming interface.  For a unicast
        destination, OutInterface_list contains one entry and send
        IncInterface is undefined.

   o    RSB -- Reservation State Block
        Each RSB holds a RERR
             message specifying "Conflicting Style", drop the reservation request that arrived in a
        particular RESV message, and return.

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

        o    If the active triple:  (session,
        next hop, Filter_spec_list).  Here "Filter_spec_list" may be a
        list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF
        style), or empty (WF style).  We define a virtual object type
        "FILTER_SPEC*" for such a data structure.

        RSB contents include:

        -    Session specification

        -    Next hop IP address

        -    Filter_spec_list

        -    The outgoing (logical) interface OI on which the
             reservation is not new, check whether FLOWSPEC to be made or has been made (required).

        -    Style

        -    Flowspec

        -    A POLICY_DATA object (optional)

        -    A SCOPE objects have changed.  If not, continue with the next
             flow descriptor in the RESV message, if any. object (optional, depending on style)

        -    A RESV_CONFIRM object (optional)

   o    If    TCSB -- Traffic Control State Block

        Each TCSB holds the active RSB is new, set its OI and style, and copy
             any FLOWSPEC, POLICY_DATA, and/or SCOPE objects into it.

        o    If there is reservation specification that has been
        handed to traffic control for a RESV_CONFIRM in specific outgoing interface.  In
        general, TCSB information is derived from RSB's for the message, turn on
             Resv_Refresh_Needed and save same
        outgoing interface.  Each TCSB defines a single reservation for
        a particular triple: (session, OI, Filter_spec_list).   TCSB
        contents include:

        -    Session

        -    OI

        -    Filter_spec_list

        -    TC_Flowspec, the object in effective flowspec, i.e., the RSB.

        o    The active RSB must be new or changed.  Compute maximum over
             the corresponding FLOWSPEC values from matching RSB's.
             TC_Flowspec is passed to traffic control parameters, using the following steps.

             1.   Locate to make the set actual
             reservation.  The Tspec part of PSBs (senders) whose
                  SENDER_TEMPLATEs match FILTER_SPEC* in TC_Flowspec is the active RSB
                  and whose OutInterface_list includes OI.

                  If this set is empty, build and send an error message
                  specifying "No
             effective reservation Tspec Resv_Te (Section 2.3).

        -    TC_Tspec, equal to Path_Te, the effective sender information", Tspec.

        -    Police Flags

             The flags E_Police_Flag, M_Police_Flag, and continue with
                  the next flow descriptor B_Police_Flag
             are defined in Section 3.7.

        -    Rhandle, F_Handle_list

             Handles returned by the RESV message.

             2.   If this set contains more than one PSB traffic control interface,
             corresponding to the reservation (flowspec) and if to the list
             of filter specs.

   o    BSB -- Blockade State Block

        Each BSB contains an element of blockade state.  Depending upon
        the reservation style has explicit sender selection (e.g., FF in use, the BSB's may be per (session,
        sender_template) or SE),
                  build and send per (session, PHOP).  In practice, an error message specifying "Ambiguous
        implementation might embed a BSB within a PSB; however, for
        clarity we describe BSB's independently.

        The contents of a BSB include:

        -    Session

        -    Sender_Template (which is also a filter spec" and continue with the next flow
                  descriptor.

             3.   Add the spec)

        -    PHOP from the PSB

        -    FLOWSPEC Qb

        -    Blockade timer Tb

   The following other variables are also used in this section: Boolean
   flags Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed,
   Need_Scope, B_Merge, and NeworMod, and Refresh_PHOP_list, a
   variable-length list of PHOPs to the Resv_Refresh_PHOP*
                  list, be refreshed.

   MESSAGE ARRIVES

   Verify version number and RSVP checksum, and discard message if any
   mismatch is found.

   If the PHOP message type is not already on the list.

             4.   Set TC_E_Police_flag on PATH or PTEAR and if the IP destination
   address does not match any of these PSBs have
                  their E_Police flag on.  Set TC_M_Police_flag on if it
                  is a shared style and there is more than one PSB in
                  the set.

             5.   Compute Path_Te as the sum addresses of the SENDER_TSPEC objects
                  in this set of PSBs.

             6.   Scan all RSB's matching local interfaces,
   then forward the SESSION message to IP destination address and
                  Filter_Spec_list from return.

   Verify the message.

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

   Reassemble fragments of these RSB's has a style that is
                       incompatible with message.

   Parse the specifying "Conflicting
                       Style", drop sequence of objects in the RESV message, delete the RSB if
                       it has just been created, and return.

                  -    Set TC_B_Police_flag on discard message if TC_Flowspec is smaller
                       than, or incomparable to,
   any FLOWSPEC in those
                       RSB's.

             7.   Consider required objects are missing.  Verify the set length field of RSB's for the same (SESSION, OI,
                  Filter_Spec_list) triple from the message.

                  -    Compute the effective kernel flowspec,
                       TC_Flowspec, as
   common header, and discard message if there is a mismatch.

   Verify the maximum consistent use of port fields.  If the FLOWSPEC
                       values DstPort in these RSB's.

                  -    Compute the effective kernel filter spec (list),
                       TC_Filter*. by merging the FILTER_SPEC*
   SESSION object
                       (lists) from these RSB's.

        o    Search for a TCSB matching the triple (SESSION, OI,
             FILTER_SPEC*), taken from the RSB.

             1.   If none is found zero but style the SrcPort in a SENDER_TEMPLATE or
   FILTER_SPEC object is SE, search for non-zero, the the message has a TCSB
                  matching (SESSION, OI).  If find one and if TCSB's
                  TC_Flowspec, Path_Te, and police flags match "conflicting
   source port" error; discard the
                  computed values, then

                  -    Make an appropriate set of TC_DelFilter message and
                       TC_AddFilter calls to transform return.

   Further processing depends upon message type.

   PATH MESSAGE ARRIVES

        Process the
                       Filter_Spec_list sender descriptor object sequence in the TCSB into the
                       Filter_Spec_list from the message.

                  -    Set Resv_Refresh_Needed on, drop the RESV
                       message, message as
        follows.  The Path_Refresh_Needed and return.

             2.   Otherwise, if none Resv_Refresh_Needed flags
        are initially off.

        o    If there is found:

                  -    Create a new TCSB.

                  -    Store TC_Flowspec, Filter_Spec_list, Path_Te, and
                       the 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, POLICY_DATA object, verify it; if it is
             unacceptable, build and send a RERR message
                       specifying "Admission control failed", and
                       continue with the next flow descriptor.
                       Otherwise, record Rhandle in "Administrative Rejection"
             PERR message, drop the TCSB.

                  -    For each filter_spec F in Filter_Spec_list, call:

                          Fhandle = TC_AddFilter( Rhandle, SESSION, F) PATH message, and record return.

        o    Search for a path state block (PSB) whose (session,
             sender_template) pair matches the returned Fhandle corresponding objects in
             the TCSB.

                  -    Continue with message.

        o    If, during the next flow descriptor.

             3.   Otherwise (found existing TCSB), check whether
                  TC_Flowspec, Path_Te, and/or any of PSB search, a PSB is found whose session
             matches the police flags
                  has changed, and if so:

                  -    Store TC_Flowspec, Filter_Spec_list, Path_Te, DestAddress and Protocol Id fields of the police flags into it.

                       [SCOPE?]

                  -    Set Resv_Refresh_Needed on.

                  -    Make
             received SESSION object, but the 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 DstPorts differ and one is
             zero, then build and send a "Conflicting Dst Port" PERR
             message, drop the next flow descriptor. PATH message, and return.

        o    If    If, during the Resv_Refresh_Needed flag PSB search, a PSB is now on, execute found with a matching
             sender host but the RESV
             REFRESH sequence (below) for each PHOP in SrcPorts differ and one of the
             Resv_Refresh_PHOP* set.

        If processing a RESV message finds an error, a RERR message SrcPorts
             is
        created containing flow descriptor zero, then build and send an ERRORS object.  The
        Error Node field "Ambiguous Path" PERR
             message, drop the PATH message, and return.

        o    If there was no matching PSB, then:

             1.   Create a new PSB.

             2.   Copy contents of the ERRORS object (see Appendix A) SESSION, SENDER_TEMPLATE,
                  SENDER_TSPEC, and PHOP (IP address and LIH) objects
                  into the PSB.

             3.   Calculate initial routing information.  If the sender
                  is from the local API, OutInterface_List is set to the IP
                  single interface whose address matches the sender
                  address, and IncInterface is undefined.  Otherwise,
                  call the appropriate Route_Query routine, using
                  DestAddress from SESSION and (for multicast routing)
                  SrcAddress from SENDER_TEMPLATE.  Store the values of OI,
                  OutInterface_list and IncInterface into the message PSB.

             4.   If IncInterface is sent unicast to NHOP.

   RESV TEAR MESSAGE ARRIVES

        A RTEAR defined and if a multicast message arrives with
                  arrived on an IP destination address matching
        outgoing interface OI.  Flags Tear_Needed and
        Resv_Refresh_Needed are initially off and Resv_Refresh_PHOP*
        list is empty.

        o    Process the STYLE object and different from IncInterface,
                  turn on the flow descriptor list Local_Only flag in the RTEAR message to tear down local reservation state, as
             follows.

             For FF style, execute PSB.

             5.   If this is the following steps for each b flow
             descriptor, i.e., first PSB 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 session, set a single internal
             placeholder "WILD_FILTER".

             1.   Find matching RSB
                  refresh timer for the 4-tuple: (SESSION, NHOP,
                  style, Filter_Spec_list); call this session.

             6.   Turn on the active RSB. Path_Refresh_Needed flag.

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

             1.   If there is no active RSB is found, continue with next flow
                  descriptor.

             2.   Delete the active RSB.

             3.   Find TCSB for the triple: (SESSION, OI,
                  Filter_Spec_list).

             4.   Consider route change notification in place,
                  call the set of RSB's matching this TCSB.  If
                  there are none: appropriate Route_Query routine using
                  DestAddress from SESSION and (for multicast routing)
                  SrcAddress from Sender_Template.

                  -    Call    If the traffic control interface routine:

                          TC_DelFlowspec( Rhandle )

                  -    Delete OutInterface_list that is returned differs
                       from that in the TCSB and set Tear_Needed flag on. PSB, then execute the PATH LOCAL
                       REPAIR event sequence below.

                  -    Continue with    If a multicast message arrived on an interface
                       different from IncInterface, then execute the next flow descriptor.

             5.   Otherwise (there are other RSB's
                       RESV REFRESH event sequence below for the same TCSB),
                  recompute TC_Flowspec and Path_Te (see RESV MESSAGE
                  ARRIVES).  (This also adds
                       previous hop.

             2.   If the appropriate PHOP
                  addresses to IP address, the Resv_Refresh_PHOP* list>) If either
                  changed, update LIH, or Sender_Tspec
                  differs between the TCSB, set flag Resv_Refresh_Needed
                  on, message 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 kernel call should not fail, since the
                  reservation can only be reduced.

             [LZ: Suppose receiver R has PSB, copy the credential to make new
                  value into the
             reservation PSB and others took a ride turn on top of R's
             credential.  Now R tears down its request, what should
             happen?  Shouldn't TEAR take policy data as input?] the Path_Refresh_Needed
                  flag.

        o    If Tear_Needed and Resv_Refresh_Needed flags are both off,
             then drop the RTEAR message and return. contains an ADSPEC object, copy it into the
             PSB.

        o    If Tear_Needed is off but Resv_Refresh_Needed is on, then
             execute    Start or Restart the RESV REFRESH sequence cleanup timer for each PHOP in the
             Resv_Refresh_PHOP* set, drop the RTEAR message, and return. PSB.

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

             Do    Copy E_Police flag from SESSION object into PSB.

        o    Store the following for each PSB whose OutInterface_list
             includes received TTL into the outgoing interface OI:

             1.   Pick each flow descriptor Fj PSB.

             If the the received TTL differs from Send_TTL in the RTEAR message
                  whose FILTER_SPEC matches RSVP
             common header, set the PSB, Non_RSVP flag on in the PSB.

        o    The Path_Refresh_Needed flag is now set if the path state
             is new or modified.  If so:

             1.   If this PATH message came from a network interface and do
                  not from a local application, make a Path Event upcall
                  for each local application for this session:

                      Call: <Upcall_Proc>( session-id, PATH_EVENT,
                                  flags, sender_tspec, sender_template,
                                  [ADSPEC], [POLICY_DATA] )

             2.   Execute the
                  following.

                  - PATH REFRESH event sequence (below) for
                  the sender defined by the PSB.

             3.   If there is no RSB whose FILTER_SPEC matches the
                       PSB, reservation state for this SESSION
                  (i.e., no RSB's exist), then add Fj to drop the new RTEAR PATH message being
                       built.

                  - and
                  return.

             4.   Otherwise (there is a matching RSB), note the PSB
                       as needing a RESV refresh message and set the
                       Resv_Refresh_Needed flag True.

             2.   If reservation state):

                  -    Execute the new RTEAR message contains any flow
                  descriptors, send it event sequence UPDATE TRAFFIC CONTROL
                       below, to PHOP in update the PSB.

        o    If local traffic control state
                       if necessary.  This will turn on the
                       Resv_Refresh_Needed flag is now on, if the traffic control
                       state changes; if so, execute the RESV REFRESH
                       event sequence (below) for each PHOP the sender in the
             Resv_Refresh_PHOP* set.

             If PSB.

                       However, if the Refresh_Needed flag is true, PATH message came from a local
                       application, then execute the RESV
             REFRESH sequence for the PSB's make a RESV_EVENT upcall to
                       that have been noted. application.

        o    Drop the RTEAR PATH message and return.

   RESV ERROR

   PATH TEAR MESSAGE ARRIVES

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

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

        o    Do    Forward a copy of the following with PTEAR message to each outgoing
             interface listed in OutInterface_list of the PSB.

        o    Find each RSB for that matches this SESSION whose OI
             does not match In_If and PSB, i.e., that whose FILTER_SPEC
             Filter_spec_list matches that Sender_Template in the RERR message.

             1.   Copy the error flow descriptor from PSB and
             whose OI is included in OutInterface_list.

             If this RSB matches no other PSB, then tear down the incoming RERR
                  message.

             2.   Compare RSB,
             as described below under RESV TEAR MESSAGE ARRIVES.

        o    Delete the FLOWSPEC in PSB.

        o    Drop the RERR PTEAR message with and return.

   PATH ERROR MESSAGE ARRIVES

        o    Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
             matches the
                  FLOWSPEC corresponding objects in the RSB. message.  If they don't match along any
                  coordinate (i.e., if the RSB FLOWSPEC no
             matching PSB is strictly
                  `smaller'), continue with found, drop the next RSB. PERR message and return.

        o    If they agree on some but not all coordinates, turn on the LUB-used flag.

             3.   If NHOP previous hop address in RSB the PSB is the local API, deliver
             make an error upcall to the application:

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

             Any SENDER_TSPEC or ADSPEC object in the message is
             ignored.

             Otherwise, send a copy of the PERR message to the PHOP IP
             address.

        o    Drop the PERR message and return.

   RESV MESSAGE ARRIVES

        Initially, Refresh_PHOP_list is empty and continue with the next RSB.  Here k,
                  Filter_Spec_List,
        Resv_Refresh_Needed and Flowspec_List NeworMod flags are constructed
                  from the error flow descriptor.

             4.   If off.  These variables
        are used to control immediate reservation refreshes.

        o    Determine the RESV message has wildcard sender selection, use
                  its SCOPE object 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 that route
                  to Outgoing Interface OI

             The logical outgoing interface OI [LIH?], as determined by scanning the PSB's.  If
                  SC.Out is empty, continue with the next RSB.

             5.   Create a new RERR message containing taken from the error flow
                  descriptor and send to LIH in
             the NHOP address specified object.  (If the physical interface is not implied
             by the RSB.  Include SC.Out if LIH, it can be learned from the sender selection is
                  wildcard.

             6.   Continue with interface matching
             the next RSB. IP destination address).

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

   RESV CONFIRMATION ARRIVES

        If

        o    Check the (unicast) IP address found in its RESV_CONFIRM object
        matches S_POLICY_DATA object.

             If there is an interface of S_POLICY_DATA object in the node, a confirmation upcall is made message, check
             permission to create a reservation for the matching application:

                    Call: <Upcall_Proc>( session-id, Resv Confirm,
                              Error_code, Error_value, Node_Addr,
                              LUB-Used, nlist, Flowspec,
                              Filter_Spec_List, NULL, NULL ) session.  If the
             check fails, build and send an "Administrative rejection"
             RERR message, drop the RESV message, and return.
             Otherwise, copy the RACK message S_POLICY_DATA object into the RSB.

        o    Check for incompatible styles.

             If any existing RSB for the session has a style that is forwarded immediately to
             incompatible with the
        address in style of the IP address in its RESV_CONFIRM object.

   PATH REFRESH

        This sequence sends message, build and send
             a path refresh for a particular sender,
        i.e., a PSB.  This sequence may be entered by either RERR message specifying "Conflicting Style", drop the
        expiration of
             RESV message, and return.

        Process the path refresh timer or directly flow descriptor list to make reservations, as
        follows, depending upon the result style.  The following uses a filter
        spec list struct Filtss, of type FILTER_SPEC* (defined earlier).

        For FF style: execute the Path_Refresh_Needed flag being turned on during following steps independently for each
        flow descriptor in the
        processing message, i.e., for each (FLOWSPEC,
        Filtss) pair.  Here the structure Filtss consists of a received PATH message.

        o    Compute the IP TTL for
        FILTER_SPEC from the PATH message as one less than flow descriptor.

        For SE style, execute the maximum following steps once for (FLOWSPEC,
        Filtss), with Filtss consisting of the TTL values list of FILTER_SPEC
        objects from the senders included flow descriptor.

        For WF style, execute the following steps once for (FLOWSPEC,
        Filtss), with Filtss an empty list.

        o    If the DstPort in the message.  However, if SESSION object is zero but the result
             SrcPort in a FILTER_SPEC object (in Filtss) is zero, return
             without sending non-zero,
             build nd send a "Conflicting Src Port" RERR message, drop
             the PATH message.

        o    Insert TIME_VALUES RESV message, and PHOP objects into return.

        o    Check the PATH path state, as follows.

             1.   Locate the set of PSBs (senders) whose
                  SENDER_TEMPLATEs match Filtss and whose
                  OutInterface_list includes OI.

                  If this set is empty, build and send an error message
             being built.

        o    Create a
                  specifying "No sender information", and continue with
                  the next flow descriptor containing in the SENDER_TEMPLATE,
             SENDER_TSPEC, RESV message.

             2.   If the style has explicit sender selection (e.g., FF
                  or SE) and POLICY_DATA objects, if present any FILTER_SPEC included in the Filtss
                  matches more than one PSB, build and pack it into the PATH send a RERR
                  message being built.

        o    Pass any ADSPEC specifying "Ambiguous filter spec" and SENDER_TSPEC objects present
                  continue with the next flow descriptor in the RESV
                  message.

             3.   Add the PHOP from the PSB to Refresh_PHOP_list, if the traffic control call TC_Advertise.  Insert the
             modified ADSPEC object that
                  PHOP is returned into not already on the PATH
             message being built. list.

        o    Find or create a reservation state block (RSB) for the
             triple: (session, NHOP, Filtss).  Call this the "active
             RSB".

        o    If the PSB has active RSB is new:

             1.   Set the E_Police flag on and if interface session, NHOP, OI is
             not capable and style of policing, turn the E_Police flag on in RSB from
                  the
             PATH message being built.

        o    Send a copy message.

             2.   Copy Filtss into the Filter_spec_list of the PATH message to each interface in
             OutInterfact_list.  Before sending each copy, insert into
             its PHOP object RSB.

             3.   Copy the interface address FLOWSPEC and any SCOPE object from the LIH for the
             interface.

   RESV REFRESH

        This sequence sends a reservation refresh towards a particular
        previous hop with IP address PH.  This sequence may be entered
        by either
                  message into the expiration of a reservation refresh timer RSB.

             4.   Set NeworMod flag on.

        o    Start or
        directly as the result of restart the Resv_Refresh_Needed flag being
        turned cleanup timer on as the result of processing a RESV or RTEAR message.

        In general, this sequence considers each of the PSB's with PHOP
        address PH.  For active RSB.

        o    If there is a given PSB, it scans RESV_CONFIRM in the RSBs for matching
        reservations message, turn on
             Resv_Refresh_Needed and merges save the styles, FLOWSPECs and FILTER_SPEC*'s
        appropriately.  It then builds a RESV message and sends it to
        PH.  The details depend upon the attributes of the style(s)
        included object in the reservations. RSB.

        o    If there are PSB's from more than one PHOP and if the
             multicast routing protocol does active RSB is not use shared trees, set
             the Need_Scope flag on, otherwise set it off.

        o    Create an output message containing SESSION, RSVP_HOP,
             INTEGRITY, new, check whether STYLE, FLOWSPEC
             or SCOPE objects have changed; if so, copy changed object
             into RSB and TIME_VALUES objects. turn on the NeworMod flag.

        o    Select each sender PSB whose PHOP has address PH.

             1.   Select all RSB's whose FILTER_SPEC*'s match    If NeworMod flag is off, continue with the
                  SENDER_TEMPLATE object next flow
             descriptor in the PSB and whose OI appears
                  in RESV message, if any.

        o    Otherwise (the NeworMod flag is on, i.e., the OutInterface_list of active RSB is
             new or modified), execute the PSB.

             2.   Get a STYLE object from UPDATE TRAFFIC CONTROL event
             sequence (below).  If the first RSB and move result is to modify the traffic
             control state, it into will turn on the output message.  (Note that Resv_Refresh_Needed
             flag.

        o    For any local sender, make an RESV_EVENT upcall to the present set of
                  styles are never themselves merged; if future styles
                  can be merged, these rules will become more complex).

             3.   Compute
             application:

                          Call: <Upcall_Proc>( session-id, RESV_EVENT,
                                  style, Flowspec, Filter_spec_list,
                                  [POLICY_DATA] )

             where the maximum/LUB over parameters come from the FLOWSPEC objects of
                  this set of RSB's.

             4.   While computing active RSB.

        o    Continue with the maximum/LUB, next flow descriptor.

        o    When all flow descriptors have been processed, check for a
                  RESV_CONFIRM object in each RSB. the
             Resv_Refresh_Needed flag.  If a RESV_CONFIRM
                  object it is found and if now on, execute the FLOWSPEC
             RESV REFRESH sequence (below) for each PHOP in that RSB is
                  larger than all other flowspecs being compared, then
                  save this RESV_CONFIRM object.
             Refresh_PHOP_list.

        o    Drop the RESV message and return.

        If processing a RESV_CONFIRM
                  object RESV message finds an error, a RERR message is found but
        created containing flow descriptor and an ERRORS object.  The
        Error Node field of the corresponding FLOWSPEC ERRORS object is
                  equal or smaller than the largest, or if set to the result IP address
        of
                  merging was a LUB, then create OI, and send a RACK the message is sent unicast to the NHOP.

   RESV TEAR MESSAGE ARRIVES

        A RTEAR message arrives with an IP destination address in the RESV_CONFIRM object.

                  -    Include the RESV_CONFIRM object in matching
        outgoing interface OI.  Flags Tear_Needed and
        Resv_Refresh_Needed are initially off and Refresh_PHOP_list is
        empty.

        o    Process the RACK
                       message.

                  -    Build a confirmation ERROR_SPEC STYLE object and
                       include it the flow descriptor list in
             the RACK message. RTEAR message to tear down local reservation state, as
             follows.

             The Error_Node
                       parameter following uses a filter spec list struct Filtss, of
             type FILTER_SPEC* (defined earlier).

             For FF style: execute the following steps independently for
             each flow descriptor in this object should be the IP address
                       of OI from message, i.e., for each
             (FLOWSPEC, Filtss) pair.  Here the RSB.

                  Then delete structure Filtss
             consists of the RESV_CONFIRM object FILTER_SPEC from the RSB.

             5.   Merge flow descriptor.

             For SE style, execute the matching following steps once for
             (FLOWSPEC, Filtss), with Filtss consisting of the list of
             FILTER_SPEC objects from this set
                  of RSB's.  The merging rule depend upon the style:

                  Explicit sender selection (FF, SE) styles:

                       Use flow descriptor.

             For WF style, execute the SENDER_TEMPLATE as following steps once for
             (FLOWSPEC, Filtss), with Filtss an empty list.

             1.   Find matching RSB for the merged
                       FILTER_SPEC.

                  Wildcard sender selection (WF) style:

                       There is no filter spec to merge.

             6.   If triple: (SESSION, NHOP,
                  Filtss); call this the Need_Scope flag active RSB.  If no active RSB
                  is on, compute a new SCOPE
                  object as the union of the SCOPE objects found in found, continue with next flow descriptor.

             2.   Delete the
                  RSB's.

             7.   Merge active RSB.

             3.   Execute the F_POLICY_DATA objects from event sequence UPDATE TRAFFIC CONTROL
                  (below) to update the RSB's.

             8.   (All matching RSB's have been processed).  The next
                  step depends upon traffic control state to be
                  consistent with the style attributes.

                  Distinct reservation (FF) style

                       Pack the merged (FLOWSPEC, FILTER_SPEC,
                       F_POLICY_DATA) triplet into the message as state.

             4.   Search for a flow
                       descriptor.

                  Shared reservation (SE, WF) styles

                       Merge (take TCSB remaining for the maximum) across all PSB's (session, OI,
                  Filtss) triple; if not, set the
                       merged FLOWSPECS from Tear_Needed flag on.

             5.   Continue with the RSB's. next flow descriptor.

        o    If Tear_Needed and Resv_Refresh_Needed flags are both off,
             then drop the sender selection RTEAR message and return.

        o    If Tear_Needed is not wildcard (i.e., if
                       it off but Resv_Refresh_Needed is SE), form the union of on, then
             execute the FILTER_SPECs
                       obtained from RESV REFRESH sequence for each PHOP in
             Refresh_PHOP_list, drop the RSB's.  For Wildcard sender
                       selection (WF) style, there RTEAR message, and return.

        o    Otherwise (Tear_Needed is not filter spec on), need to
                       merge.

             9.   If forward RTEAR and/or
             RESV refresh messages.

             Do the Need_Scope flag is on, remove from following for each PSB whose OutInterface_list
             includes the merged
                  SCOPE object all sender addresses that do not match outgoing interface OI:

             1.   Pick each flow descriptor Fj in the set of PSB's for PH, RTEAR message
                  whose FILTER_SPEC matches the PSB, and all senders addresses
                  that are local.  If do the resulting set
                  following.

                  -    If there is empty, no
                  RESV should be forwarded RSB whose FILTER_SPEC matches the
                       PSB, then add Fj 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
             style is RTEAR message being built, move
                       built.

                  -    Otherwise (there is a matching RSB), note the final merged FLOWSPEC,
             F_POLICY_DATA, PSB
                       as needing a RESV refresh message and FILTER_SPEC (if SE) objects into set the
             message.

        o
                       Resv_Refresh_Needed flag True.

             2.   If a RESV_CONFIRM object was saved earlier, copy it into the new RESV RTEAR message and delete contains any flow
                  descriptors, send it from the RSB to PHOP in which it
             was found. the PSB.

        o    Set    If the RSVP_HOP object Resv_Refresh_Needed flag is now on, execute the RESV
             REFRESH sequence (below) for each PHOP in
             Refresh_PHOP_list.

        o    Drop the RTEAR message to contain the
             IncInterface address through which it will be sent and return.

   RESV ERROR MESSAGE ARRIVES

        A RERR message arrives through the
             LIH from (one of) the PSB's. (real) incoming interface
        In_If.

        o    Send    If there is no path state for SESSION, drop the RERR
             message to and return.

        o    If the address PH.

APPENDIX A. Object Definitions

   C-Types are defined for Error Code = 01 (Admission Control failure), do
             special processing as follows:

             1.   Find or create a Blockade State Block (BSB), in the two Internet address families IPv4 and
   IP6.  To accommodate other address families, additional C-Types could
   easily
                  following style-dependent manner.

                  For WF (wildcard) style, there will be defined.  These definitions are contained as an Appendix,
   to ease updating.

   All unused fields should one BSB per
                  (session, PHOP) pair.

                  For FF style, there will be sent as zero and ignored on receipt.

   A.1 SESSION Class

      SESSION Class = 1.

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

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

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

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +               IP6 DestAddress (16 bytes)              +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           | Protocol Id |     Flags   |          DstPort          |
           +-------------+-------------+-------------+-------------+

      DestAddress

           The IP unicast or multicast destination address of the
           session.  This parameter must one BSB per (session,
                  filter_spec) pair.  Note that an FF style RERR message
                  carries only one flow descriptor.

                  For SE style, there will be supplied.

      Protocol Id

           The IP Protocol Identifier one BSB per (session,
                  filter_spec), for the data flow.  This parameter
           must be supplied.

      Flags

           0x01 = E_Police flag

                The E_Police flag is used each filter_spec contained in PATH messages to determine the effective "edge"
                  filter spec list of the network, flow descriptor.

             2.   For each BSB in the preceding step, set (or replace)
                  its FLOWSPEC Qb with FLOWSPEC from the message, and
                  set (or reset) its timer Tb to control traffic
                policing. Kb*R seconds [Section
                  3.4].  If the sender host BSB is not itself capable of
                traffic policing, it will new, set this bit on in PATH
                messages it sends.  The first node whose RSVP is capable
                of traffic policing will do so (if appropriate its PHOP value, and set
                  its Sender_Template equal to the
                service) and turn appropriate
                  filter_spec from the message.

             3.   Partially execute the RESV REFRESH event sequence
                  shown below, for the previous hop PHOP.

                  In particular, execute the refresh sequence with the
                  B_Merge flag off.

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

      DstPort

           The UDP/TCP destination port for no refresh
                  messages being generated, because all matching
                  reservations are blockaded, do not turn B_Merge on but
                  instead exit the session.  Zero may be
           used to indicate a `wildcard', i.e., any port.

           Other SESSION C-Types could be defined refresh sequence and return here.

        o    For all RERR messages, execute the following for each RSB
             for this session whose OI differs from In_If and whose
             Filter_spec_list has at least one filter spec in common
             with the future to
           support other demultiplexing conventions FILTER_SPEC* in the transport-
           layer or application layer.

   A.2 RSVP_HOP Class

      RSVP_HOP class = 3.

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

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

      o    IP6 RSVP_HOP object: Class = 3, C-Type RERR message.   For WF style,
             empty FILTER_SPEC* structures are assumed to match.

             1.   If Error_Code = 2

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

      This object provides 01 and the IP address InPlace flag is 1 and one
                  or more of the interface through which
      the last RSVP-knowledgeable hop forwarded this message.  The
      Logical Interface Handle is BSB's found/created above has a 32-bit number which may be used to
      distinguish logical outgoing interfaces as described Qb that
                  is strictly greater than Flowspec in Section
      3.2; it should be identically zero the RSB, then
                  continue with the next matching RSB, if there any.

             2.   If NHOP in the RSB is no logical
      interface handle.

   A.3 INTEGRITY Class

      INTEGRITY class = 4.

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

   A.4 TIME_VALUES Class

      TIME_VALUES class = 5.

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

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

      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 ERROR_SPEC object: Class = 6, C-Type = 2

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

      Error Node Address

           The IP address of the node local API, then:

                  -    If the FLOWSPEC in which the error was detected.

      Flags

           0x01 = LUB-Used

                The use of this flag RERR message is described strictly
                       greater than the RSB Flowspec, then turn on the
                       NotGuilty flag in section 3.1.5.

      Error Code

           A one-octet the ERROR_SPEC.

                  -    Deliver an error description.

      Error Value

           A two-octet field containing additional information about upcall to application:

                                Call: <Upcall_Proc>( session-id, RESV_ERROR,
                                          Error_code, Error_value,
                                             Node_Addr,  Error_flags,
                                             Flowspec, Filter_Spec_List,
                                             [Policy_data] )

                       and continue with the
                error.  Its contents depend upon next RSB.

             3.   If the style has wildcard sender selection, use the Error Type.

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

   A.6 SCOPE Class
                  SCOPE class = 7.

      This object contains SC.In from the RERR message to construct
                  a list of IP addresses, used for routing
      messages with wildcard scope without loops.  The addresses must SCOPE object SC.Out to be
      listed forwarded.  SC.Out should
                  contain those sender addresses that appeared in ascending numerical order.

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

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

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

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

      STYLE class = 8.

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

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

      Option Vector

           A set of bit fields giving values for SC.In
                  and that route to OI [LIH?], as determined by scanning
                  the reservation
           options. PSB's.  If SC.Out is empty, continue with the next
                  RSB.

             4.   Create a new options are added RERR message containing the error flow
                  descriptor and send to the NHOP address specified by
                  the RSB.  Include SC.Out if the style has wildcard
                  sender selection.

             5.   Continue with the next RSB.

        o    Drop the RERR message and return.

   RESV CONFIRM ARRIVES

        o    If the (unicast) IP address found in the future,
           corresponding fields RESV_CONFIRM
             object in the option vector will be assigned
           from RACK message matches an interface of the least-significant end.  If a node does not recognize
             node, a style ID, it may interpret as much of confirmation upcall is made to the option vector as
           it can, ignoring new fields that may have been defined.

           The option vector bits are assigned (from matching
             application:

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

        o    Otherwise, the 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 - 111b: Reserved

      The low order bits of RACK message is forwarded immediately to the option vector are determined by
             address in the
      style, as follows:

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

      FLOWSPEC class = 9. IP address in its RESV_CONFIRM object.

        o    Class = 9, C-Type = 1:  int-serv flowspec    Drop the RACK message and return.

   UPDATE TRAFFIC CONTROL

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

      o    Class = 9, C-Type = 254:  Unmerged Flowspec List

           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 FLOWSPEC object  1                  //
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 FLOWSPEC object  2                  //
           |                                                       |
           +-------------+-------------+-------------+-------------+
           //                                                     //
           //                                                     //
           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 FLOWSPEC object  k                  //
           |                                                       |
           +-------------+-------------+-------------+-------------+

           This PATH MESSAGE ARRIVES or the RESV
        MESSAGE ARRIVES sequence, to (re-)calculate and adjust the local
        traffic control state in accordance with the current reservation
        and path state.  If the result is a container C-Type, used to enclose a set of FLOWSPEC
           objects that could not be merged at modify the next hop downstream
           because they include unrecognized C-Types.  The node that
           receives traffic control
        state, this object may merge those it recognizes and
           forward sequence turns on the rest in another Unmerged Flowspec List object.

   A.9 FILTER_SPEC Class

      FILTER_SPEC class = 10. Resv_Refresh_Needed flag.

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

           +-------------+-------------+-------------+-------------+
           |               IPv4 SrcAddress (4 bytes)               |
           +-------------+-------------+-------------+-------------+
           |    //////   |    //////   |          SrcPort          |
           +-------------+-------------+-------------+-------------+    Compute the traffic control parameters using the following
             steps.

             1.   Consider the set of RSB's matching SESSION and OI from
                  the message.

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

                  -    Compute the effective traffic control filter spec
                       (list) TC_Filter_Spec*, by merging the
                       Filter_spec_lists from these RSB's.

             2.   Scan all RSB's matching session and Filtss, for all
                  OI.  Set TC_B_Police_flag on if TC_Flowspec is smaller
                  than, or incomparable to, any FLOWSPEC in those RSB's.

             3.   Locate the set of PSBs (senders) whose
                  SENDER_TEMPLATEs match Filter_spec_list in the active
                  RSB and whose OutInterface_list includes OI.

             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 is more than one PSB in
                  the set.

             5.   Compute Path_Te as the sum of the SENDER_TSPEC objects
                  in this set of PSBs.

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

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +               IP6 SrcAddress (16 bytes)               +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |    //////   |    //////   |          SrcPort          |
           +-------------+-------------+-------------+-------------+    Search for a TCSB matching SESSION and OI; for distinct
             style (FF), it must also match Filter_spec_list.

             If none is found, create a new TCSB.

        o    IP6 Flow-label FILTER_SPEC object: Class = 10, C-Type    If TCSB is new:

             1.   Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the
                  police flags into TCSB.

             2.   Turn the Resv_Refresh_Needed flag on and make the
                  traffic control call:

                      Rhandle = 3

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

      SrcAddress TC_AddFlowspec( OI, TC_Flowspec,
                                             Path_Te, police_flags)

             3.   If this call succeeds, record Rhandle in the TCSB and,
                  for each filter_spec F in TC_Filter_Spec*, call:

                      Fhandle = TC_AddFilter( OI, Rhandle, Session, F)

                  and record the returned Fhandle in the TCSB.

             4.   Otherwise, build and send a RERR message specifying
                  "Admission control failed" and with the InPlace flag
                  off.

        o    If TCSB is not new but the TC_Flowspec, Path_Te, and/or
             police flags just computed differ from corresponding values
             in the TCSB, then:

             1.   Turn the Resv_Refresh_Needed flag on and make the
                  traffic control call:

                      TC_ModFlowspec( OI, Rhandle, TC_Flowspec,
                                            Path_Te, police_flags )

             2.   If this call fails, build and send a RERR message
                  specifying "Admission control failed" and with the
                  InPlace bit on.  If the call succeeds, update the TCSB
                  with the new values.

        o    If the TCSB is not new but the TC_Filter_Spec* just
             computed differ from the FILTER_SPEC* in the TCSB, then:

             1.   Make an appropriate set of TC_DelFilter and
                  TC_AddFilter calls to transform the Filter_spec_list
                  in the TCSB into the new TC_Filter_Spec*.

        o    Return to the event sequence that invoked this one.

   PATH REFRESH

        This sequence sends a path refresh for a particular sender,
        i.e., a PSB.  This sequence may be entered by either the
        expiration of the path refresh timer or directly as the result
        of the Path_Refresh_Needed flag being turned on during the
        processing of a received PATH message.

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

        o    Insert TIME_VALUES and PHOP objects into the PATH message
             being built.

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

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

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

        o    Send a copy of the PATH message to each interface in
             OutInterfact_list.  Before sending each copy, insert into
             its PHOP object the interface address and the LIH for the
             interface.

   RESV REFRESH

        This sequence sends a reservation refresh towards a particular
        previous hop with IP address PH.  This sequence may be entered
        by either the expiration of a reservation refresh timer or
        directly as a result of the Resv_Refresh_Needed flag being
        turned on by processing a RESV or RTEAR message.

        In general, this sequence considers each of the PSB's with PHOP
        address PH.  For a given PSB, it scans the RSBs for matching
        reservations and merges the styles, FLOWSPECs and
        Filter_spec_list's appropriately.  It then builds a RESV message
        and sends it to PH.  The details depend upon the attributes of
        the style(s) included in the reservations.

        o    Create an output message containing INTEGRITY (if
             supported), SESSION, RSVP_HOP, and TIME_VALUES objects.

        o    Determine the style for these reservations from the first
             RSB for the session, and move the STYLE object into the
             proto-message.  (Note that the present set of styles are
             never themselves merged; if future styles can be merged,
             these rules will become more complex).

        o    If style is wildcard and if there 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    Select each sender PSB whose PHOP has address PH.

             1.   Set local flag B_Merge off.

             2.   Select all RSB's whose Filter_spec_list's match the
                  SENDER_TEMPLATE object in the PSB and whose OI appears
                  in the OutInterface_list of the PSB.

             3.   If B_Merge flag is off then ignore a blockaded RSB, as
                  follows.

                  -    Select BSB's that match this RSB; if any of these
                       BSB's has a Qb that is not strictly larger than
                       RSB Flowspec, then continue processing with the
                       next RSB.

                  However, if steps 1 and 2 result in finding that all
                  RSB's matching this PSB are blockaded, then:

                  -    If this RESV REFRESH sequence was invoked from
                       RESV ERROR RECEIVED, then return now to the
                       latter.

                  -    Otherwise, turn on the B_Merge flag and restart
                       with this procedure step 1. above.

             4.   Merge the flowspecs, as follows:

                  -    If B_Merge flag is off, compute the LUB over the
                       Flowspec objects of this set of RSB's.

                       While computing the LUB, check for a RESV_CONFIRM
                       object in each RSB.  If a RESV_CONFIRM object is
                       found:

                       -     If the FLOWSPEC in that RSB is larger than
                            all other (non-blockaded) flowspecs being
                            compared, then save this RESV_CONFIRM object
                            for forwarding.

                       -    Otherwise (the corresponding FLOWSPEC is not
                            the largest) then create and send a RACK
                            message containing the RESV_CONFIRM object
                            to the address in the RESV_CONFIRM object.
                            Include the RESV_CONFIRM object in the RACK
                            message.  The RACK message should also
                            include an ERROR_SPEC object whose
                            Error_Node parameter is IP source address of OI
                            from the RSB.

                       -    Then delete the RESV_CONFIRM object from the
                            RSB.

                  -    Otherwise (B_Merge flag is on), compute the GLB
                       over the Flowspec objects of this set of RSB's.

                       While computing the GLB, check for a RESV_CONFIRM
                       object in each RSB.  If one is found, delete it.

             5.   If the Need_Scope flag is on, compute a new SCOPE
                  object as the union of the SCOPE objects found in the
                  RSB's.

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

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

             8.   Merge the matching FILTER_SPEC objects from this set
                  of RSB's.  For explicit sender selection (FF, SE)
                  styles, use the SENDER_TEMPLATE as the merged
                  FILTER_SPEC; for wildcard sender selection (WF) style,
                  there is no filter spec to be merged.

                  Distinct reservation (FF) style

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

                  Shared wildcard reservation (WF) style

                       There is no merged FILTER_SPEC.  Merge (take the
                       maximum of) the merged FLOWSPECS from the RSB's,
                       across all PSB's for a PH.

                  Shared distinct reservation (SE) style

                       Using the Sender_Template as the merged
                       FILTER_SPEC, form the union of the FILTER_SPECS
                       obtained from the RSB's.  Merge (take the maximum
                       of) the merged FLOWSPECS from the RSB's, across
                       all PSB's for PH.

             9.   If the Need_Scope flag is on, remove from the merged
                  SCOPE object all sender host, or zero to indicate
           a `wildcard'.

      SrcPort

           The UDP/TCP source port addresses that do not match
                  the set of PSB's 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 PH, and all senders addresses
                  that are local.  If the packet classifier resulting set is empty, no
                  RESV should be forwarded to efficiently identify this PHOP; return.
                  Otherwise (set is not empty), move the packets
           belonging to a particular (sender->destination) data flow.

   A.10 SENDER_TEMPLATE Class

      SENDER_TEMPLATE class = 11. new SCOPE
                  object into the message.

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

           Definition same as IPv4/UDP    (All PSB's have been processed).  If a shared reservation
             style is being built, move the final merged FLOWSPEC,
             F_POLICY_DATA, and FILTER_SPEC object. (if SE) objects into the
             message.

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

           Definition same as IP6/UDP FILTER_SPEC object.

   A.11 SENDER_TSPEC Class

      SENDER_TSPEC class = 12.    If a RESV_CONFIRM object was saved earlier, copy it into
             the new RESV message and delete it from the RSB in which it
             was found.

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

           The contents of this    Set the RSVP_HOP object in the message to contain the
             IncInterface address through which it will be specified in documents
           prepared by sent and the int-serv working group.

   A.12 ADSPEC Class

      ADSPEC class = 13.
             LIH from (one of) the PSB's.

        o    Send the message to the address PH.

   PATH LOCAL REPAIR

        The contents sequence is entered when RSVP learns from routing that the
        set of this object will be specified outgoing interfaces for some destination (G,DstPort) has
        changed.

        o    Wait for a delay time of W seconds [Section 3.5].

        o    For each session that exists for destination IP address G,
             execute the PATH REFRESH event sequence above for each
             sender (PSB) for that session.

5. Acknowledgments

   The design of RSVP is based upon research performed in documents
      prepared 1992-1993 by a
   collaboration including Lixia Zhang (Xerox PARC), Deborah Estrin
   (USC/ISI), Scott Shenker (Xerox PARC), Sugih Jamin (USC/Xerox PARC),
   and Daniel Zappala (USC).  Sugih Jamin developed the int-serv working group.

   A.13 POLICY_DATA Class

      POLICY_DATA class = 14.

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

           The contents first prototype
   implementation of this object RSVP and successfully demonstrated it in May 1993.
   Shai Herzog, and later Steve Berson, continued development of RSVP
   prototypes.

   Since 1993, many members of the Internet research community have
   contributed to the design and development of RSVP; these include (in
   alphabetical order) Steve Berson, Bob Braden, Lee Breslau, Dave
   Clark, Deborah Estrin, Shai Herzog, Craig Partridge, Scott Shenker,
   John Wroclawski, and Daniel Zappala.  In addition, a number of host
   and router vendors have made valuable contributions, particularly
   Fred Baker (Cisco), Mark Baugher (Intel), Don Hoffman (Sun), Steve
   Jakowski (NetManage), John Krawczyk (Bay Networks), and Bill Nowicki
   (SGI).  Ron Frederick, Bobby Minnear, Eve Schooler, and Garrett
   Wollman did early interfacing of multicast applications to RSVP.
   Steve Deering, Bill Fenner, and Ajit Thyagarajan helped with the
   interface between RSVP and multicast routing.

APPENDIX A. Object Definitions

   C-Types are defined for the two Internet address families IPv4 and
   IP6.  To accommodate other address families, additional C-Types could
   easily be defined.  These definitions are for further study.

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

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

           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 POLICY_DATA object  1              //
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 POLICY_DATA object  2              //
           |                                                       |
           +-------------+-------------+-------------+-------------+
           //                                                     //
           //                                                     //
           +-------------+-------------+-------------+-------------+
           |                                                       |
           //                 POLICY_DATA object  k              //
           |                                                       |
           +-------------+-------------+-------------+-------------+
   A.14 RESV_CONFIRM as an Appendix,
   to ease updating.

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

   A.1 SESSION Class

      SESSION Class

      RESV_CONFIRM class = 15. 1.

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

           +-------------+-------------+-------------+-------------+
           |             IPv4 Receiver Address DestAddress (4 bytes)                |
           +-------------+-------------+-------------+-------------+

      o    IP6 RESV_CONFIRM object: Class = 15, C-Type = 2

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +            IP6 Receiver Address (16 bytes)            +
           | Protocol Id |
           +                                                       +    Flags    |          DstPort          |
           +-------------+-------------+-------------+-------------+

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 rejects the message without updating local state.

        u = 1: RSVP may use message to update local state and 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 specific
             to local organization.  RSVP is not expected to be able to
             interpret this except as a numeric value.

        ss

      o    IP/UDP SESSION object: Class = 11: Low order 12 bits contain a sub-code that is specific
             to the service.  RSVP is not expected to be able to
             interpret this except as a numeric value.  Since the
             traffic control mechanism might substitute a different
             service, this encoding may include some representation 1, C-Type = 2

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +               IP6 DestAddress (16 bytes)              +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           | Protocol Id |     Flags   |          DstPort          |
           +-------------+-------------+-------------+-------------+

      DestAddress

           The IP unicast or multicast destination address of the service in use.

        r: Reserved bit, should
           session.  This field must be zero.

        cccc cccc cccc: 12 bit code. non-zero.

      Protocol Id

           The following globally-defined sub-codes may appear in IP Protocol Identifier for the low-
        order 12 bits when ss = 00:

        -    Sub-code = 1: Delay bound cannot data flow.  This field
           must be met

        -    Sub-code = 2: Requested bandwidth unavailable

        -    Sub-code = 11: Service conflict

        -    Sub-code non-zero.

      Flags

           0x01 = 12: Service unsupported

             Traffic E_Police flag

                The E_Police flag is used in PATH messages to determine
                the effective "edge" of the network, to control can provide neither traffic
                policing.  If the requested service
             nor an acceptable replacement.

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

             Unreasonable request.  High order bit u = 0, i.e., RSVP sender host is not itself capable of
                traffic policing, it will reject the message.

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

             Rmax would result set this bit on in excessive refresh overhead.

   o    Error Code = 02: Administrative rejection

        Reservation has been rejected for administrative reasons. PATH
                messages it sends.  The high order 4 bits first node whose RSVP is capable
                of traffic policing will do so (if appropriate to the Error Value field are assigned as
        for Error Code = 01 (above).  For Error Code = 02,
                service) and turn the following
        global sub-codes are defined:

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

        -    Sub-code = 2: Request too large

             Reservation request exceeds allowed value for this user
             class.

        -    Sub-code flag off.

           0x10 = 3: Insufficient quota Non_RSVP flag

                The Non_RSVP flag is turned on in the SESSION object of
                a PATH message whenever the RSVP daemon detects that the
                previous RSVP hop included one or balance.

        -    Sub-code = 4: Administrative preemption

   o    Error Code more non-RSVP-capable
                routers.  This flag is forwarded hop-by-hop and passed
                to a receiver application.  If it is on, it indicates to
                the application that even a successful reservation
                request may not install the requested QoS at every node
                along the path.

           0x20 = 03: No path information for this Resv Maybe_RSVP flag

                The Maybe_RSVP flag is turned on in the SESSION object
                of a PATH message whenever the RSVP should reject daemon is unable to
                ascertain whether or not the message.

   o    Error Code = 04: No sender information for this Resv

        There previous hop included one
                or more non-RSVP-capable routers.  This flag is path information, but
                forwarded hop-by-hop and passed to a receiver
                application.  If it does is on and the Non_RSVP flag is off,
                the application cannot tell whether or not include a successful
                reservation request may not install the sender
        specified requested QoS at
                every node along the path.

      DstPort

           The UDP/TCP destination port for the session.  Zero may be
           used to indicate `none'.

           Other SESSION C-Types could be defined in one of the Filterspecs listed future to
           support other demultiplexing conventions in the Resv message.
        RSVP should reject the message.

   o    Error Code transport-
           layer or application layer.

   A.2 RSVP_HOP Class

      RSVP_HOP class = 05: Ambiguous path

        Sender port appears both zero and non-zero in same session.
        RSVP should reject the message. 3.

      o    Error Code    IPv4 RSVP_HOP object: Class = 06: Ambiguous filter spec

        Filter spec matches more than one sender, in a style that
        requires a unique match.  RSVP should reject the message. 3, C-Type = 1

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

      o    Error Code    IP6 RSVP_HOP object: Class = 07: Conflicting or unknown style

        Reservation style conflicts with style(s) of existing
        reservation state, or it is unknown.  If 3, C-Type = 2

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

      This object provides the high-order bit IP address of
        Error Value is zero, RSVP should reject the interface through which
      the last RSVP-knowledgeable hop forwarded this message.

   o    Error Code = 08: Conflicting dest port

        Sessions for same destination address and protocol have appeared
        with both  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 and non-zero dest port fields. if there is no logical
      interface handle.

   A.3 INTEGRITY Class

      INTEGRITY class = 4.

      See [Baker96].

   A.4 TIME_VALUES Class

      TIME_VALUES class = 5.

      o    Error Code    TIME_VALUES Object: Class = 09: Conflicting source port 5, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |                   Refresh Period R                    |
           +-------------+-------------+-------------+-------------+

      Refresh Period

           The source port is non-zero refresh timeout period R used to generate this message;
           in a filter spec or sender template
        for a session with destination port zero. milliseconds.

   A.5 ERROR_SPEC Class

      ERROR_SPEC class = 6.

      o    Error Code    IPv4 ERROR_SPEC object: Class = 11: Missing required object

        RSVP was unable to find or construct required object data from
        message. 6, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |            IP4 Error Value will be Class-Num that is missing.  RSVP
        should reject the message.

   o Node Address (4 bytes)           |
           +-------------+-------------+-------------+-------------+
           |    Flags    |  Error Code = 12: Unknown object class |        Error Value will contain 16-bit value composed of (Class-Num,
        C-Type) of unknown object.  This error should be sent only if
        RSVP is going to reject the message.        |
           +-------------+-------------+-------------+-------------+

      o    Error Code    IP6 ERROR_SPEC object: Class = 13: Unknown object 6, C-Type = 2

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

   o Node Address (16 bytes)           +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |    Flags    |  Error Code = 14: Object error

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

      Error Node Address

           The IP address of bad object.  RSVP should reject the
        message.

   o    Error Code = 21: Traffic Control error

        Some system node in which the error was detected detected.

      Flags

           0x01 = InPlace

                This flag is used only for an ERROR_SPEC object in a
                RERR message.  If it on, this flag indicates that there
                was, and reported by the traffic
        control modules.  The Error Value will contain still is, a system-specific
        value giving more information about reservation in place at the error.  RSVP failure
                point.

           0x02 = NotGuilty

                This flag is not
        expected to be able used only for an ERROR_SPEC object in a
                RERR message, and it is only set in the interface to interpret the
                receiver application.  If it on, this value.

   o flag indicates
                that the FLOWSPEC that failed was strictly greater than
                the FLOWSPEC requested by this receiver.

      Error Code = 22: RSVP System

           A one-octet error

        The description.

      Error Value

           A two-octet field will provide implementation-dependent containing additional information on about the
                error.  RSVP is not expected to be able to
        interpret this value.

APPENDIX C. UDP Encapsulation

   An RSVP implementation will generally require the ability to perform
   "raw" network I/O, i.e., to send and receive IP datagrams using
   protocol 46.  However, some important classes of host systems may not
   support raw network I/O.  To use RSVP, such hosts must encapsulate
   RSVP 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  Its contents depend upon the second assumption is given later.

   Let Hu be a "UDP-only" host that requires UDP encapsulation, and Hr a
   host that can do raw network I/O.  The UDP encapsulation scheme must
   allow RSVP interoperation among an arbitrary topology of Hr hosts, Hu
   hosts, and routers.

   RESV, RERR, RTEAR, Error Type.

      The values for Error Code and PERR messages Error Value are sent to unicast defined in Appendix
      B.

   A.6 SCOPE Class

      SCOPE class = 7.

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

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

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

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

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

      STYLE class = 8.

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

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

      Flags: 8 bits

           (None assigned yet)

      Option Vector: 24 bits

           A set of bit fields giving values for the path or reservation state
           options.  If new options are added in the node.  If future,
           corresponding fields in the option vector will be assigned
           from the least-significant end.  If a node
   keeps track does not recognize
           a style ID, it may interpret as much of which previous hops and which interfaces need UDP
   encapsulation, these messages message can be sent using UDP
   encapsulation when necessary.

   On the other hand, PATH and PTEAR messages option vector as
           it can, ignoring new fields that may have been defined.

           The option vector bits are send to the unicast or
   multicast destination address for assigned (from the session. left) as
           follows:

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

      The table in Figure
   12 shows the basic rules for UDP encapsulation low order bits of such messages.
   Under the `Send' column, the notation is `mode(destaddr, destport,
   TTL)', where TTL is option vector are determined by the IP-layer hop count.
      style, as follows:

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

      FLOWSPEC class = 9.

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

           The `Receive' column
   shows the group that is joined and, where relevant, contents of this object will be specified in documents
           prepared by the UDP Listen
   port.  The following symbols are also used: int-serv working group.

   A.9 FILTER_SPEC Class

      FILTER_SPEC class = 10.

      o    D is the DestAddress for the particular session.    IPv4 FILTER_SPEC object: Class = 10, C-Type = 1

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

      o    G* is a well-known group    IP6 FILTER_SPEC object: Class = 10, C-Type = 2

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

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

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

      SrcAddress

           The IP source address of the form 224.0.0.x, i.e., for a
        group that is limited to the local connected network.  [TO BE
        DEFINED]

   o    Pu is the well-known UDP sender host.  Must be non-zero.

      SrcPort

           The UDP/TCP source port for UDP encapsulation of RSVP:
        3455.

   o    Ra is the IP address of the router interface `a'.

   o    Tr is the TTL a sender, or zero to indicate
           `none'.

      Flow Label

           A 24-bit Flow Label, defined in IP6.  This value of the specific PATH message.

   o    Router interface `a' is on may be used
           by the local network connected packet classifier to Hu and
        Hr, while interface `b' is connected only efficiently identify the packets
           belonging 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 destination
   address D is unicast.

   [Note 2] R ignores PATH messages addressed to G* if D is unicast.
   (This is necessary to prevent routing and reservation anomalies).

   [Note 3] The DestAddress D is particular (sender->destination) data flow.

   A.10 SENDER_TEMPLATE Class

      SENDER_TEMPLATE class = 11.

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

           Definition same as IPv4/UDP FILTER_SPEC object.

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

           Definition same as IP6/UDP FILTER_SPEC object.

   A.11 SENDER_TSPEC Class

      SENDER_TSPEC class = 12.

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

           The contents of this object are specified in service
           specification documents prepared by the IP address int-serv working
           group.

   A.12 ADSPEC Class

      ADSPEC class = 13.

      o    Intserv ADSPEC object: Class = 13, C-Type = 2

           The contents of Hu this object are specified in service
           specification documents prepared by the int-serv working
           group.

   A.13 POLICY_DATA Class

      POLICY_DATA class = 14.

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

           The contents of this case.

   R and Hr send their PATH messages twice, once with UDP encapsulation object are for further study.

   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 Codes and once Values

   The following Error Codes may appear in raw mode.  In two cases (Hr -> R ERROR_SPEC objects and Hr -> Hr), each PATH
   message will be delivered twice.  The destination may take steps
   passed to
   ignore the duplicates, although this redundancy has no ill effect
   other than overhead for processing the extra messages.

   A router end systems.  Except where noted, these Error Codes 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 address of interface X (unicast D).  There
   is one failure mode for this scheme:  if no host on
   appear only in RERR messages.

   o    Error Code = 00: Confirmation

        This code is reserved for use in the connected
   network acts as an RSVP sender, there ERROR_SPEC object of a RACK
        message.  The Error Value will also be no PATH messages zero.

   o    Error Code = 01: Admission Control failure

        Reservation request was rejected by Admission Control due to
   trigger UDP encapsulation.  In
        unavailable resources.

        For this (unlikely) case, it will be
   necessary to explicitly configure UDP encapsulation on Error Code, the local
   network interface 16 bits of the router.

   A UDP-only host Hu supporting unicast RSVP sessions must somehow know Error Value field are:

           ssur cccc cccc cccc

        where the address Ra, presumably by configuration.

   When bits are:

        ss = 00: Low order 12 bits contain a UDP-encapsulated packet is received, the IP TTL globally-defined sub-code
             (values listed below).

        ss = 10: Low order 12 bits contain a organization-specific sub-
             code.  RSVP is not
   available expected to the application on most systems.  The RSVP daemon that
   receives be able to interpret this
             except as a UDP-encapsulated PATH or PTEAR message should therefore
   use the Send_TTL field of the numeric value.

        ss = 11: Low order 12 bits contain a service-specific sub-code.
             RSVP common header as the effective
   receive TTL.

   We have assumed that the first-hop RSVP-capable router R is on the
   directly-connected network.  There are several possible approaches if
   this is not the case.

   1.   Hu can send both unicast and multicast sessions expected to
        UDP(Ra,Pu,Ta).

        Here Ta must be able to interpret this except as
             a numeric value.

             Since the TTL traffic control mechanism might substitute a
             different service, this encoding may include some
             representation of the service in use.

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

        u = 1: RSVP may use message to exactly reach R.  If Ta is too small, update local state and forward
             the message.  This means that the PATH message will not reach R.  If Ta is too large,
        multicast routing informational.

        r: Reserved bit, should be zero.

        cccc cccc cccc: 12 bit code.

        The following globally-defined sub-codes may appear in R will forward the UDP packet into the
        Internet until its hop count expires. low-
        order 12 bits when ssur = 0000:

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

        -    Sub-code = 2: Requested bandwidth unavailable

   o    Error Code = 02: Policy Control failure

        Reservation has been rejected for administrative reasons, for
        example, required credentials not submitted, insufficient quota
        or balance, or administrative preemption.  This will turn on UDP
        encapsulation between routers within Error Code may
        appear in a PERR or RERR message.

        Contents of the Internet, causing bogus
        UDP traffic.  The host Hu must Error Value field are to be explicitly configured with Ra
        and Ta.

   2.   A particular host on determined in the LAN connected to Hu could
        future.

   o    Error Code = 03: No path information for this Resv message.

        No path state for this session.  RESV message cannot be designated
        as an "RSVP relay host".  A relay host would listen on (G*,Pu)
        and forward any PATH messages directly to R, although
        forwarded.

   o    Error Code = 04: No sender information for this Resv message.

        There is path state for this session, but it would does not be include
        the sender matching some flow descriptor contained in the data path. RESV
        message.  RESV message cannot be forwarded.

   o    Error Code = 05: Conflicting reservation style

        Reservation style conflicts with style(s) of existing
        reservation state.  The relay host would have to be
        configured Error Value field contains the low-order
        16 bits of the Option Vector of the existing style with Ra and Ta.

APPENDIX D. Experimental and Open Issues

   D.1 which
        the conflict occurred.  This RESV message cannot be forwarded.

   o    Error Code = 06: Unknown reservation style

        Reservation Compatibility

      How strong style is the requirement for compatibility of reservations in
      different directions?  For example, see Figure 10; should it unknown.  This RESV message cannot be
      possible to
        forwarded.

   o    Error Code = 07: Conflicting dest port

        Sessions for same destination address and protocol have incompatible reservation styles on the two
      interfaces?  If R1 requests a WF reservation appeared
        with both zero and R2 requests non-zero dest port fields.  This Error Code
        may appear in a FF
      reservation, it is logically possible to make the corresponding
      reservations on the two different interfaces.  The current
      implementation does NOT allow this; instead, it prevents mixing of
      incompatible styles PERR or RERR message.

   o    Error Code = 08: Ambiguous path

        Sender port appears both zero and non-zero in the same session on in a node, even if they
      are on different interfaces.

   D.2 Session Groups (Experimental)

      Section 1.2 explained that
        PATH message.  This Error Code may appear only in a distinct destination address, PERR
        message.

   o    Error Code = 09, 10, 11: (reserved)

   o    Error Code = 12: Service preempted

        The service request defined by the STYLE object and
      therefore a distinct session, will be used for each the flow
        descriptor has been administratively preempted.

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

           ssur cccc cccc cccc

        Here the high-order bits ssur are as defined under Error Code
        01.  The following globally-defined sub-codes may appear in a hierarchically encoded flow.  However, these
      separate sessions the
        low-order 12 bits when ssur = 0000 are logically related.  For example it may be
      necessary to pass reservations for all subflows to Admission
      Control at be defined in the same time (since it would
        future.

   o    Error Code = 13: Unknown object class

        Error Value contains 16-bit value composed of (Class-Num, C-
        Type) of unknown object.  This error should be nonsense sent only if RSVP
        is going to admit high
      frequency components but reject the baseband component message, as determined by the high-order
        bits of the
      session data).  Such a logical grouping is indicated Class-Num.  This Error Code may appear in RSVP by
      defining a "session group", an ordered set PERR or
        RERR message.

   o    Error Code = 14: Unknown object C-Type

        Error Value contains 16-bit value composed of sessions.

      To declare that a set (Class-Num, C-
        Type) of sessions form a session group, a receiver
      includes a data structure we call a SESSION_GROUP object in the
      RESV message object.

   o    Error Code = 15-19: (reserved)

   o    Error Code = 20: Reserved for each of the sessions.  A SESSION_GROUP object API

        Error Value field contains four fields: a reference address, a session group ID, a
      count, an API error code, for an API error
        that was detected asynchronously and a rank.

      o    The reference address is must be reported via an agreed-upon choice from among
        upcall.

   o    Error Code = 21: Traffic Control Error
        Reservation request was rejected by Traffic Control due to the
           DestAddress values
        format or contents of the sessions in request.  This RESV message cannot be
        forwarded, and continued attempts would be futile.

        For this Error Code, the group, for example 16 bits of the smallest numerically.

      o    The session group ID is used to distinguish different groups
           with Error Value field are:

           ss00 cccc cccc cccc

        Here the same reference address.

      o high-order bits ss are as defined under Error Code 01.

        The count is the number of members following globally-defined sub-codes may appear in the group.

      o    The rank, low
        order 12 bits (cccc cccc cccc) when ssr = 000:

        -    Sub-code = 01: Service conflict

             Trying to merge two incompatible service requests.

        -    Sub-code = 02: Service unsupported

             Traffic control can provide neither the requested service
             nor an integer between 1 acceptable replacement.

        -    Sub-code = 03: Bad Flowspec value

             Mal-formed or unreasonable request.

        -    Sub-code = 04: Bad Tspec value

             Mal-formed or unreasonable request.

   o    Error Code = 22: Traffic Control System error

        A system error was detected and count, is different in
           each session of reported by the session group. traffic control
        modules.  The SESSION_GROUP objects for all sessions in the group Error Value will contain a system-specific value
        giving more information about the same values of the reference address, the session
      group ID, and the count error.  RSVP is not expected
        to be able to interpret this value.

   o    Error Code = 23: RSVP System error

        The rank values establishes Error Value field will provide implementation-dependent
        information on the
      desired order among them.

      If error.  RSVP is not expected to be able to
        interpret this value.

   In general, every RSVP message is rebuilt at a given each hop, and the node receives a RESV
   that creates an RSVP message containing a
      SESSION_GROUP object, it should wait until RESV messages is responsible for all
      `count' sessions have appeared (or until its correct
   construction.  Similarly, each node is required to verify the correct
   construction of each RSVP message it receives.  Should a programming
   error allow an RSVP to create a malformed message, the error is not
   generally reported to end systems in an ERROR_SPEC object; instead,
   the error is simply logged locally, and perhaps reported through
   network management mechanisms.

   The only message formatting errors that are reported to end of the refresh
      cycle) systems
   are those that may reflect version mismatches, and then pass which the RESV requests end
   system might be able to circumvent, e.g., by falling back to Admission Control as a
      group.  It is normally expected
   previous CType for an object; see code 12 and 13 above.

   The choice of message formatting errors that all sessions in the group an RSVP may detect and
   log locally is implementation-specific, but it will be routed through typically include
   the same nodes.  However, if not, only following:

   o    Wrong-length message: RSVP Length field does not match message
        length.

   o    Unknown or unsupported RSVP version.

   o    Bad RSVP checksum

   o    Illegal RSVP message Type

   o    Illegal object length: not a
      subset multiple of the session group reservations may appear at 4, or less than 4.

   o    Next hop/Previous hop address in HOP object is illegal.

   o    Conflicting source port: Source port is non-zero in a given
      node; filter
        spec or sender template for a session with destination port
        zero.

   o    Required object class (specify) missing

   o    Illegal object class (specify) in this case, the RSVP should wait until the end message type.

   o    Violation of required object order

   o    Flow descriptor count wrong for style

   o    Logical Interface Handle invalid

   o    Unknown object Class-Num.

APPENDIX C. UDP Encapsulation

   An RSVP implementation will generally require the
      refresh cycle and then ability to perform Admission Control on the subset
   "raw" network I/O, i.e., to send and receive IP datagrams using
   protocol 46.  However, some important classes of
      the session group that it has received. host systems may not
   support raw network I/O.  To use RSVP, such hosts must encapsulate
   RSVP messages in UDP.

   The rank values will
      identify which basic UDP encapsulation scheme makes two assumptions:

   1.   All hosts are missing.

      Note that routing different sessions capable of the session group
      differently will generally result in delays in establishing or
      rejecting the desired QoS.  A "bundling" facility could be added
      to sending and receiving multicast routing, to force all sessions in a session group packets
        if multicast destinations are 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 = supported.

   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 first/last-hop routers are defined in above.

   D.3 DF Style (Experimental)

      In addition to RSVP-capable.

   A method of relaxing the WF second assumption is given later.

   Let Hu be a "UDP-only" host that requires UDP encapsulation, and FF styles defined in this specification, Hr a Dynamic Filter (DF) style has also been proposed.
   host that can do raw network I/O.  The following
      describes this style and gives examples UDP encapsulation scheme must
   allow RSVP interoperation among an arbitrary topology of its usage.  At this
      time, DF style is experimental.

      D.3.1 Reservation Styles

         A Dynamic-Filter (DF) style reservation makes "distinct"
         reservations with "wildcard" scope, but it decouples
         reservations Hr hosts, Hu
   hosts, and routers.

   RESV, RERR, RTEAR, and PERR messages are sent to unicast addresses
   learned from filters.

         o    Each DF the path or reservation request specifies a number D state in the node.  If the node
   keeps track of
              distinct reservations which previous hops and which interfaces need UDP
   encapsulation, these messages can be sent using UDP encapsulation
   when necessary.  On the same specified flowspec.
              These reservations other hand, PATH and PTEAR messages are distributed with wildcard  scope,
              i.e., send
   to all senders. thedestination address for the session, which may be unicast or
   multicast.

   The number of reservations that are actually made tables in a
              particular node is D' = min(D,Ns), where Ns is the total
              number of senders upstream of the node.

         o    In addition to D Figures 13 and 14 show the flowspec, a DF style reservation
              may also specify a list basic rules for UDP
   encapsulation of K filterspecs, PATH and PTEAR messages, for some K in
              the range: 0 <= K <= D'.  These filterspecs define
              particular senders to use the D' reservations, unicast DestAddress and this
              list establishes
   multicast DestAddress, respectively.  Under the scope for `Send' column, the filter specs.

              Once a DF reservation has been established,
   notation is `mode(destaddr, destport)'; destport is omitted for raw
   packets.  The `Receive' column shows the receiver
              may change group that is joined and,
   where relevant, the set of filterspecs UDP Listen port.

   It is useful to specify a different
              selection define two flavors of senders, without a new admission control
              check (assuming D' UDP encapsulation, one to be
   sent by Hu and the common flowspec remain
              unchanged).  This is known as "channel switching", in
              analogy with a television set.

         In order other to provide assured channel switching, each node along
         the path must reserve enough bandwidth for all D' channels,
         even though some of this bandwidth may be unused at any one
         time.  If D' changes (because sent by Hr and R, to avoid double
   processing by the receiver changed D or because recipient.  In practice, these two flavors are
   distinguished by differing UDP port numbers Pu and Pu'.

   The following symbols are used in the number Ns of upstream sources changed), or if tables.

   o    D is the common
         flowspec changes, DestAddress for the refresh message particular session.

   o    G* is treated as a new
         reservation well-known group address of the form 224.0.0.x, i.e., a
        group that is subject limited to admission control the local connected network.  [TO BE
        DEFINED]

   o    Pu and may fail.

         The DF style allows a receiver to switch channels without
         danger Pu' are two well-known UDP ports for UDP encapsulation of an admission denial due to limited resources (unless
         a topology change reroutes traffic along a lower-capacity path
         or new senders appear), once the initial reservations have been
         made.  This in turn implies that the DF style creates
         reservations that may not be in use at any given time.

         The DF style
        RSVP.  [TO BE DEFINED]

   o    Ra is compatible with the FF style but not the WF or
         SE style.

      D.3.2 Examples

         To give an example IP address of the DF style, we use the following
         notation: router interface `a'.

   o    DF Style

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

         This message carries    Tr is 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 13 shows an example TTL value of Dynamic-Filter reservations.  The
         receivers downstream from the specific PATH message.

   o    Router interface (d) have requested two
         reserved channels, but selected only one sender, S1.  The node
         reserves min(2,3) = 2 channels of size B `a' is on interface (d), and
         it then applies any specified filters the local network connected to these channels.  Since
         only one sender was specified, one channel has no corresponding
         filter, as shown by `?'.

         Similarly, Hu and
        Hr.

   o    [RA] indicates that the receivers downstream of interface (c) have
         requested two channels Router Alert option is sent.

   UNICAST DESTINATION D:

                   RSVP               RSVP
   Node            Send               Receive
   ___       _____________          _______________
   Hu         UDP(D/Ra,Pu)          UDP(D,Pu)
                 [Note 1]       and selected senders S1 UDP(D,Pu')
                                       [Note 2]

   Hr         Raw(D,Tr)[RA]         Raw()
               and S2.  The two
         channels might have been one channel each from R1 if (UDP)     and R2, or
         two channels requested by one of them, UDP(D, Pu)
               then UDP(D,Pu')         [Note 2]
                                    (Ignore Pu')

   R (Interface a):
              Raw(D,Tr)[RA]         Raw()
               and if (UDP)     and UDP(Ra, Pu)
               then UDP(D,Pu')      (Ignore Pu')

       Figure 13: UDP Unicast Encapsulation Rules for example.

                           | Path Messages
   MULTICAST DESTINATION D:

                  RSVP                    RSVP
   Node           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} |
                           |      |________|
   ___           _____________        _________________
   Hu             UDP(G*,Pu)              UDP(D,Pu')
                                              [Note 3]
                                      and UDP(G*,Pu)

   Hr             Raw(D,Tr)[RA]           Raw()
                   and if (UDP)       and UDP(G*,Pu)
                     then UDP(D,Pu')     (Ignore Pu')

   R (Interface a):
                  Raw(D,Tr)[RA]           Raw()
                   and if (UDP)       and UDP(G*,Pu)
                     then UDP(D,Pu')     (Ignore Pu')

      Figure 13: Dynamic-Filter Reservation Example

         A router should not reserve more Dynamic-Filter channels than 14: UDP Multicast Encapsulation Rules for Path Messages

   [Note 1] Hu sends a unicast PATH message either to the number of upstream sources (three, in destination
   address D, if D is local, or to the router address Ra of Figure
         13).
          Since there the first-hop
   router.  Ra is only one source upstream from previous hop (a), presumably known to the first parameter host.

   [Note 2] Here D is the address of the DF local interface through which
   the message (the count arrived.

   [Note 3] This assumes that the application has joined the group D.

   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 address of channels interface X (unicast D).  There
   is one failure mode for this scheme:  if no host on the connected
   network acts as an RSVP sender, there will be no PATH messages to
   trigger UDP encapsulation.  In this (unlikely) case, it will be reserved) was decreased
   necessary to 1 in explicitly configure UDP encapsulation on the forwarded reservations.
         However, this is unnecessary, because local
   network interface of the routers upstream will
         reserve only one channel, regardless. router.

   When a DF reservation UDP-encapsulated packet is received, it is labeled with the IP
         address of the next hop (RSVP-capable) router, downstream from
         the current node.  Since the outgoing interface may be directly
         connected TTL is not
   available to the application on most systems.  The RSVP daemon that
   receives a shared medium network UDP-encapsulated PATH or to a non-RSVP-capable
         router, there PTEAR message should therefore
   use the Send_TTL field of the RSVP common header as the effective
   receive TTL.  This may be more than one next-hop node downstream; if
         so, each sends independent DF RESV messages for a given
         session.  The number N' of DF channels reserved on an outgoing
         interface is given overridden by manual configuration.

   We have assumed that the formula:

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

         where Di first-hop RSVP-capable router R is on the D value (channel reservation count) in a RESV
         from the ith next-hop node.

         For a DF reservation request with a Dynamic Reservation Count =
         C, RSVP should call TC_AddFlowspec C times.

      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
   directly-connected network.  There are several possible approaches if
   this is not the case.

   1.

                   2 bits: Sharing control (as before)

                   3 bits: Scope control (as before)

              Dynamic Resv Count

                   The number of channels   Hu can send both unicast and multicast sessions to UDP(Ra,Pu)
        with TTL=Ta

        Here Ta must be reserved for a Dynamic
                   Filter style reservation. the TTL to exactly reach R.  If Ta is too small,
        the PATH message will not reach R.  If Ta is too large,
        multicast routing in R will forward the UDP packet into the
        Internet until its hop count expires.  This integer value will turn on UDP
        encapsulation between routers within the Internet, perhaps
        causing bogus UDP traffic.  The host Hu must
                   not less than be explicitly
        configured with Ra and Ta.

   2.   A particular host on the number of FILTER_SPEC objects 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
                   filter spec list. the data path.  The relay host would have to be
        configured with Ra and Ta.

References

[Baker96]  Baker, Fred, "RSVP Cryptographic Authentication", Internet
    Draft draft-ietf-rsvp-md5-01.txt, February 1996.

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

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

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

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

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,

   Steve Berson
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90089-0871 90292

   Phone: (213) 740-4524 (310) 822-1511
   EMail: estrin@USC.EDU Berson@ISI.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