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

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

                               **DRAFT**
                            November 3, 1994

                           March 24, 1995

Status of Memo

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

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

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

Abstract

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

What's Changed Since Seattle Toronto IETF

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

   o    Redesign generic    The RSVP API (section 3.6.2) packet format has been reorganized to carry most data
        as typed variable-length objects.

   o    Change encoding of style in RESV messages (section 3.1.2)    This generality includes provision for 16-byte IP6 addresses.

   o    Clarify filterspec functions (section 2.1)    Filter specs have been simplified.

   o    Simplify definition of    DF style (sections 2.2, 2.4). has been moved to an Appendix, as experimental.

   o    Revise discussion of flowspec merging (section 2.3.3).    UDP encapsulation has been included.

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

   o    Add a user authentication field in all RSVP messages (Section
        3).    The Drop flag has been eliminated.

   o    Add short discussion of local repair (Section 3.3.3).    Session groups have been added.

   o    Editorial nits.    The routing of RERR messages has been changed.

1. Introduction

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

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

   At each "node" (i.e., router or host) along the path, data path.

   RSVP passes a
   new resource reservation request to an admission control routine, to
   determine whether there are sufficient reserves resources available.  If there
   are, the node for simplex data streams, i.e., it reserves the
   resources and updates its packet scheduler
   and classifier control parameters to provide the requested QoS
   [ISInt93].  It is expected that RSVP implementations will execute in
   user space in only one direction on a host, and in background in link, so that a router.  On the other
   hand, sender is
   logically distinct from a receiver.  However, the packet scheduler same application
   may act as both sender and classifier are expected to execute in
   the kernel receiver.  RSVP operates on top of a host operating system, and in the high-speed packet
   forwarding path of a router.

   RSVP messages are sent as IP datagrams; thus, RSVP occupies IP,
   occupying the place of a transport protocol in the protocol stack.
   However, like ICMP, IGMP, and routing protocols, RSVP does not
   transport application data but is really rather an Internet control
   protocol; it does not carry any application data,
   protocol.  As shown in Figure 1, an implementation of RSVP, like the
   implementations of routing and its messages
   are processed by management protocols, will typically
   execute in the routers background, not in the data forwarding path.

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

   The objectives operate with existing and general justification for future unicast and multicast
   routing protocols.

               HOST                             ROUTER

    _________________________    RSVP design are
   presented in [RSVP93,ISInt93].  In summary,   ______________________
   |                         |    .---------------.           |
   |  _______       ______   |   .     | ________  .   ______ |
   | |       |     |      |  |  .      ||        |  . |      ||  RSVP has the following
   attributes:

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

   o <-----       ||Routing |   -> RSVP reserves resources for simplex <------>
   | |  App  <----->daemon|  |         ||Protocol|    |daemon||
   | |       |     |      |  |         || daemon <---->      ||
   | |_______|     |___.__|  |         ||_ ._____|    |__.___||
   |===|===============v=====|         |===v=============v====|
   | data streams.

   o     ..........     |         |   .  ............    |
   |   |  ____v_   ____v____ |         |  _v__v_    _____v___ |
   |   | |Class-| |         ||   data  | |Class-|  |         ||  data
   |   |=> ifier|=> Packet  =============> ifier|==> Packet  |======>
   |     |______| |Scheduler||         | |______|  |Scheduler||
   |              |_________||         |           |_________||
   |_________________________|         |______________________|

                   Figure 1: RSVP in Hosts and Routers

   Each router that is receiver-oriented, i.e., the receiver capable of a resource reservation passes incoming
   data flow is
        responsible for packets to a packet classifier and then queues them as necessary
   in a packet scheduler.  The packet classifier determines the initiation route
   and maintenance of the resource
        reservation used QoS class for that flow.

   o    RSVP maintains "soft state" in the routers, enabling each packet.  The scheduler allocates a
   particular outgoing link for packet transmission, and it may also
   allocate other system resources such as CPU time or buffers.

   In order to
        gracefully support efficiently accommodate heterogeneous receivers and
   dynamic group membership changes and automatically
        adapt to routing changes.

   o be consistent with IP multicast, RSVP provides several reservation models or "styles" (defined
        below)
   makes receivers responsible for requesting resource reservations
   [RSVP93].  A QoS request, typically originating in a receiver host
   application, will be passed to fit the local RSVP implementation, shown
   as a variety user daemon in Figure 1.  The RSVP protocol is then used to pass
   the request to all the nodes (routers and hosts) along the reverse
   data path(s) to the data source(s).

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

   RSVP is designed to scale well for very large multicast groups.
   Since the membership of applications.

   o a large group will be constantly changing,
   the RSVP provides transparent operation through routers design assumes that do not
        support it.

   The router state for traffic control will be
   built and destroyed incrementally.  For this purpose, RSVP uses "soft
   state" in the routers, in addition to receiver-initiation.

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

   In order to efficiently accommodate heterogeneous receivers summary, RSVP has the following attributes:

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

   o    RSVP makes is simplex.

   o    RSVP is receiver-oriented, i.e., the receivers receiver of a data flow is
        responsible for
   requesting the initiation and maintenance of the resource reservations [RSVP93].  Each receiver can request
   a
        reservation used for that is tailored flow.

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

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

   o    RSVP provides transparent operation through routers along the reverse
   path(s) to that do not
        support it.

   Further discussion on the sender(s).

   There are two aspects to RSVP, its reservation model and its protocol
   mechanisms.  Sections 2.1 objectives and 2.2 general justification for
   RSVP design are presented in [RSVP93,ISInt93].

   The remainder of this memo summarize section describes the RSVP reservation model, while Sections 2.3 describes
   services.  Section 2 presents an overview of the RSVP protocol
   mechanisms.  Sections 2.4
   mechanisms, while Section 3 gives examples of both model and mechanism,
   and Section 2.5 summarizes the model of RSVP seen by a host. services and
   mechanism.  Section
   3 presents 4 contains the functional specification for of RSVP.

2. RSVP Overview

   2.1 RSVP Reservation Model

      Figure 1 illustrates a single multicast distribution session.
   Section 5 presents explicit message processing rules.

   1.1 Data Flows

      The
      arrows indicate set of data flowing from senders S1 and S2 to receivers
      R1, R2, and R3, and the cloud represents the distribution mesh
      created by flows with the same unicast or multicast routing protocol.  Multicast distribution
      forwards
      destination constitute a copy of session. RSVP treats each session
      independently.  All data packet from packets in a sender Si particular session are
      directed to every the same IP destination address DestAddress, and
      perhaps to some further demultiplexing point defined in a higher
      layer (transport or application).  We refer to the latter as a
      "generalized destination port".

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

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

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

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

                 Figure 1: 2: Multicast Distribution Session

      All data packets in

   1.2 Reservation Model

      An elementary RSVP reservation request consists of a given session are addressed to the same IP
      destination address DestAddress.  For multicast delivery,
      DestAddress "flowspec"
      together with a "filter spec"; this pair is called a "flow
      descriptor".  The flowspec specifies a desired QoS.  The filter
      spec (together with the multicast group address to which DestAddress and the data is
      addressed.  For unicast delivery, DestAddress is simply the
      unicast address of the single receiver.  RSVP identifies a session
      by DestAddress plus a 32-bit stream identifier called the
      "reservation id" (ResvID).  We use the term "session socket" for generalized
      destination port defining the (DestAddress, ResvID) pair that session) defines a session.  RSVP
      treats each session independently.  In the rest set of this document,
      a particular session (hence, session socket) is always implied
      even if not stated.

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

      A single RSVP resource reservation request is QoS defined by a "
      flowspec" together with a "filterspec"; this pair is called a "
      Flow Descriptor". the
      flowspec.  The flowspec specifies the desired QoS in a
      quantitative manner, e.g., the tolerable delay, the average
      throughput, the maximum burstiness, etc [Partridge92, ISInt93,
      IServ93]; it is used to set parameters to the packet scheduling
      mechanism
      scheduler in the node (router or host).  The filterspec (plus the
      DestAddress) defines (assuming that admission control succeeds),
      while the set of data packets to receive this
      service; it filter spec is used to set parameters in the packet classifier
      component
      classifier.

      The flowspec in a reservation request will generally include a
      service type and two sets of numeric parameters: (1) an " Rspec"
      (R for `reserve'), which defines the node.  For all packets that are addressed to desired per-hop reservation,
      and (2) a
      particular session, only those that can match "Tspec" (T for `traffic'), which defines the filter spec(s)
      of parameters
      that session will may be forwarded according used to police the flowspec; data flow, i.e., to ensure it does
      not exceed its promised traffic level.

      The general RSVP reservation model allows filter specs to select
      arbitrary subsets of the
      rest will be either dropped or sent as best-effort traffic.

      More specifically, a filterspec may have two distinct functions.

      o    Sender Selection

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

      o    Receiver Sub-selection

           A filterspec may distinguish different sessions with higher-level protocol, or
      generally in terms of any fields in any protocol headers in the same
           DestAddress
      packet.  For example, filter specs might be used to select
      different subflows in a hierarchically-encoded signal, by
      selecting a subset on fields in an application-layer header.  However,
      considerations of the packets destined both architectural purity and practical
      requirements have led to the decision that address.  This subset is defined RSVP should use
      separate sessions for distinct subflows of hierarchically-encoded
      signals.  For multicast sessions, subflows can be distinguished by a "generalized
           destination port", which again may include transport-layer
           (e.g., UDP
      multicast destination port) and/or application-layer
           demultiplexing information.  An RSVP receiver Rj is defined address; for unicast sessions, they must be
      distinguished by destination port.  As a result of these
      considerations, the pair (Hj, Pj), where Hj is the present RSVP version includes a quite
      restricted definition of filter specs, selecting only on sender IP host
      address and Pj
           is the generalized destination port.

      RSVP needs to distinguish different sessions.  It is difficult to
      do this by matching generalized destination ports buried within
      the filterspecs, since UDP/TCP port number, and on protocol id.  However, the part
      design of the filterspec protocol would easily handle a more general
      definition in future versions.

      Any packets that defines the
      generalized destination port should be opaque are addressed to an RSVP module in a router, which does not particular session but do not know the structure
      match any of transport or
      application layer protocol headers.  Therefore, RSVP identifies a the filter specs for that session will be sent as
      best-effort traffic.  Under congested conditions, such packets are
      likely to experience long delays and may be dropped.  A receiver
      may wish to conserve network resources by explicitly asking the pair (DestAddress, ResvID),
      network to drop those data packets for which there is no
      reservation; however, such dropping should be performed by
      routing, not by RSVP.  Determining where the ResvID's form packets get delivered
      should be a simple space of identifiers that routing function; RSVP can use to distinguish
      different sessions is concerned only with the same DestAddress.  The ResvID's need
      not themselves be (generalized) ports, but the the ResvID values QoS
      of those packets that are used must have a one-to-one correspondence with the
      generalized ports in use for the given DestAddress.

      All delivered by routing.

      RSVP reservation requests for a given session must use filterspecs
      that specify the same DestAddress and the same generalized
      destination port (since request messages originate at receivers of and are
      passed upstream towards the same substream,
      downstream of a given node, must share a common resource
      reservation in sender(s).  (Note that node).

   2.2 Reservation Styles

      In addition this document
      always uses the directional terms "upstream" vs. "downstream",
      "previous hop" vs.  "next hop", and "incoming interface" vs
      "outgoing interface" with respect to the Flow Descriptors, each RSVP data flow direction).
      When an elementary reservation request
      specifies is received at a "reservation style".  The following reservation styles
      have been defined so far. node, the
      RSVP daemon takes two primary actions.

      1.   Wildcard-Filter (WF) Style

           A Wildcard-Filter (WF) style reservation creates   Make a single
           resource "pipe" along each link, shared by data packets from
           all senders for the given session. reservation

           The "size" flowspec and the filter spec are passed to traffic
           control.  Admission Control determines the admissibility of
           the request (if it's new); if it fails this pipe test, the
           reservation is rejected and RSVP sends back an error message
           towards the largest of responsible receiver(s).  If it passes, the resource requests for that link from
           all receivers, independent of the number of senders using it.
           (The concept of a "largest"
           flowspec is discussed later).

           The term "wildcard" implies a filterspec that selects all
           senders.  A WF reservation automatically extends used to new
           senders set up the packet scheduler for the
           desired QoS and the filter spec is used to set the packet
           classifier to select the session, as they appear. appropriate data packets.

      2.   Fixed-Filter (FF) Style

           A Fixed-Filter (FF) style   Forward reservation request creates
           reservation(s) for data packets from particular sender(s).  A
           FF upstream.

           The reservation request from a particular receiver Rj contains
           a list of one or more Flow Descriptors, each consisting is propagated upstream towards the
           appropriate senders.  The set of a
           filterspec, senders to which specifies some sender Si, and a
           corresponding flowspec.

           FF reservations requested by different receivers Rj but
           selecting given
           reservation request is propagated is called the same sender Si must necessarily share a single "scope" of
           that request.

      The reservation in request that a given node.  This node forwards upstream may differ
      from the request that it received, for two reasons.  First, it is simply
      possible (at least in theory) for the result kernel to modify the
      flowspec hop-by-hop (although currently no realtime services do
      this).  Second, reservations from different downstream branches of
      the multicast distribution tree(s) must be "merged" as
      reservations travel upstream.  Merging reservations is a necessary
      consequence of multicast distribution, which creates a single
      stream of data packets in a particular router from any Si,
      regardless of the
           number set of receivers downstream.  The reservation
      for Si will on a particular outgoing link L should be the maximum "maximum" of
      the individual flowspecs from different
           downstream the receivers Rj (see Section 2.3.3).

           FF reservations for different senders that are distinct; they do
           NOT share a common pipe.  The total reservation on a downstream
      via link for
           a given session L.  Merging is therefore the cumulative total discussed further in Section 2.3.

      For both of these primary actions, there are options controlled by
      the
           reservations for each requested sender.  A receiver that has
           established a FF style reservation may modify, add, or delete
           a flow descriptor at any time.  However, any additional or
           modified reservations making the reservation. These options are subject to admission combined
      into a control and
           may fail.

      3.   Dynamic-Filter (DF) Style

           A Dynamic-Filter (DF) style reservation decouples
           reservations from filters.  Each DF variable called the reservation request
           specifies a number D "style", which is
      discussed in section 1.3.  One option concerns the treatment of distinct
      reservations to be made
           using for different senders within the same specified flowspec.  The number of
           reservations that are actually made in session:
      establish a particular node is
           D' = min(D,Ns), where Ns is "distinct" reservation for each upstream sender, or
      else "mix" all senders' packets into a single reservation.
      Another option controls the total number scope of the request: "unitary" (i.e.,
      a single specified sender), an explicit sender list, or a
      "wildcard" that implicitly selects all senders upstream of the
      given node.

           In addition to D and the flowspec, a DF style

      The basic RSVP reservation may
           also specify model is "one pass": a list of K filterspecs, for some K in the
           range: 0 <= K <= D'.  These filterspecs define particular
           senders to use the D' reservations.  Once receiver sends a DF
      reservation
           has been established, request upstream, and each node in the receiver may change path can only
      accept or reject the set of
           filterspecs request.  This scheme provides no way to specify a different selection of senders,
           without a new admission control check (assuming D' and make
      end-to-end service guarantees; the
           common flowspec remain unchanged).  This QoS request is applied
      independently at each hop.  RSVP also supports an optional
      reservation model, known as "channel
           switching", in analogy with a television set. " One Pass With Advertising" (OPWA)
      [Shenker94].  In order to provide assured channel switching, each node
           along OPWA, RSVP control packets sent downstream,
      following the path must reserve enough bandwidth for all D'
           channels, even though some data paths, are used to gather information on the
      end-to-end service that would result from a variety of this bandwidth possible
      reservation requests.  The results ("advertisements") are
      delivered by RSVP to the receiver host, and perhaps to the
      receiver application.  The information may then be unused at
           any one time.  If D' changes (because used by the
      receiver changed D
           or because the number Ns to construct an appropriate reservation request.

   1.3 Reservation Styles

      Each RSVP reservation request specifies a "reservation style".
      The following reservation styles are defined in this version of upstream sources changed), or if
      the common flowspec changes, protocol.

      1.   Wildcard-Filter (WF) Style

           The WF style specifies the refresh message is treated
           as options: "mixing" reservation and
           " wildcard" reservation scope.  Thus, a new WF-style reservation
           creates a single reservation into which flows from all
           upstream senders are mixed.  This reservation may be thought
           of a shared "pipe", whose "size" is the largest of the
           resource requests for that link from all receivers,
           independent of the number of senders using it.  A WF-style
           reservation has wildcard scope, i.e., the reservation is subject
           propagated upstream towards all senders.  A WF-style
           reservation automatically extends to admission control and
           may fail.

           Like a new senders to the
           session as they appear.

      2.   Fixed-Filter (FF) Style

           The FF style request, specifies the options: "distinct" reservation
           and a DF "unitary" reservation scope.  Thus, an elementary FF-
           style reservation request causes creates a distinct
           reservations reservation for different senders.

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

      WF reservations are appropriate mixing them with
           other senders' packets for those multicast applications
      whose application-level constraints prohibit all data sources from
      transmitting simultaneously; one the same session.

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

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

      The essential difference between the FF WF and DF FF styles is that the
      DF style allows a receiver to switch channels without danger of an
      admission denial due to limited resources (unless a topology
      change reroutes traffic along are incompatible and cannot be combined
      within a lower-capacity path or new senders
      appear), once the initial reservations have been made. session.  Other reservation styles may be defined in the future.

   2.3
      future (see Appendix C).

2. RSVP Protocol Mechanisms

      2.3.1

   2.1 RSVP Messages

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

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

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

                           Figure 2: 3: RSVP Messages

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

         The path each node.  Path
      state is currently used by RSVP to route the RESV messages hop-by-hop in the
      reverse direction from each receiver to all
         selected senders for a given session.  In direction.  (In the future, this
         function may be assumed by some routing protocols. protocols may
      supply reverse path forwarding information directly, without path
      state).

      PATH messages
         have other functions; they may also carry the following additional information:

      o    A sender template, which    Sender Template

           The Sender Template describes the format of data packets that
           the sender will originate.

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

              ISSUE:

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

      o    A    Tspec

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

         A (template, flowspec) pair in a

      o    Adspec

           The PATH message is called may carry a
         Sender Descriptor.

      2.3.2 Soft State

         To maintain reservation state, package of OPWA advertising
           information, known as an "Adspec".

       Previous       Incoming           Outgoing             Next
       Hops           Interfaces         Interfaces           Hops

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

                         Figure 4: Router Using RSVP keeps "soft state" in

      Figure 4 illustrates RSVP's model of a router node.  Each data
      stream arrives from a previous hop through a corresponding
      incoming interface and host nodes.  RSVP soft state is created and
         periodically refreshed by PATH and RESV messages, departs through one or more outgoing
      interface(s).  The same physical interface may act in both the
      incoming and it can outgoing roles (for different data flows but the same
      session).

      As illustrated in Figure 4, there may be
         removed at each node by explicit "Teardown" messages.  RSVP
         also has multiple previous hops
      and/or next hops through a timer-driven cleanup procedure if no message is
         received within given physical interface.  This may
      result from the connected network being a cleanup timeout interval.

         When shared medium or from
      the route changes, existence of non-RSVP routers in the path to the next PATH message will initialize RSVP hop
      (see Section 2.6).  An RSVP daemon must preserve the next and
      previous hop addresses in its reservation and path state state,
      respectively.  A RESV message is sent with a unicast destination
      address, the address of a previous hop.   PATH messages, on the new route, and future RESV messages will
         establish
      other hand, are sent with the session destination address, unicast
      or multicast.

      Although multiple next hops may send reservation state while requests through
      the state same physical interface, the final effect should be to install
      a reservation on that interface, which is defined by an effective
      flowspec.  This effective flowspec will be the now-unused
         segment "maximum" of the route times out.  Thus, whether
      flowspecs requested by the different next hops.  In turn, a RESV
      message is
         "new" or forwarded to a "refresh" particular previous hop carries a flowspec
      that is determined separately at each node,
         depending upon the existence of state at that node.  (This
         document will use "maximum" over the term "refresh message" in this effective
         sense, to indicate an RSVP message that does not modify the
         existing state at reservations on the node in question.)

         RSVP sends all its messages as IP datagrams without any
         reliability enhancement.  Periodic transmission of refresh
         messages by hosts and routers
      corresponding outgoing interfaces.  Both cases represent merging,
      which is expected discussed further below.

      There are a number of ways for a new reservation request to replace any lost
         RSVP messages.  However, the traffic control mechanism should fail
      in a given node.

      1.   There may be statically configured to grant high-reliability service to
         RSVP messages, to protect RSVP messages from severe congestion.

         If no matching path state (i.e., the set of senders Si or receivers Rj changes, or if any of scope may
           empty), which would prevent the receivers' reservation requests change, being propagated
           upstream.

      2.   Its style may be incompatible with the RSVP state is
         adjusted accordingly.   RSVP believes style(s) of existing
           reservations for the latest PATH and RESV
         messages (ignoring same session on the possibility same outgoing
           interface, so an effective flowspec cannot be computed.

      3.   Its style may be incompatible with the style(s) of reordering).  To modify
           reservations that exist on other outgoing interfaces but will
           be merged with this reservation when a
         reservation, refresh message to
           create a receiver simply starts sending refresh message for the new values.
         It is not necessary (although it previous hop.

      4.   The effective flowspec may sometimes be desirable,
         when the resources being consumed are "valuable"), fail admission control.

      In any of these cases, an error message is returned to tear down the old
      receiver(s) responsible for the message, but any existing
      reservation explicitly.

         When a RESV message is received at left in place.  This prevents a router or sender host, new, very large,
      reservation from disrupting the
         RSVP module checks whether the message is a new or a modified
         reservation request, or whether it simply refreshes existing QoS by merging with an
      existing
         reservation.  A new or modified request is passed to the reservation and then failing admission control module for a decision.  If the control.

   2.2 Soft State

      To maintain reservation is
         accepted, state, RSVP sets up (or modifies) the reservation keeps "soft state" in router
      and filter
         state.  It host nodes.  RSVP soft state is created and periodically
      refreshed by PATH and RESV messages.  The state is deleted if no
      refreshes arrive before the expiration of a "cleanup timeout"
      interval; it may also forwards be deleted as the RESV message result of an explicit
      "Teardown" message.  It is not necessary (although it may be
      desirable, since the resources being consumed may be "valuable"),
      to explicitly tear down an old reservation.

      When a route changes, the next reverse-
         hop router(s) or sender host(s), as determined by PATH message will initialize the
      path (or
         routing) state.  If RSVP state on the node rejects the new route, and future RESV messages will
      establish reservation
         request due to admission control failure or to some processing
         error, it discards state, while the RESV message and returns a RSVP error
         message to state on the originating receiver host.  If now-unused
      segment of the request
         modifies route will time out.  Thus, whether a previous reservation, RSVP may immediately remove
         the old state, message is
      "new" or it may simply let the old state time out
         since it a "refresh" is no longer being refreshed; the details depend determined separately at each node,
      depending upon the style and existence of state at that node.  (This
      document uses the implementation.

          Previous    Incoming               Outgoing         Next
          Hops        Interfaces             Interfaces       Hops

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

                           Figure 3: Router Using term "refresh message" in this effective sense,
      to indicate an RSVP

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

         The interfaces shown node in Figure 3 may be physical interfaces
         (e.g., question.)
      In addition to point-to-point links), or they may be logical
         interfaces that reach multiple nodes through the same physical
         interface.  Multiple previous hops and/or next hops through cleanup timeout, there is a
         given physical interface can result from either "refresh timeout"
      period.  As messages arrive, the connected
         network being a shared medium (e.g., an Ethernet), or from RSVP daemon checks them against
      the
         existence of non-RSVP routers in existing state; if it matches, the path to cleanup timeout timer on
      the next RSVP hop
         (see Section 3.5).  It state is generally necessary for reset and the message is dropped.  At the expiration
      of each refresh timeout period, RSVP scans its state to track
         both logical build and physical interfaces on both the incoming
      forward PATH and
         outgoing sides.

      2.3.3 Merging RSVP Messages

         Whenever possible, the control information arriving in RESV refresh messages to succeeding hops.

      RSVP sends its messages for a given session is combined into fewer outgoing
         messages; this is known generically as "merging".  Those
         messages that cause a state change are forwarded IP datagrams without delay,
         while the reliability
      enhancement.  Periodic transmission of refresh messages may by hosts
      and routers is expected to replace any lost RSVP messages.  To
      tolerate K successive packet losses, the effective cleanup timeout
      must be merged into fewer messages,
         perhaps only one per session.

         For PATH messages, merging implies collecting together at least K times the
         Sender Descriptors from multiple incoming messages into a
         single outgoing PATH message.  For RESV messages, merging
         implies that only refresh timeout.  In addition, the essential (e.g.,
      traffic control mechanism in the largest) reservation
         requests need network should be forwarded, once per refresh period; redundant statically
      configured to grant high-reliability service to RSVP messages, to
      protect RSVP messages are "purged".  A successful reservation request will
         propagate as far from congestion losses.

      In steady state, refreshing is performed hop-by-hop, which allows
      merging and packing as described in the closest point(s) along next section.  However, if
      the sink tree to received state differs from the sender(s) where a reservation level equal or greater than
         that being requested has been made.  At that point, stored state, the merging
         process stored state
      is updated.  Furthermore, if the result will drop it in favor of another, equal or larger,
         reservation request.

         To allow merging, each node must save be to modify the state from received
         messages and then periodically generate cumulative PATH and
         RESV
      refresh messages from the saved state, to be generated, these refresh messages must be
      generated and forwarded immediately.  This will result in place changes
      propagating end-to-end without delay.  However, propagation of
         the received messages.  Thus, new refresh messages are created
         hop-by-hop inside the network, at a rate determined by a
         "refresh period".  Since messages that modify
      change stops when and if it reaches a point where merging causes
      no resulting state change; this minimizes RSVP control traffic due
      to changes, and is essential for scaling to large multicast
      groups.

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

      The RSVP state associated with a session in a particular node ("new" messages) is
      divided into atomic elements that are forwarded without delay, created, refreshed, and
      timed out independently.  The atomicity is determined by the refresh
         period does not affect
      requirement that any sender or receiver may enter or leave the rate
      session at which new any time, and its state propagates
         from end to end (when packets are not lost).

         Although flowspecs are opaque to RSVP, merging requires the
         ability to determine which should be created and timed out
      independently.  Management of two flowspecs RSVP state is "larger", i.e.
         whether one represents a stricter request (and hence represents
         a larger resource commitment) than the other.  However, a
         flowspec may be a complex multi-dimensional vector, so the
         "larger-than" relationship because there
      may not be defined for a given pair
         of flowspecs.  For example, consider two flowspecs Fls1 one-to-one correspondence between state carried in
      RSVP control messages and
         Fls2, where Fls2 asks for the resulting state in nodes.  Due to
      merging, a lower throughput but shorter delay
         that Fls1.  It is not clear which is "larger", so we say they
         are "incompatible".

         There are several possible solutions single message contain state referring to merging incompatible
         flowspecs.

              (1)  Compare on multiple
      stored elements.  Conversely, due to reservation sharing, a single dimension, e.g., compare
      stored state element may depend upon (typically, the
                   throughput requirement (average bit rate) only.

              (2)  Construct a third flowspec maximum of)
      state values received in multiple control messages.

   2.3 Merging and Packing

      A previous section explained that is greater than each
                   of the two being compared.  In reservation requests in RESV
      messages are necessarily merged, to match the example above, we
                   could construct multicast
      distribution tree.  As a third flowspec Fls3 by combining
                   the higher throughput from Fls1 with result, only the lower delay
                   from Fls2.

              (3)  Treat essential (i.e., the compatibility
      "largest") reservation requests are forwarded, once per refresh
      period.  A successful reservation request will propagate as far as an error that should be
                   avoided by applications.

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

         Note that this problem cannot be avoided by refraining from
         merging flowspecs.  If incompatible flowspecs were not merged
         at a particular node A, then they would arrive at
      the next node
         upstream, say B, in separate RESV messages.  This may also
         happen if there are multiple next hops across closest point(s) along the same outgoing
         interface.  Node B would have sink tree to make the sender(s) where a
      reservation for the
         largest flowspec, if that is defined, level equal or one greater than that dominates all
         the given flowspecs; being requested has
      been made.  At that is, point, the merging process will drop it in
      favor of another, equal or larger, reservation request.

      Although flowspecs are opaque to RSVP, an RSVP daemon must merge the unmerged
         reservations.  Thus, failing be able
      to merge simply moves calculate the problem
         one node upstream. "largest" of a set of flowspecs.  This mechanism, reserving for the highest demand at each node,
         allows an application is
      required both to increase an existing reservation
         request immediately (assuming admission control does not fail
         for calculate the larger flowspec).  Decreasing a reservation has effective flowspec to be
         handled more cautiously, however.  The arrival of install on a RESV
         message with an apparently decreased reservation might be
         caused by
      given physical interface (see the loss of a merged RESV message downstream.
         Therefore, an RSVP should not "believe" discussion in connection with
      Figure 4), and to merge flowspecs when sending a reservation decrease
         until the cleanup timeout has passed.

         The refresh period message
      upstream.  Since flowspecs are generally multi-dimensional vectors
      (they contain both Tspec and the cleanup timeout must obey the
         following general principles:

              A.   The refresh period must Rspec components, each of which may
      itself be long enough to keep multi-dimensional), they are not strictly ordered.  When
      it cannot take the larger of two flowspecs, RSVP
                   overhead must compute and
      use a third flowspec that is at least as large as each, i.e., a
      "least upper bound" (LUB).  It is also possible for two flowspecs
      to be incomparable, which is treated as an acceptable level.

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

                   Applications may differ in their sensitivity to
                   service outages, definition
      and therefore they should be able to
                   adjust implementation of the refresh period rules for their session state.
                   However, comparing flowspecs are
      outside RSVP proper, but they are defined as part of the technique service
      templates.

      For protocol efficiency, RSVP also allows multiple sets of "local repair" (see Section
                   3.3.3) can provide rapid adaptation despite a long
                   refresh period.

              C.   The timeout period must be long enough to allow path
      (or reservation) information for
                   loss of individual the same session to be "packed"
      into a single PATH (or RESV) message, respectively.  (For
      simplicity, the protocol prohibits packing different sessions into
      the same RSVP messages.

      2.3.4 message).

   2.4 Teardown

         As an optimization to release resources quickly,

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

         Teardown not explicitly deleted.

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

      To increase the reliability of teardown, Q copies of any given
      teardown message can be sent.  Note that a node cannot actually
      delete the state being torn down until it has sent Q Teardown
      messages; it must place the state in a "moribund" status
      meanwhile.  The appropriate value of Q is an engineering issue.  Q
      = 1 would be the simplest and may be adequate, since unrefreshed
      state will time out anyway; teardown is an optimization.  If one
      or more Teardown message hops are lost, the router that failed to
      receive a Teardown message will time out its state and initiate a
      new Teardown message beyond the loss point.  Assuming that RSVP
      message loss probability is small, the longest time to delete
      state will seldom exceed one refresh timeout period.

      There are two types of RSVP Teardown message, PTEAR and RTEAR.  A
      PTEAR message travels towards all receivers downstream from its
      point of initiation and tears down path state along the
         way, while an way.  A
      RTEAR message tears down reservation state and travels towards all
      senders upstream from its point of initiation.  A particular reservation on a node PTEAR (RTEAR)
      message may be shared among multiple
         senders and/or receivers, but it must apply to conceptualized as a unique next
         hop (and outgoing interface).  The receipt of an RTEAR reversed-sense Path message
         implies that the corresponding reservation state has been
         removed downstream, so that the reservation can safely be
         deleted locally.  Again, the local node will only forward the
      (Resv message, respectively).

      A teardown message upstream when deletes the specified state named in the message
         has been entirely removed locally. node where
      it is received.  Like any other state change, this will be
      propagated immediately to the next node, but only if it represents
      a change.  As a result, an RTEAR message will prune the
      reservation state back (only) as far as possible.  Note that the
      RTEAR message will cease to be forwarded at the same node where
      merging suppresses forwarding of the corresponding RESV messages.

         Consider
      The change will be propagated as a new teardown message if the router configuration shown in Figure 4 below.
         Assume that there are reservations for source S1 on both
         outgoing interfaces (c) and (d), and that the receiver R1 wants
      result has been to tear down its reservation state for S1.  R1's RTEAR message
         arriving through interface (c) indicates that remove all reservation state for (this this session and) sender S1 has been removed
         downstream.  The current node therefore removes the S1
         reservation state from interface (c).  However, since there
         will still be an S1 reservation on interface (d), the RTEAR
         message will not be forwarded any further. at this node.
      However, if the outgoing interface connects to a shared medium
         or if there is a non-RSVP router immediately downstream, then
         there result may simply be multiple next-hop RSVP nodes downstream that are
         reached through to change the same outgoing interface, say (c).  Then propagated
      information; thus, the receipt of a
         single reservation RTEAR message may be shared among multiple next hops.
         RSVP must tag each reservation with the next hop(s) from which result in
      the immediate forwarding of a modified RESV messages came, for use by teardown to avoid deleting
         shared state. refresh message.

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

         o    Wildcard-Filter depends upon the style: If if
      the style is WF and S is the only sender to the session, delete
      the reservation.

         o    Fixed-Filter style: Delete reservation; if the style is FF, delete only reservations made for
      sender S.

         o    Dynamic-Filter style: Reduce total  These reservation if it now
              exceeds changes should not trigger an
      immediate RESV refresh message, since the total number of remaining senders.

   2.4 Examples

      We use teardown message will
      have already made the following notation for required changes upstream.  However, at the
      node in which an RTEAR message stops, the change of reservation
      state may trigger a RESV message:

      1.   Wildcard-Filter

           WF( *{r})

           Here "*{r}" represents a Flow Descriptor with a "wildcard"
           filter (choosing all senders) and a flowspec of quantity r.
           For simplicity we assume here refresh starting at that flowspecs node.

   2.5 Security

      There are one-
           dimensional, defining for example the average throughput, and
           state them as a multiple of some unspecified base resource
           quantity B.

      2.   Fixed-Filter
           FF( S1{r1}, S2{r2}, ...)

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

      3.   Dynamic-Filter

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

           This message carries security concerns in RSVP.

      1.   Protecting RSVP Message Integrity

           It may be necessary to ensure the count n integrity of channels to RSVP messages
           against corruption or spoofing, hop by hop.  RSVP messages
           have an optional integrity field that can be reserved,
           each using common flowspec r.  It also carries created and
           verified by neighboring RSVP nodes.

      2.   Authenticating Reservation Requests

           RSVP-mediated resource reservations may reserve network
           resources, providing special treatment for a list,
           perhaps empty, particular set
           of filterspecs defining senders.

      Figure 4 shows schematically a router with two previous hops
      labeled (a) and (b) and two outgoing interfaces labeled (c) and
      (d).  This topology users.  Administrative mechanisms 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 necessary to
           control who gets privileged service and R2
      (R3) are routed via outgoing interface (c) ((d) respectively).

      In addition to collect billing
           information.  These mechanisms may require secure
           authentication of senders and/or receivers responsible for
           the connectivity shown in 4, we must also specify
      the multicast routing within this node.  Assume first that data
      packets (hence, PATH messages) from each Si shown in Figure 4 reservation.  RSVP messages may contain credential
           information to verify user identity.

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

   2.6 Automatic RSVP Tunneling

      It is
      routed impossible to both outgoing interfaces.  Under this assumption,
      Figures 5, 6, and 7 illustrate Wildcard-Filter reservations,
      Fixed-Filter reservations, and Dynamic-Filter reservations,
      respectively.

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

                        Figure 4: Router Configuration

      In Figure 5, deploy RSVP (or any new protocol) at the "Receive" column shows same
      moment throughout the RESV messages received
      over outgoing interfaces (c) entire Internet.  Furthermore, RSVP may
      never be deployed everywhere.  RSVP must therefore provide correct
      protocol operation even when two RSVP-capable routers are joined
      by an arbitrary "cloud" of non-RSVP routers.  Of course, an
      intermediate cloud that does not support RSVP is unable to perform
      resource reservation, so service guarantees cannot be made.
      However, if there is sufficient excess capacity through such a
      cloud, acceptable and () useful realtime service may still be
      possible.

      RSVP will automatically tunnel through such a non-RSVP cloud.
      Both RSVP and the "Reserve" column shows
      the resulting reservation state for each interface.   The "Send"
      column shows the RESV non-RSVP routers forward PATH messages forwarded to previous hops (a) and
      (b).  In towards the "Reserve" column, each box represents one reservation
      "channel", with
      destination address using their local uni-/multicast routing
      table.  Therefore, the corresponding filter.  As a result routing of merging,
      only  Path messages will be
      unaffected by non-RSVP routers in the path.  When a PATH message with
      traverses a non-RSVP cloud, the largest flowspec is forwarded upstream
      to each previous hop.

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

               Figure 5: Wildcard-Filter Reservation Example 1

      Figure 6 shows Fixed-Filter style reservations.  Merging takes
      place among copies that emerge will carry as a
      Previous Hop address the flow descriptors (i.e., filter spec, flowspec
      pairs).  For example, IP address of the message last RSVP-capable
      router before entering the cloud.  This will effectively construct
      a tunnel through the cloud for RESV messages, which will be
      forwarded directly to previous hop b, the next RSVP-capable router on the path(s)
      back towards S2 and S3, contains flow descriptors received from
      outgoing interfaces (c) and (d).  Similarly, when FF( S1{B} ) and
      FF( S1{3B} ) are merged, the single message FF( S1{3B} ) source.

      Automatic tunneling is sent not perfect; in some circumstances it may
      distribute path information to previous hop (a), towards S1.

      For each outgoing interface, there RSVP-capable routers not included
      in the data distribution paths, which may create unused
      reservations at these routers.  This is a private reservation for
      each because PATH messages
      carry the IP source that has been requested, but this private reservation
      is shared among address of the receivers that made previous hop, not of the request.

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

               Figure 6: Fixed-Filter Reservation Example

      Figure 7 shows an example of Dynamic-Filter reservations.  The
      receivers downstream from interface (d) have requested two
      reserved channels, but selected only one
      original sender, S1.  The node
      reserves min(2,3) = 2 channels and multicast routing may depend upon the source
      as well as the destination address.  This can be overcome by
      manual configuration of size B on interface (d), the neighboring RSVP programs, when
      necessary.

   2.7 Session Groups

      Section 1.2 explained that a distinct destination address, and
      therefore a distinct session, will be used for each of the
      subflows in a hierarchically encoded flow.  However, these
      separate sessions are logically related.  For example it
      then applies any specified filters may be
      necessary to these channels.  Since only
      one sender was specified, one channel has no corresponding filter,
      as shown pass reservations for all subflows to Admission
      Control at the same time (since it would be nonsense to admit high
      frequency components but reject the baseband component of the
      session data).  Such a logical grouping is indicated in RSVP by `?'.

      Similarly,
      defining a "session group", an ordered set of sessions.

      To declare that a set of sessions form a session group, a receiver
      includes a data structure we call a SESSION_GROUP object in the receivers downstream
      RESV message for each of interface (c) have
      requested two channels and selected senders S1 the sessions.  A SESSION_GROUP object
      contains four fields: a reference address, a session group ID, a
      count, and S2. a rank.

      o    The two
      channels might have been one channel each reference address is an agreed-upon choice from R1 and R2, or two
      channels requested by one of them, for example.

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

              Figure 7: Dynamic-Filter Reservation Example

      A router should not reserve more Dynamic-Filter channels than among the
      number
           DestAddress values of upstream sources (three, the sessions in the router of Figure 7).
      Since there is only one source upstream from previous hop (a), group, for example
           the
      first parameter of smallest numerically.

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

      o    The count is the number of channels to be
      reserved) was decreased to 1 members in the forwarded reservations.
      However, this group.

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

      The SESSION_GROUP objects for all sessions in the group will
      reserve only one channel, regardless.

      When a DF reservation is received, it is labeled with
      contain the IP
      address same values of the next hop (RSVP-capable) router, downstream from reference address, the
      current node.  Since session
      group ID, and the outgoing interface may be directly
      connected to a shared medium network or to count value.  The rank values establishes the
      desired order among them.

      If RSVP at a non-RSVP-capable
      router, there may be more than one next-hop given node downstream; if
      so, each sends independent DF receives a RESV message containing a
      SESSION_GROUP object, it should wait until RESV messages for a given session.
      The number N' of DF channels reserved on an outgoing interface is
      given by all
      `count' sessions have appeared (or until the formula:

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

      where Di is end of the D value (channel reservation count) refresh
      cycle) and then pass the RESV requests to Admission Control as a
      group.  It is normally expected that all sessions in the group
      will be routed through the same nodes.  However, if not, only a RESV from
      subset of the ith next-hop node.

      The three examples just shown assume full routing, i.e., data
      packets from S1, S2, session group reservations may appear at a given
      node; in this case, the RSVP should wait until the end of the
      refresh cycle and S3 are routed to both outgoing
      interfaces.  Assume then perform Admission Control on the subset of
      the session group that it has received.  The rank values will
      identify which are missing.

      Note that routing shown different sessions of the session group
      differently will generally result in Figure 8, delays in which data
      packets from S1 are not forwarded to interface (d) (because establishing or
      rejecting the
      mesh topology provides desired QoS.  A "bundling" facility could be added
      to multicast routing, to force all sessions in a shorter path for S1->R3 that does not
      traverse this node).

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

                        Figure 8: Router Configuration

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

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

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

   2.5 same path.

   2.8 Host Model

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

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

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

      H3   A receiver listens for PATH messages.

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

      H5   A sender starts sending data packets.

      There are several synchronization issues. considerations.

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

      o    Suppose that a new sender starts sending PATH messages (H2)
           and immediately starts sending data, data (H5), and there are
           receivers but no RESV messages have reached the sender yet
           (e.g., because its PATH messages have not yet propagated to
           the receiver(s)).  Then the initial data may arrive at
           receivers without the desired QoS.

      o    If a receiver starts sending RESV messages (H4) before any
           PATH messages have reached it (H5) (and if path state is
           being used to route RESV messages), RSVP will return error
           messages to the receiver.  The receiver may simply choose to
           ignore such error messages, or it may avoid them by waiting
           for PATH messages before sending RESV messages.

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

3. Functional Specification

   There are currently 6 types of RSVP messages: PATH, RESV, PTEAR,
   RTEAR, PERR, and RERR.

   3.1 Message Formats

      3.1.1 Path Message

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

   We use the following notation for a RESV message:

   1.   Wildcard-Filter

        WF( *{Q})

        Here "*{Q}" represents a Flow Descriptor List                  |
         //                         ...                          //
         +-------------+-------------+-------------+-------------+

         IP Fields:

              Protocol

                   46

              IP Source Address

                   The IP address with a "wildcard" scope
        (choosing all senders) and a flowspec of the host or router sending this
                   message.

              IP Destination Address

                   The IP address quantity Q.

   2.   Fixed-Filter

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

        A list of the data destination (DestAddress).

         RSVP Fields:

              Vers

                   Version number.  This is version 1.

              Type

                   1  = Path Message

              Flags

                   8 = Drop

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

              RSVP Checksum

                   A standard TCP/UDP checksum, over the contents of the
                   RSVP message with single RESV message.

   For simplicity we assume here that flowspecs are one-dimensional,
   defining for example the checksum field replaced by
                   zero.

              DestAddress, ResvID

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

              Previous Hop Address

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

                   The Previous Hop Address is used to support reverse-
                   path forwarding state them as a
   multiple of RESV messages.  This field is
                   initialized by some unspecified base resource quantity B.

   Figure 5 shows schematically a sender to its IP address (see IP
                   Source Address above) and must be updated at each router hop as the PATH message is forwarded.

              Refresh Period

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

              State TTL Time with two previous hops labeled
   (a) and (b) and two outgoing interfaces labeled (c) and (d).  This field specifies the time-to-live for soft state,
   topology will be assumed in milliseconds.  It determines the cleanup timeout
                   period; see Section 3.3 below.

              SD Count

                   Count of Sender Descriptors examples that follow.

              Authentication Field

                   A variable-length authentication field to identify  There are
   three upstream senders; packets from sender S1 (S2 and perhaps authenticate the principal making this
                   reservation request.  The field has the following
                   form:

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

                   The AuthLen octet contains the integer length of the
                   field in fullwords, and AuthType specifies the format
                   of the field.  See Section 3.6.1 S3) arrive
   through previous hop (a) ((b), respectively).  There are also three
   downstream receivers; packets bound for currently
                   defined authentication field formats.  If there is no
                   authentication information, AuthLen will be zero, but R1 and R2 (R3) are routed via
   outgoing interface (c) ((d) respectively).

   In addition to the Authentication Field will still occupy one
                   fullword connectivity shown in 5, we must also specify the message.

              Sender Descriptor List

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

         Each sender must periodically send a PATH message containing a
         single Sender Descriptor describing its own node.  Assume first that data stream.  These
         messages are addressed packets
   (hence, PATH messages) from each Si shown in Figure 5 is routed to the uni-/multicast destination
         address for the session,
   both outgoing interfaces.  Under this assumption, Figures 6 and they are forwarded to all
         receivers, following 7
   illustrate Wildcard-Filter reservations and Fixed-Filter
   reservations, respectively.

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

                      Figure 5: Router Configuration

   In Figure 6, the same paths as a data packet from "Receive" column shows the
         same sender.  PATH RESV messages are received
   over outgoing interfaces (c) and processed locally
         to create path () and the "Reserve" column shows
   the resulting reservation state at for each intermediate router along interface.   The "Send"
   column shows the
         path.

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

         PATH RESV messages are distributed from senders forwarded to receivers along
         the exact paths that previous hops (a) and
   (b).  In the data will traverse, using uni-
         /multicast routing.  This distribution actually takes place
         hop-by-hop, allowing RSVP in "Reserve" column, each router along box represents one reservation
   "channel", with the path corresponding filter.  As a result of merging,
   only the largest flowspec is forwarded upstream to
         observe each previous hop.

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

              Figure 6: Wildcard-Filter Reservation Example 1

   Figure 7 shows Fixed-Filter style reservations.  The flow descriptors
   for senders S2 and modify S3, received from outgoing interfaces (c) and (d),
   are packed into the message.  Routing of PATH messages is
         based on message forwarded to previous hop b.  On the sender address(es) from
   other hand, the Sender Descriptor(s),
         not two different flow descriptors for sender S1 are
   merged into the IP source address.  This single message FF( S1{3B} ), which is necessary sent to prevent loops;
         see Section 3.2.

         Each Sender Descriptor consists of two variable-length fields:
   previous hop (a), For each outgoing interface, there is a sender template private
   reservation for each source that defines has been requested, but this private
   reservation is shared among the format of data packets and a
         corresponding Flowspec receivers that describes the traffic
         characteristics.  The sender template has made the form of a
         filterspec, and a Sender Descriptor has the form defined below
         for a Flow Descriptor (see also Section 3.6.1).  The flowspec
         may be omitted, in which case its length field will be zero
         (but it will still occupy one fullword in the Sender
         Descriptor).

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

      3.1.2 Resv Message

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

                0             1              2             3
         +-------------+-------------+-------------+-------------+
         | Vers | Type |    Flags request.

                       |       RSVP Checksum
         Send          |
         +-------------+-------------+-------------+-------------+       Reserve              Receive
                       |                      DestAddress
                       |
         +-------------+-------------+-------------+-------------+       ________
  FF( S1{3B} ) <- (a)  |                        ResvID  (c) |
         +-------------+-------------+-------------+-------------+ S1{B}  |                    Refresh Period   (c) <- FF( S1{B}, S2{5B} )
                       |
         +-------------+-------------+-------------+-------------+      |________|
                       |                    State TTL Time      |
         +-------------+-------------+-------------+-------------+ S2{5B} |                   Next Hop Address
                       |
         +-------------+-------------+-------------+-------------+      |________|
  ---------------------|---------------------------------------------
                       |                     RecvAddress       ________
               <- (b)  |
         +-------------+-------------+-------------+-------------+  (d) | Dynamic Reservation Count S1{3B} |         FD Count   (d) <- FF( S1{3B}, S3{B} )
  FF( S2{5B}, S3{B} )  |
         +-------------+-------------+-------------+-------------+      |________|
                       |                 Authentication Field      |
         //                         ...                          //
         +-------------+-------------+-------------+-------------+ S3{B}  |                Flow Descriptor List
                       |
         //                         ...                          //
         +-------------+-------------+-------------+-------------+      |________|

               Figure 7: Fixed-Filter Reservation Example

   The fields two examples just shown assume full routing, i.e., data packets
   from S1, S2, and S3 are routed to both outgoing interfaces.  Assume
   the same as defined earlier for a PATH message,
         except for the following:

         IP Fields:

              IP Source Address

                   The IP address of routing shown in Figure 8, in which data packets from S1 are not
   forwarded to interface (d) (because the node sending mesh topology provides a
   shorter path for S1 -> R3 that does not traverse this message.

              IP Destination Address

                   The IP address of the next-hop router or host to
                   which node).

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

                      Figure 8: Router Configuration

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

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

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

4. RSVP Functional Specification

   4.1 RSVP Fields:

              Type

                   2 = Resv Message

              Flags Formats

      All RSVP messages consist of a common header followed by a
      variable number of variable-length typed "objects" using a common
      structure.  The following flag bit combinations subsections that follow define the
                   reservation style:

                   001xxxxx = Wildcard-Filter

                   010xxxxx = Fixed-Filter

                   011xxxxx = Dynamic-Filter

              Next Hop Address

                   The IP address formats of the interface through which
      common header, the
                   last forwarded this message.

                   The Next Hop Address is used to support teardown.
                   This field is initialized by a receiver to its IP
                   address object structures, and must be updated at each router hop as of the
                   RESV RSVP message
      types.  For each RSVP message type, there is forwarded.

              RecvAddress

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

              Dynamic Reservation Count

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

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

              FD Count

                   Count of Flow Descriptors in the Flow Descriptor
                   List.

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

                   Each Flow Descriptor has the following form: object types.  These rules
      are specified using Backus-Naur Form (BNF) augmented with square
      brackets surrounding optional sub-sequences.

      4.1.1 Common Header

                0             1              2             3
         +-------------+-------------+-------------+-------------+
         |  FiltSLen Vers | Type |  FiltSType    Flags    |       Message Length      |
             +-------------+-------------+                           +
             //                    Filter Spec ...                   //
         +-------------+-------------+-------------+-------------+
         |  FlowSLen   |  FlowSType       RSVP Checksum       |        Object Count       |
             +-------------+-------------+                           +
             //                    Flow Spec ...                     //
         +-------------+-------------+-------------+-------------+

                   Here FiltSLen and FlowSLen are one-octet

         The common header fields
                   specifying the lengths are as follows:

         Vers

              Protocol version number.  This is version 2.

         Type

              1 = PATH

              2 = RESV

              3 = PERR

              4 = RERR

              5 = PTEAR

              6 = RTEAR

         Flags

              0x01 = Entry-Police
                   This flag should be on in fullwords (including the
                   length byte) of a PATH message sent by an
                   RSVP daemon in a sender host.  The first RSVP node
                   that finds the filterspec and flowspec,
                   respectively, and FiltSType and FlowSType are one-
                   octet fields defining flag on in a PATH message (i.e., the corresponding field
                   formats.  See Section 3.6.1
                   first-[RSVP-]hop router) should institute policing
                   for currently defined
                   formats.

         The following specific rules hold for different reservation
         styles.

         o    Wildcard-Filter

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

         o    Fixed-Filter

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

         o    Dynamic-Filter

              Include max(1, FD Count) Flow Descriptors flow(s) described in the this message.
              Here the FD Count specifies the number of sender
              Filterspecs that are included.  If DC  This flag
                   should never be forwarded in PATH refresh messages.

              0x02 = LUB-Used

                   This flag is described below in the Dynamic
              Reservation Count, then DC >= FD Count >= 0. section on Error
                   Messages.

         Message Length

              The Flowspec part total length of this RSVP message, including this
              common header and the first Flow Descriptor defines objects included in Object Count.

         RSVP Checksum

              A standard TCP/UDP checksum over the
              desired size contents of all the DC channels that are reserved.
              The Flowspec parts of later Flow Descriptors (if any) are
              ignored.

      3.1.3 Error Messages

         There are two types of RSVP error messages: PERR messages
         result from PATH messages and travel towards senders, while
         RERR messages result from RESV messages and travel towards
         receivers. RSVP error messages are triggered only
              message, with the checksum field replaced by
         processing zero.

         Object Count

              Count of PATH and RESV messages; errors encountered while
         processing error variable-length objects that follow.

      4.1.2 Object Formats

         An object consists of one or teardown messages must not create error
         messages.

         A PERR message has more 32-bit words with a one-word
         header, in the following form: format:

                0             1              2             3
         +-------------+-------------+-------------+-------------+
         | Vers | Type |    Flags    |       RSVP Checksum       |
         +-------------+-------------+-------------+-------------+
         |                      DestAddress                      |
         +-------------+-------------+-------------+-------------+
         |                        ResvID                         |
         +-------------+-------------+-------------+-------------+
         |  Error Code | Error Index |        Error Value        |
         +-------------+-------------+-------------+-------------+
         |       ////////////// (ignored) //////////////////     |
         +-------------+-------------+-------------+-------------+
         |       ////////////// (ignored) //////////////////       Length (bytes)      |
         +-------------+-------------+-------------+-------------+
         |     /// Reserved ///    Class    |         SD Count    C-Type   |
         +-------------+-------------+-------------+-------------+
         |                 Authentication Field                                                       |
         //                         ...                  (Object contents)                   //
         +-------------+-------------+-------------+-------------+
         |                Sender Descriptor List                                                       |
         //                         ...                          //
         +-------------+-------------+-------------+-------------+

         The fields are

         An object header has the same as following fields:

         Length

              Total length in bytes.  Must always be a PATH message, defined earlier,
         except for multiple of 4,
              and at least 4.

         Class

              Object class.  In this document, the following:

         RSVP Fields:

              RSVPType

                   3 names of object
              classes are capitalized.

              0 = PERR message

              Error Code NULL

                   A one-octet error description.

                        01 = Insufficient memory

                        02 = Count Wrong

                             The SD Count field does not match NULL object has a Class of zero; its C-Type is
                   ignored.  Its length must be at least 4, but can be
                   any multiple of
                             message.

              Error Index

                   Position 4.  A NULL object may appear anywhere
                   in a sequence of Sender Descriptor that caused the error
                   within
                        Sender Descriptor List.  An integer between zero objects, and SD Count - 1.

              Error Value

                   (Unused)

         A RERR message has its contents will be
                   ignored by the following form:

                0 receiver.

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

         The fields are = SESSION

                   Contains the same as in IP destination address (DestAddress) and
                   possibly a RESV message, defined earlier,
         except generalized source port, to define a
                   specific session for the following: other objects that follow.
                   Required in every RSVP Fields:

              RSVPType

                   4 = RERR message

              Error Code

                   A one-octet error description.

                        DEFINE THESE VALUES IN AN APPENDIX??

                        01 = Insufficient memory

                        02 message.

              2 = Count Wrong

                             The FD Count field does not match length SESSION_GROUP

                   When present, defines a session group, a set of
                             message.

                        03
                   related sessions whose reservation requests should be
                   passed collectively to Admission Control.

              3 = No path information for RSVP_HOP

                   Carries the IP address of the RSVP-capable node that
                   sent this Resv

                        04 message.  This document refers to a
                   RSVP_HOP object as a PHOP ("previous hop") object for
                   downstream messages or as a NHOP ("next hop") object
                   for upstream messages.

              4 = No Sender STYLE

                   Defines the reservation style plus style-specific
                   information for this Resv

                             There that is path information, but it does not
                             include the sender specified a FLOWSPEC or FILTER_SPEC
                   object, in any a RESV message.

              5 = FLOWSPEC

                   Defines a desired QoS, in a RESV message.

              6 = FILTER_SPEC

                   Defines a subset of session data packets that should
                   receive the
                             Filterspecs listed desired QoS (specified by an FLOWSPEC
                   object), in the Resv messager.

                        05 a RESV message.

              7 = Incorrect Dynamic Reservation Count

                             Dynamic Reservation Count is zero or less
                             than FD Count.

                        06 SENDER_TEMPLATE

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

              8 = Filterspec error

                        07 SENDER_TSPEC

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

              9 = Flowspec syntax error

                        08 ADVERT

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

              10 = Flowspec value error

                             Internal inconsistency TIME_VALUES

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

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

                        09 R and T.

              11 = Resources unavailable

                             [Sub-reasons?  Depend upon traffic ERROR_SPEC

                   Specifies an error, in a PERR or RERR message.

              12 = CREDENTIAL

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

              13 = INTEGRITY

                   Contains a cryptographic data to authenticate the
                   originating node, and admission control algorithms?]

              Error Index

                   Position of Flow Descriptor that caused perhaps verify the error contents, of
                   this RSVP message.

         C-Type

              Object type; unique within
                        Flow Descriptor List.  An integer between zero Class.  Values defined in
              Appendix A.

         The Class and FD Count - 1.

              Error Value

                   Specific cause of the error described by the Error
                   Code.

                        DEFINE THESE VALUES IN AN APPENDIX??
         An error message may be duplicated and forwarded unchanged.
         Since PATH and RESV messages C-Type fields may be merged, an error condition
         must be disseminated to all RSVP client applications whose
         requests may have contributed used together as a 16-bit
         number to the error situation.
         Therefore, RSVP error define a unique type for each object.

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

      4.1.3 Path Message

         PATH messages must be propagated and perhaps
         duplicated hop-by-hop.  For this purpose, an error message must
         include all the carry information used from senders to route the original message
         that caused the error: receivers along
         the Sender Descriptor List, Flags,
         RecvAddress, same paths, and Flow Descriptor List fields, as appropriate.
         In particular, a RERR message carries using the same style flags uni-/multicast routes, as
         the RESV data packets.  The IP destination address of a PATH message that caused
         is the error.

         To ease implementation, DestAddress for the error message formats are chosen to
         match session, and the formats source address is
         an address of the messages whose processing caused the
         error.  In particular, a PATH or RESV message node that encounters
         an error can be simply converted to sent the corresponding error message by overwriting the Type and (if possible, the Refresh Period fields.

         A PERR message is forwarded to all previous hops for all
         senders listed in
         address of the Sender Descriptor List. particular interface through which it was sent).

         The routing format of a
         RERR PATH message is more complex.

         o    An error in as follows:

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

                                     [ <INTEGRITY> ]  [ <TIME_VALUES> ]

                                     <sender descriptor list>

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

                               <sender descriptor list> <sender descriptor>

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

                                     [ <SENDER_TSPEC> ]  [ <ADVERT> ]

         Each sender descriptor defines a filterspec should sender, and the sender
         descriptor list allows multiple sender descriptors to be detected at packed
         into a PATH message.  For each sender in the first
              RSVP hop from list, the receiver application, normally within
         SENDER_TEMPLATE object defines the receiver host.  However, an error caused by a
              flowspec, normally an admission control failure, may be
              detected somewhere along the path(s) to the sender(s).

         o    The router that creates a RERR message as the result format of
              processing a RESV message should send data packets, the RERR message out
         SENDER_TSPEC object may specify the interface through which traffic flow, and the RESV arrived.

         o    In succeeding hops,
         CREDENTIAL object may specify the routing of user credentials.  There may
         also be an ADVERT object carrying advertising (OPWA) data.

         Each sender host must periodically send a RERR PATH message depends
              upon
         containing the sender descriptor(s) describing its style.  In general, own data
         stream(s), for a RERR message given session.  Each sender descriptor is sent on a
              pruned version of
         forwarded and replicated as necessary to follow the multicast distribution tree delivery
         path(s) for a data packet from the
              session; those branches that do not have reservations for
              any of same sender, finally
         reaching the specified senders are pruned off.

              A DF-style or WF-style RERR message is forwarded applications on all
              outgoing interfaces for which there is already receivers (except not a
              reservation of
         receiver included in the corresponding style.

              A FF-style RERR message is forwarded on all outgoing
              interfaces for which there is already sender process).

         At each node, a FF-style
              reservation route must be computed independently for the each
         sender (filterspec) corresponding to descriptors being forwarded.  These routes, obtained
         from the error.

         At uni/multicast routing table, generally depend upon the end host, RSVP delivers
         (sender host address, DestAddress) pairs, and consist of a copy list
         of every relevant error
         message to its local application clients.  It examines outgoing interfaces.  Then the set
         of RSVP requests that local clients have made descriptors being forwarded
         through the API,
         and notifies every client same outgoing interface can be packed into as few
         PATH messages as possible.  Note that contributed to the error
         message.  A match multicast routing of path
         information is required between based on the session, filters
         (senders), and reservation styles of sender address(es) from the error message and sender
         descriptors, not the
         corresponding state in IP source address; this is necessary to
         prevent routing loops; see Section 4.3.  PHOP (i.e., the latest API requests.  A particular
         notification
         RSVP_HOP object) of each PATH message should include only contain the IP
         source address, the interface address through which the information (e.g.,
         filters) relevant to that application.

      3.1.4 Teardown Messages

         There are two types of RSVP Teardown message, PTEAR and RTEAR.
         A PTEAR message tears down
         is sent.

         PATH messages are processed at each node they reach to create
         path state state, which includes SENDER_TEMPLATE object and travels towards all
         receivers downstream from its point of initiation.  A RTEAR
         message tears down reservation state possibly
         CREDENTIAL, SENDER_TSPEC, and travels towards all
         senders upstream from its point of initiation.

         A PTEAR message has the same format as ADVERT objects.  If an error is
         encountered while processing a PATH message, except
         that in a PTEAR message:

         o    Type field = 5

         o    Refresh Period and State TTL Time fields are ignored.

         A RTEAR PERR message has is
         sent to all senders implied by the same format as a RESV message, except
         that in a RTEAR message:

         o    Type field = 6

         o    Refresh Period and State TTL Time fields are ignored.

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

         Teardown the
         sender descriptor list.

      4.1.4 Resv Messages

         RESV messages are processed in carry reservation requests hop-by-hop from
         receivers to senders, along the following way.

         o    PTEAR

              Processing reverse paths of data flow for
         the session.  The IP destination address of a PTEAR RESV message is straightforward.  For each
              sender S in
         the message, unicast address of a previous-hop node, obtained from the node removes
         path state for S
              and also deletes all related reservations.  Finally, state.  The Next Hop address (in the
              node forwards RSVP_HOP object)
         should be the original PTEAR message to all outgoing
              interfaces IP address of the (incoming) interface through
         which data packets from some S in the
              packet would be routed.  That is, PTEAR forwarding rules
              are the same as those for PATH messages.

         o    RTEAR
              Processing an RTEAR RESV message is more complex.  Suppose a
              RTEAR message arrives through outgoing interface OI from
              next hop NH.  For each sender S listed in the RTEAR
              message, sent. The IP source address is an
         address of the node checks that sent the reservation, if any, for S on
              OI.  If there is a reservation and if this reservation is
              shared among more than one next hop, then message (if possible, the only action
              is to remove NH from
         address of the list particular interface through which it was sent).

         The permissible sequence of next hops sharing this
              reservation.  If there is only objects in a single next hop, then RESV message depends
         upon the reservation is deleted.  Finally, the node forwards the
              original RTEAR message to all incoming interfaces for
              senders listed style specified in the message.  That is, RTEAR forwarding
              rules STYLE object.
         Currently, object types Style-WF and Style-FF of class STYLE
         are the same as those for defined (see Appendix A).

         The RESV messages.

   3.2 Avoiding Message Loops

      RSVP routes its control messages, and every routing procedure must
      avoid looping packets. message format is as follows:

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

                                     [ <SESSION_GROUP> ]  <RSVP_HOP>

                                     [ <INTEGRITY> ] [ <TIME_VALUES> ]

                                     [ <CREDENTIAL> ]

                                     <style-specific tail>

             <style-specific-tail> ::=

                         <Style-WF> [ <FILTER_SPEC> ]  <FLOWSPEC> |
                         <Style-FF> <flow descriptor list>

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

                         <flow descriptor list> <FILTER_SPEC> <FLOWSPEC>

         The merging reservation scope, i.e., the set of RSVP messages delays
      forwarding at each node for up senders towards which a
         particular reservation is to one refresh period.  This may
      avoid high-speed loop, but there can still be "slow" loops,
      clocked forwarded, is determined by
         matching FILTER_SPEC objects against the refresh period; the effect of such slow loops is to
      keep path state active forever, even if the end nodes have ceased
      refreshing it.  RSVP uses the following rules to prevent looping
      messages.

           L1:  When an RSVP message is received through a particular
                incoming interface F, the message must not be forwarded
                out F as an outgoing interface.  This implies created
         from SENDER_TEMPLATE objects, considering any wildcards that RSVP
                must keep track
         may be present.

      4.1.5 Error Messages

         There are two types of the interface through which each
                message is received, to avoid forwarding it out that
                interface.  Note that, although RSVP distinguishes
                incoming error messages:

         o    PERR messages result from outgoing interfaces, in many cases the
                same physical interface will play both roles.

           L2:  Upon receipt of a PATH message in particular, a route
                must be computed for messages and travel towards
              senders.  PERR messages are routed hop-by-hop like RESV
              messages; at each of its sender Flow
                Descriptors.  These routes, obtained from hop, the
                uni/multicast routing table, generally depend upon IP destination address is the
                (sender host address, DestAddress) pairs.  Each route
                consists
              unicast address of a list of outgoing interfaces; these lists
                (with previous hop.

         o    RERR messages result from RESV messages and travel hop-
              by-hop towards the incoming interfaces deleted appropriate receivers, routed by rule L1) are
                used to create merged PATH messages to be forwarded
                through the outgoing interfaces.

      Assuming that multicast routing
              reservation state.  At each hop, the IP destination
              address is free the unicast address of loops, PATH messages
      cannot loop even in a topology with cycles.

      Since PATH next-hop node.
              Routing is discussed below.

         RSVP error messages don't loop, they create path state defining a
      loop-free path to each sender.  Similarly, are triggered only by processing of PATH
         and RESV messages; errors encountered while processing error or
         teardown messages directed
      to particular senders cannot loop.  However, rules L1 and L2
      cannot protect against looping RESV messages that are directed
      towards all senders (WF or DF styles). must not create error messages.

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

                                       [ <INTEGRITY> ]  <ERROR_SPEC>

                                       <sender descriptor>

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

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

                                       [ <INTEGRITY> ]  <ERROR_SPEC>

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

         The following three rules
      are needed for this purpose.

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

           L4: detected the error, called the Error Node
         Address.

         When a PATH or RESV message is received, has been "packed" with multiple
         sets of elementary parameters, the Reverse Path
                Forwarding rule RSVP implementation should
         process each set independently and return a separate error
         message for each that is applied to the receiver address in
                the message; that is, the error.

         An error message must may be discarded
                unless it arrives duplicated and forwarded unchanged.  In
         general, error messages should be delivered to the applications
         on all the interface session nodes that is the preferred
                route (may have) contributed to the receiver.

           L5: this
         error.

         o    A RESV message whose RecvAddress matches one of the IP
                addresses of the local node must be discarded without
                processing.

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

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

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

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

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

      The loop-suppression rules for RESV messages also prevent looping

              In succeeding hops, the routing of RTEAR messages.  Note that RTEAR messages are otherwise subject
      to fast loops, since they are not delayed by a refresh timeout
      period.

      PERR messages are routed upstream by RERR message depends
              upon its style and upon routing.  In general, a RERR
              message is sent out some subset of the same rules used outgoing interfaces
              specified for FF multicast routing, using Error Node Address
              as the source address and DF RESV messages (there DestAddress as the destination.
              (This rule is no equivalent necessary to prevent packet loops; see
              Section 4.3 below).  Within this set of wildcard-filter
      for routing outgoing
              interfaces, a PERR message).  Similarly, RERR messages are routed
      by message is sent only to next hop(s)
              whose RESV message(s) created the rules for PATH messages.  For reasons explained above, no
      special loop-suppression rules are required in either case.

   3.3 Soft State Management

      The RSVP state associated with a session error; this in a particular node is
      divided into atomic elements turn
              depends upon the merging of flowspecs.  Assume that are created, refreshed, and
      timed out independently.  The atomicity a
              reservation whose error is determined being reported was formed by the
      requirement that any sender or receiver may enter or leave the
      session at any time,
              merging two flowspecs Q1 and its state Q2 from different next hops.

              -    If Q1 = Q2, the error message should be created and timed out
      independently.

      Management of RSVP state is complex because there is not generally
      a one-to-one correspondence between state carried in RSVP control
      messages and the resulting state in nodes.  Due forwarded to merging, a
      single
                   both next hops.

              -    If Q1 < Q2, the error message contain state referring to multiple stored
      elements.  Conversely, due should be forwarded
                   only to reservation sharing, a single stored
      state element may depend upon (typically, the maximum of) state
      values received in multiple control messages.

      3.3.1 Time Parameters

         For each element, there are two time parameters controlling the
         maintenance of soft state: the refresh period R next hop for Q2.

              -    If Q1 and Q2 are incomparable, the TTL
         (time-to-live) value T.  R specifies the period between
         successive refresh messages over the same link.  T controls how
         long state will error message
                   should be retained after refreshes stop appearing.

         PATH and RESV messages specify both R and T.  When messages are
         merged and forwarded to the both next hop, R hops, and the LUB
                   flag should be the minimum R
         that has been received, turned on.

              The ERROR_SPEC and T the LUB-flag should be delivered to the maximum T that has
         been received.   Thus,
              receiver application.  In the largest T determines how long state
         is retained, and case of an Admission Control
              error, the smallest R determines style-specific tail will contain the responsiveness
         of RSVP to route changes.  In FLOWSPEC
              object that failed.  If the first hop, they are expected
         to be equal.  The RSVP API LUB-flag is off, this should set a configurable default
         value, which can
              be overridden by an application for the same as a
         particular session.

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

         Let X indicate differ.

              An error in a particular message type (either "Path" or
         "Resv") and FILTER_SPEC object in a particular session.  Then each X RESV message from
         node a to node b carries refresh period Rab and TTL time Tab.

         o    As X messages arrive will
              normally be detected at node b, the node computes and
              saves both the min over the Rab values (min(Rab)) and the
              max over the Tab values (max(Tab)) first RSVP hop from these messages.

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

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

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

         o    A node may impose
              receiver application, i.e., within the receiver host.
              However, an upper bound Tmax and a lower bound
              Rmin, set admission control failure caused by configuration information, and enforce: Rmin
              <= R <= T <= Tmax.

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

      3.3.2 Teardown
              path(s) to the sender(s).

      4.1.6 Teardown messages, like other RSVP messages, Messages

         There are sent as
         datagrams and may be lost (although a QoS is used that should
         minimize the chances of congestive loss two types of RSVP messages).  To
         increase the reliability of teardown, Q copies of any given
         teardown message can be sent.  Note that if the iteration count
         Q on initiating teardown Teardown message, PTEAR and RTEAR.

         o    PTEAR messages is > 1, then the state cannot
         actually be deleted until Q teardowns have been sent.  The delete path state would be placed (which in a "moribund" status meanwhile.

         The appropriate value of Q is an engineering issue.  Q = 1
         would be the simplest and turn may be adequate, since unrefreshed
         state will time out anyway; teardown is an optimization.  Note delete
              reservations state) and travel towards all receivers that if one or more teardown hops
              are lost, downstream from the router that
         failed to receive a teardown message will time out its state point of initiation.  PTEAR
              messages are routed like PATH messages, and initiate a new teardown message beyond the loss point.
         Assuming that RSVP message loss probability their IP
              destination address is small (but non-
         zero), DestAddress for the longest time to session.

         o    RTEAR messages delete reservation state will seldom exceed one
         state timeout time K*Tab.

         Here is an example.  Here G1, G2, G3, and G4 travel towards
              all matching senders upstream from the point of teardown
              initiation.  RTEAR message are routers
         between a sender S routed like RESV messages,
              and their IP destination address is the unicast address of
              a receiver R.  S initiates previous hop.

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

                                         [ <INTEGRITY> ]

                                         <sender descriptor list>

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

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

                                         [ <INTEGRITY> ]  [ <CREDENTIAL> ]

                                         <style-specific tail>

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

         Flowspec objects in the style-specific tail of a PTEAR
         message (denoted by "PT"), but this RTEAR message is lost between
         routers G2
         will be ignored and G3.  Since G2 has deleted its may be omitted.

         If the state for S, G2
         will cease refreshing G3 (though G3 being deleted was created with user credentials
         from a CREDENTIAL field, then the matching PTEAR or RTEAR
         message must include matching CREDENTIAL field(s).

         [There is still refreshing G4,
         etc.)

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

         After a time K*Tab, G3's problem here: tearing down path state will time out, and G3 will
         initiate may
         implicitly delete reservation state.  But a teardown PTEAR message does
         not have credentials for S the reservation state, only for the
         path state:

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

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

      3.3.3 Local Repair

         To accommodate merging, RSVP uses hop-by-hop refreshing of
         state, where each node sends refreshes to its next/previous
         hops periodically.  However, as an optimization, local events
         could
         teardown messages, on the assumption that false teardown
         messages can be used to trigger injected only with the RSVP module to send such refreshes
         to any time.  For example, suppose collusion of routers
         along the data path, and in that case, the local routing
         protocol module were able to notify colluding router can
         just as well stop delivering the RESV messages, which will have
         the same effect.]

   4.2 Sending RSVP module that a
         route has changed for particular destinations.  The Messages

      RSVP module
         could use this information messages are sent hop-by-hop between RSVP-capable routers as
      "raw" IP datagrams, protocol number 46.  Raw IP datagrams are
      similarly intended to trigger be used between an immediate refresh of
         state for these destinations along end system and the new route.  This would
         allow fast adaptation
      first/last hop router; however, it is also possible to routing changes without the overhead encapsulate
      RSVP messages as UDP datagrams for end-system communication, as
      described in Appendix C.  UDP encapsulation will simplify
      installation of a short refresh period.

   3.4 Sending RSVP Messages on current end systems, particularly when
      firewalls are in use.

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

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

      The largest

      Since RSVP message is 556 bytes.

   3.5 Automatic Tunneling

      It is impractical messages are normally expected to deploy RSVP (or any protocol) at the same
      moment throughout the Internet, and RSVP may never be deployed
      everywhere.  RSVP must therefore provide correct protocol
      operation even when two RSVP-capable routers are joined by an
      arbitrary "cloud" of non-RSVP routers.

      RSVP will automatically tunnel through such a non-RSVP cloud.
      Both RSVP generated and non-RSVP routers forward PATH messages towards the
      destination address using sent
      hop-by-hop, their local uni-/multicast routing
      table.  Therefore, MTU should be determined by the routing MTU of  Path messages will each
      interface.

      [There may be
      unaffected by non-RSVP routers rare instances in the path.  When a PATH message
      traverses which this does not work very
      well, and in which manual configuration would not help.  The
      problem case is an interface connected to a non-RSVP cloud, the copies that emerge will carry as cloud in
      which some particular link far away has a
      Previous Hop address the IP address of the last RSVP-capable
      router before entering the cloud. smaller MTU.  This will cause effectively
      construct a tunnel through the cloud would
      affect only those sessions that happened to use that link.
      Proper solution to this case would require MTU discovery
      separately for RESV messages, each interface and each session, which will is a very
      large amount of machinery and some overhead for a rare (?) case.
      Best approach seems to be forwarded directly to the next RSVP-capable router rely on the
      path(s) back towards the source.

      This automatic tunneling capability of RSVP has a cost: a PATH
      message must carry the session DestAddress as its IP destination
      address; it cannot be addressed hop-by-hop.  As a result, each fragmentation and
      reassembly for this case.]

   4.3 Avoiding RSVP router Message Loops

      We must have a small change in its multicast ensure that the rules for forwarding
      path to recognize RSVP control messages (by the IP protocol number) and
      intercept them for local processing.  See Section 3.6.5 below.

      (There is a potential defect in tunneling.  Merged
      avoid looping.  In steady state, PATH and RESV messages
      can carry information for a list are
      forwarded on each hop only once per refresh period.  This avoids
      directly looping packets, but there is still the possibility of senders, and since multicast
      routing depends in general upon an
      " auto-refresh" loop, clocked by the sender, it refresh period.  The effect
      of such a loop is not possible to
      ensure that all keep state active "forever", even if the non-RSVP routers along end
      nodes have ceased refreshing it (but the tunnel state will be able
      to route deleted
      when the packet properly.  The effect turns out receivers leave the multicast group and/or the senders
      stop sending PATH messages).

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

      PATH messages are forwarded using routes determined by the
      appropriate routing protocol.  For routing that
      tunnels may distribute path information to is source-
      dependent (e.g., some multicast routing algorithms), the RSVP routers where it
      should not go, which may
      daemon must route each sender descriptor separately using the
      source addresses found in turn lead to unused reservations at
      these routers. the SENDER_TEMPLATE objects.  This is hoped to
      should ensure that there will be an acceptable defect.)

      Of course, if an intermediate cloud does not support RSVP, it is
      unable no auto-refresh loops of PATH
      information, even in a topology with cycles.

      Since PATH messages don't loop, they create path state defining a
      loop-free reverse path to perform resource reservation.  In this case, firm end-
      to-end service guarantees cannot be made.  However, if there is
      sufficient excess capacity through such each sender.  As a cloud, acceptable result, RESV and
      useful realtime service may still be possible.

   3.6 Interfaces

      3.6.1 Reservation Parameters

         All variable-length RSVP parameters use
      RTEAR messages directed to particular senders cannot loop.  PERR
      messages are always directed to particular senders and therefore
      cannot loop.  However, there is a potential auto-refresh problem
      for RESV, RTEAR, and RERR messages with wildcard scope, as we now
      discuss.

      If the same general
         format.  They begin topology has no loops, then auto-refresh can be avoided,
      even for wildcard scope, with the following rule:

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

      This rule is illustrated in Figure 10, which shows a length octet followed by transit
      router with one sender and one receiver on each interface (and
      assumes one next/previous hop per interface).  Interfaces a type
         octet, and occupy an integral number of fullwords.  The length
         octet specifies c
      are both outgoing and incoming interfaces for this session.  Both
      receivers are making wildcard-scope reservations, in which the total length
      RESV messages are forwarded to all previous hops for senders in
      the group, with the exception of the parameter next hop from which they
      came.  These result in independent reservation requests in fullwords
         or zero to indicate no parameter.  An RSVP implementation can
         store and pass such parameters as opaque objects.

         o    Flowspec Format

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

               +-----------+-----------+-----------+-----------+ two
      directions, without an auto-refresh loop.

                         ________________
                      a | FlowSLen=6|FlowSType=1|      VFoffset                |
               +-----------+-----------+-----------+-----------+ c
      ( R1, S1 ) <----->|     Router     |<-----> ( R2, S2 )
                        |________________|

        Send & Receive on (a)    |    QoS Type (Guaranteed, Predictive, ...)     Send & Receive on (c)
                                 |
               +-----------+-----------+-----------+-----------+
        WF( *{3B}) <-- (a)       |           Max end-to-end delay (ms)      (c) <-- WF( *{3B})
                                 |
               +-----------+-----------+-----------+-----------+
        WF( *{4B}) --> (a)       |           Average data rate (bits/ms)      (c) --> WF( *{4B})
                                 |
               +-----------+-----------+-----------+-----------+
                                 |           Token Bucket Depth (bits)           |
               +-----------+-----------+-----------+-----------+
               |           Global Share Handle
            Reserve on (a)       |
               +-----------+-----------+-----------+-----------+

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

         o    Filterspec Format

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

               +-----------+-----------+-----------+-----------+      Reserve on (c)
              __________         |  FiltSLen |FiltSType=1|      VFoffset        __________
             |
               +-----------+-----------+-----------+-----------+  * {4B}  |                Sender IP Address        |
               +-----------+-----------+-----------+-----------+  ---       |                   V: VF Value Part   * {3B} |   Nf
               /                                               / octets
               /                                               /
               +-----------+-----------+-----------+-----------+  ---
             |__________|        |                   M: VF Mask Part       |__________|
                                 |   Nf
               /                                               / octets
               /                                               /
               +-----------+-----------+-----------+-----------+  ---

              The value M and the mask V each have length:

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

              M and V define a filter that uses a mask-and-match
              algorithm applied

           Figure 10: Avoiding Auto-Refresh in Non-Looping Topology

      However, further effort is needed to the packet at VFoffset octets prevent auto-refresh loops
      from wildcard-scope reservations in the beginning presence of cycles in the IP header.  The minimum length
      topology.  [TBD!!].

      We treat routing of
              this format RERR messages as a special case.  They are
      sent with unicast addresses of sender template is 7 octets (FiltSLen = 2).

              A wildcard Filterspec, which will match any sender host,
              has zero for next hops, but the Sender IP Address [If VM part zero also,
              could shorten multicast
      routing is used to prevent loops.  As explained above, RERR
      messages are forwarded to FiltSLen = 2].

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

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

              o    The (V,M) part must not include either multicast tree to
      DestAddress, rooted at the sender or
                   receiver address of node on which the IP header; these are carried
                   explicitly.
              ISSUE:

                 There are many possible filter rules that error was discovered.
      Since multicast routing cannot be
                 expressed using a simple mask and value pair.  A
                 compact and general filter encoding is create loops, this will prevent
      loops for further
                 study.

         o    Authenticator Format

              The following simple form of authenticator is defined:

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

              The rules for merging RERR messages.

      [Open question about Figure 10: should it be possible to have
      incompatible reservation styles on the two interfaces?  For
      example, if R1 requests a WF reservation and interpreting this field require
              further study.

      3.6.2 Application/RSVP Interface

         This section describes R2 requests a generic API from an application FF
      reservation, it is logically possible to an
         RSVP control process. make the corresponding
      reservations on the two different interfaces.  The details current
      implementation does NOT allow this; instead, it prevents mixing of a real interface may be
         operating-system dependent;
      incompatible styles in the following can only suggest same session on a node, even if they
      are on different interfaces.]

   4.4 Local Repair

      Each RSVP daemon periodically sends refreshes to its next/previous
      hops.  An important optimization would allow the
         basic functions local routing
      protocol module to be performed.  Some notify the RSVP daemon of these calls cause route changes for
      particular destinations.  The RSVP daemon should use this
      information to be returned asynchronously.

         An application could directly send and receive RSVP messages,
         just as trigger an application can do file transfer immediate refresh of state for these
      destinations, using UDP.
         However, we envision that many applications will not want the new route.  This allows fast adaptation to
         know
      routing changes without the details overhead of RSVP operation, nor to provide a short refresh period.

   4.5 Time Parameters

      For each element of state, there are two time parameters: the timing
         services necessary to keep
      refresh period R and the time-to-live value T.  R specifies the
      period between sending successive refreshes of this data.  T
      controls how long state refreshed, any more than
         an application wants to handle TCP retransmission timeouts.
         Therefore, a host using RSVP may have an RSVP control process
         to handle these functions.  Using local IPC, applications will
         register or modify resource requests with this process be retained after refreshes stop
      appearing, and depends upon period between receiving successive
      refreshes.  Specifically, R <= T, and
         receive notifications of success or change of conditions.

         Register

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

              This call initiates RSVP processing for the session
              (DestAddress, ResvID). "cleanout time" is K *
      T.  Here K is a small integer; K-1 successive messages may be lost
      before state is deleted.  Currently K = 3 is suggested.

      Clearly, a smaller T means increased RSVP overhead.  If successful, the call returns
              immediately with router
      does not implement local repair, a smaller T improves the speed of
      adapting to routing changes.  With local session identifier "session-id",
              which may repair, a router can be used
      more relaxed about T, since the periodic refresh becomes only a
      backstop robustness mechanism.

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

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

      o    A router may adjust the value of T dynamically to keep a
           constant total overhead due to refresh traffic; as more
           sessions appear, the period would be lengthened.  In this
              call, an asynchronous ERROR or EVENT call (see below)
           case, R = T could be used.

      o    R and T can be specified by the end systems.  For this
           purpose, PATH and RESV messages may
              occur at any time.

              SND-flag contain the optional
           TIM_VALUES object.  When messages are merged and forwarded to
           the next hop, R should be set true if the host will send data, minimum R that has been
           received, and RCV-flag T should be set true if the host will receive
              data.  Setting neither true is an error. maximum T that has been
           received.   Thus, the largest T determines how long state is
           retained, and the smallest R determines the responsiveness of
           RSVP to route changes.  In the first hop, they are expected
           to be equal.  The RSVP API might allow an application to
           override the default value for a particular session.

   4.6 RSVP Interfaces

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

      4.6.1 Application/RSVP Interface

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

         o    Register

              Call: REGISTER( DestAddress , DestPort

                         [ , SESSION_object ]  , SND_flag , RCV_flag

                         [ , Source_Address ]  [ , Source_Port ]

                         [ , Sender_Template ]  [ , Sender_Tspec ]

                         [ , Data_TTL ]  [ , UserCredential ]

                         [ , Upcall_Proc_addr ] )  -> Session-id

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

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

              SND_flag should be set true if the host will send data,
              and RCV_flag should be set true if the host will receive
              data.  Setting neither true is an error.  The optional
              parameters Source_Address, Source_Port, Sender_Template,
              Sender_Tspec, and Data_TTL are all concerned with a data
              source, and they will be ignored unless SND_flag is true.

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

              -    Source_Address

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

              -    Source_Port

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

              -    Sender_Template

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

              -    Sender_Tspec

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

              -    Data_TTL

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

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

         o    Reserve

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

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

              The RESERVE call returns immediately.  Following a RESERVE
              call, an asynchronous ERROR/EVENT upcall may occur at any
              time.

         o    Release

              Call: RELEASE( session-id )

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

         o    Error/Event Upcalls

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

                            [ ,Error_code ,Error_value ,LUB-flag ]

                            [ ,Filter_spec_list ]  [ ,Flowspec_list ]

                            [ ,Advert_list ] )

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

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

              1.   Info_type = Path Event

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

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

              2.   Info_type = Path Error

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

              3.   Info_type = Resv Error

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

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

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

      4.6.2 RSVP/Traffic Control Interface

         In each router and host, enhanced QoS is achieved by a group of
         inter-related traffic control functions:  a packet classifier,
         an admission control module, and a packet scheduler.  This
         section describes a generic RSVP interface to traffic control.

         1.   Make a Reservation

              Call: Rhandle =  TC_AddFlowspec( Flowspec, Police_Flag

                                     [ , Sender_Tspec]

                                     [ , SD_rank , SD_end_flag ] )

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

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

              This call returns an error code if Flowspec is malformed
              or if the requested resources are unavailable.  Otherwise,
              it establishes a new reservation channel corresponding to
              Rhandle.  It returns the opaque number Rhandle for
              subsequent references to this reservation.

         2.   Add Filter

              Call: TC_AddFilter( Rhandle, Session, Filterspec )

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

         3.   Modify or Delete Filter

              Call: TC_ModFilter( Rhandle, Session,

                                             [ new_Filterspec] )

              This call can modify an existing filter or replace an
              existing filter with no filter (i.e., delete the filter).

         4.   Modify or Delete Flowspec

              Call: TC_ModFlowspec( Rhandle

                             [, new_Flowspec [ ,Sender_Tspec]] )

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

         5.   OPWA Update

              Call: TC_Advertise( interface, Adspec

                              [ ,Sender_TSpec ] ) -> New_Adspec

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

         6.   Initialize Traffic Control

              Call: TC_Initialize(interface )

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

      4.6.3 RSVP/Routing Interface

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

         o    Promiscuous receive mode for RSVP messages

              Any datagram received for IP protocol 46 is to be diverted
              to the RSVP program for processing, without being
              forwarded.  The identity of the interface on which it is
              received should also be available to the RSVP daemon.

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

                 GetUcastRoute( DestAddress ) -> OutInterface

                 GetMcastRoute( SrcAddress, DestAddress )

                                              -> OutInterface_list

         o    Route Change Notification

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

                 New_Ucast_Route( DestAddress ) -> new_OutInterface

                 New_Mcast_Route( SrcAddress, DestAddress )

                                                -> new_OutInterface_list

         o    Outgoing Link Specification

              RSVP must be able to force a (multicast) datagram to be
              sent on a specific outgoing virtual link, bypassing the
              normal routing mechanism.  A virtual link may be a real
              outgoing link or a multicast tunnel.  Outgoing link
              specification is necessary because RSVP may send different
              versions of outgoing PATH messages on different
              interfaces, for the same source and destination addresses,
              and to avoid loops.

         o    Discover Interface List

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

5. Message Processing Rules

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

   o    PSB -- Path State Block

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

   o    RSB -- Reservation State Block

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

   MESSAGE ARRIVES

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

   Further processing depends upon message type.

   PATH MESSAGE ARRIVES

        Start with the Refresh_Needed flag off.

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

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

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

             o    Create a new PSB.

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

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

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

        3.   Otherwise (there is a matching PSB):

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

             o    Restart cleanup timer.

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

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

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

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

   PATH TEAR MESSAGE ARRIVES

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

        o    Forward a copy of the PTEAR message using the same rules as
             for a PATH message (see PATH REFRESH).

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

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

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

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

                  Delete an FF reservation for S.

             3.   Delete the PSB.

   PATH ERROR MESSAGE ARRIVES

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

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

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

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

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

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

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

        o    Check the SESSION object.

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

        o    Check the STYLE object.

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

        o    Check the CREDENTIAL object.

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

        o    Check for path state

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

        o    Make reservations

             Process the style-specific tail sequence.

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

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

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

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

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

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

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

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

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

                     TC_AddFlowspec( Sender_Tspec, K_flowspec, Police_Flag )

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

                     TC_AddFilter( K_handle, K_Filter)

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

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

                     TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec)

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

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

        created

   RESV TEAR MESSAGE ARRIVES

        A RTEAR message arrives on outgoing interface OI.

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

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

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

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

             2.   Delete the RSB(s).

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

                     TC_ModFlowspec( K_handle )

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

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

                  -    FF style: Send to PHOP of matching PSB.

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

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

   RESV ERROR MESSAGE ARRIVES

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

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

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

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

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

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

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

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

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

   PATH REFRESH

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

   For each virtual outgoing interface ("vif") V, build a PATH message
   and send it to V.  To build the message, consider each PSB whose
   ROUTE_MASK includes V, and do the following:

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

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

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

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

   RESV REFRESH

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

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

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

   o    Compute (FLOWSPEC, FILTER_SPEC) Pair

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

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

             In this case, FILTER_SPEC is the standard WILD_FILTER.

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

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

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

   o    Build RESV packets

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

   appendix
6. Object Type Definitions

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

   6.1 SESSION Class

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

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

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

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

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

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

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

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

           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +               IP6 Reference DestAddress               +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
           |      Session-Group ID     |    Count    |     Rank    |
           +-------------+-------------+-------------+-------------+
   6.3 RSVP_HOP Class

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

           +-------------+-------------+-------------+-------------+
           |             IPv4 Next/Previous Hop Address            |
           +-------------+-------------+-------------+-------------+
      o    IP6 RSVP_HOP object: Class = 3, C-Type = 129

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

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

   6.4 STYLE Class

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

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

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

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

           FD Count

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

   6.5 Flowspec Class

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

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

           QoS Service Code

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

                1 = Guaranteed Service

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

                2 = Bounded-Delay Predictive Service

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

   6.6 FILTER_SPEC Class

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

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

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

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

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

   6.7 SENDER_TEMPLATE Class

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

           Definition same as IPv4/UDP FILTER_SPEC object.

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

           Definition same as IP6/UDP FILTER_SPEC object.

   6.8 SENDER_TSPEC Class

      The most common form of Tspec is a token bucket.

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

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

      [TBD]

   6.10 TIME_VALUES Class

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

           +-------------+-------------+-------------+-------------+
           |                    Refresh Period                     |
           +-------------+-------------+-------------+-------------+
           |                    State TTL Time                     |
           +-------------+-------------+-------------+-------------+
   6.11 ERROR_SPEC Class

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

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

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

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

      Errnor Node

           The IP address

      Error Code

           A one-octet error description.

                01 = Insufficient memory

                02 = Count Wrong

                     The optional
              parameters DROP-flag, rsvpTTL, SenderTemplate, and
              Flowspec should be supplied only if SND-flag is true.

              DROP-flag indicates that session data packets that do FD Count field does not match any active filter length of
                     message.

                03 = No path information for this Resv

                04 = No Sender information for this Resv
                     There is path information, but it does not include
                     the sender specified in some node should be dropped at
              that node; otherwise, such packets will be forwarded using
              a best-effort QoS.  The rsvp-TTL parameter specifies any of the
              IP Time-to-Live field that will be used Filterspecs
                     listed in PATH messages.
              The the Resv messager.

                05 = Incorrect Dynamic Reservation Count

                     Dynamic Reservation Count is zero or less than FD
                     Count.

                06 = Filterspec error

                07 = Flowspec syntax error

                08 = Flowspec value error

                     Internal inconsistency of rsvp-TTL values.

                     [What should match the TTL field to be
              sent in data packets, so they will have the same multicast
              scope.

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

         Reserve

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

              A receiver uses this call to make a resource reservation
              for the session registered as `session-id'.  The Flowspec Feature Not
                     Supported?]

                09 = Resources unavailable [Sub-reasons?  Depend upon
                     traffic control and admission control algorithms?]

                10 = Illegal style
              parameter is an integer index indicating

      Error Value

           Specific cause of the reservation
              style.  The DF-chan-count parameter, indicating error described by the number
              of Dynamic Filter channels Error Code.

   6.12 CREDENTIAL Class

      [TBD]

   6.13 INTEGRITY Class

      [TBD]

7. UDP Encapsulation

   As described earlier, RSVP control messages are intended to be reserved, should only be
              included if the style is DF.

              The first RESERVE call
   carried as "raw packets", directly within IP datagrams.  Implementing
   RSVP in a node will initiate typically require an intercept in the periodic
              transmission packet
   forwarding path for protocol 46, which means a kernel change.
   However, for ease of RESV messages.  A later RESERVE call installing RSVP on host systems in the short
   term, it may be given desirable to modify the parameters avoid host kernel changes by supporting
   UDP encapsulation of RSVP messages.  This encapsulation would be used
   between hosts and the earlier call (but
              note that changing the reservations may result in
              admission control failure, depending upon the style).

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

         Release

              Call: RELEASE( session-id ) last- (or first-) hop router(s).  This call scheme
   will terminate also support the case of an intermediate RSVP state for router whose
   kernel supports multicast but does not have the session
              specified RSVP intercept, by session-id.  It will send appropriate
              "Teardown" messages and cease sending refreshes.

         Error Upcall

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

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

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

         Event Upcall

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

              This upcall may occur asynchronously at any time after contains a
              REGISTER call
   mix of "UDP-only" hosts, which require UDP encapsulation, and before "raw-
   capable" host, which can use raw RSVP packets.  Raw-capable hosts and
   first-hop router(s) must send each RSVP message twice in the local
   domain, once as a RELEASE call, to signal an
              event raw packet and to pass information once with UDP encapsulation; these
   nodes will also receive some local RSVP packets in both formats.  We
   assume that the only negative impact of this duplication will be
   (negligible) additional packet processing overhead in the raw-capable
   hosts and first-hop routers.

   [REST TBD]

8. DF Style (Experimental)

   In addition to the application. WF and FF styles defined in this specification, a
   Dynamic Filter (DF) style has also been proposed.  The `info-type' field indicates one following
   describes this style and gives examples of two possible event
              types. its usage.  At this time,
   DF style is experimental.

   8.1 Reservation Styles

      A Path event indicates the receipt of Dynamic-Filter (DF) style reservation decouples reservations
      from filters.

      Each DF reservation request specifies a PATH
              message, indicating number D of distinct
      reservations to be made using the application same specified flowspec, and
      these reservations have a wildcard reservation scope, so they go
      everywhere.  The number of reservations that there are actually made in
      a particular node is D' = min(D,Ns), where Ns is at
              least one active sender.  A Reservation event indicates the receipt total number
      of senders upstream of the node.  Like a RESV message, indicating FF style request, a DF
      style request causes distinct reservations for different senders.

      In addition to D and the
              application that there is at least one receiver.  Although
              these messages are repeatedly received, the API should
              make flowspec, a DF style reservation may also
      specify a list of K filterspecs, for some K in the corresponding asynchronous upcall range: 0 <= K
      <= D'.  These filterspecs define particular senders to use the
              application only on D'
      reservations, and this list establishes the first event, or when scope for the filter
      specs.

      Once a DF reservation has been established, the
              information to be reported changes.

              ISSUE:

                 The precise form and function of receiver may
      change the flowspec-list and
                 filterspec-list parameters are set of filterspecs to be determined.

      3.6.3 RSVP/Traffic Control Interface

         In each router and host, enhanced QoS is achieved by specify a group different selection of
         inter-related functions:
      senders, without a packet Classifier, an new admission control module, check (assuming D' and a packet scheduler.  We group these
         functions together under the heading traffic control.  RSVP
         uses
      the interfaces common flowspec remain unchanged).  This is known as "channel
      switching", in this section analogy with a television set.

      In order to invoke provide assured channel switching, each node along the traffic
         control functions.

         1.   Make a Reservation

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

              Returns an internal handle Rhandle
      path must reserve enough bandwidth for subsequent
              references to all D' channels, even
      though some of this reservation.

              This call passes Flowspec to admission control and returns
              an error code if Flowspec is malformed bandwidth may be unused at any one time.  If
      D' changes (because the receiver changed D or because the number
      Ns of upstream sources changed), or if the requested
              resources are unavailable.  Otherwise, it establishes common flowspec
      changes, the refresh message is treated as a new reservation channel corresponding that
      is subject to Rhandle, admission control and if
              Filterspecs are supplied, installs may fail.

      The essential difference between the FF and DF styles is that the
      DF style allows a corresponding filter receiver to switch channels without danger of an
      admission denial due to limited resources (unless a topology
      change reroutes traffic along a lower-capacity path or new senders
      appear), once the initial reservations have been made.  This in
      turn implies that the DF style creates reservations that may not
      be in use at any given time.

      The DF style is compatible with the classifier.

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

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

   8.2 Examples

      To give an example of those calls have null filterspecs.

         2.   Switch a Channel

              Call: TCModFilter( Rhandle, [new Filterspec]) the DF style, we use the following notation:

      o    DF Style

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

      This call replaces message carries the filter without calling admission
              control. count n of channels to be reserved, each
      using common flowspec r.  It may replace also carries a list, perhaps empty,
      of filterspecs defining senders.

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

         3.   Modify Flowspec

              Call: TCModFlowspec( Rhandle, oldFlowspec, newFlowspec)

              Here newFlowspec may be larger `?'.

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

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

             Figure 11: Dynamic-Filter Reservation Example

      A router should not reserve more Dynamic-Filter channels than
              oldFlowspec.

         4.   Delete Flow

              Call:  TCDeleteFlow( Rhandle )

              This call kills the reservation and reduces the reference
              count of, and deletes if
      number of upstream sources (three, in the count is zero, any filter
              associated with this handle.

         5.   Initialize

              Call: TCInitialize( )

              This call router of Figure 11).
      Since there is used when RSVP initializes its state, to
              clear out all existing classifier and/or packet scheduler
              state.

      3.6.4 RSVP/Routing Interface

         An RSVP implementation needs the following support only one source upstream from previous hop (a), the
         packet forwarding and routing mechanism
      first parameter of the node.

         o    Promiscuous receive mode for RSVP messages

              Any datagram received for IP protocol 46 is to be diverted DF message (the count of channels to the RSVP program for processing, without being
              forwarded.

         o    Route discovery

              RSVP must be able
      reserved) was decreased to discover 1 in the route(s) that forwarded reservations.
      However, this is unnecessary, because the
              routing algorithm would have used for forwarding a
              specific datagram.

              GetUCRoute( DestAddress ) -> NextHop, Interface

              GetMCRoute( SrcAddress, DestAddress ) -> Interface

         o    Outgoing Link Specification

              RSVP must be able to force a (multicast) datagram to be
              sent on routers upstream will
      reserve only one channel, regardless.

      When a specific outgoing virtual link, bypassing DF reservation is received, it is labeled with the IP
      address of the next hop (RSVP-capable) router, downstream from the
              normal routing mechanism.  A virtual link
      current node.  Since the outgoing interface may be directly
      connected to a real
              outgoing link shared medium network or to a multicast tunnel.

              This is necessary because RSVP non-RSVP-capable
      router, there may send different versions
              of outgoing PATH be more than one next-hop node downstream; if
      so, each sends independent DF RESV messages on different interfaces, for a given session.
      The number N' of DF channels reserved on an outgoing interface is
      given by the
              same source and destination addresses.

         o    Discover (Virtual) Interface List formula:

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

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

      For a DF reservation request with a Dynamic Reservation Count = C,
      RSVP must be able to learn what real and virtual
              interfaces exist.

4. ACKNOWLEDGMENTS

   Lixia Zhang, Scott Shenker, Deborah Estrin, Dave Clark, Sugih Jamin,
   Shai Herzog, Steve Berson, Steve Deering, Bob Braden, and Daniel
   Zappala have all made contributions to should call TC_AddFlowspec C times.

   8.3 Resv Messages

      Add the design following sequence:

          <style-specific-tail> ::=

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

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

   8.4 STYLE Class

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

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

           Style

                3 = Dynamic-Filter

           Dyn Resv Count

                The number of RSVP.  We are
   grateful channels to Jamin, Herzog, and Berson for prototype implementations.
   The original protocol concepts be reserved for RSVP arose out of discussions in
   meetings of the End-to-End Research Group. a Dynamic
                Filter style reservation.  This integer value must not
                less than FD Count.

REFERENCES

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

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

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

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

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

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

Security Considerations

   As noted in

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

Authors' Addresses

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

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

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

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

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

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

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

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

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

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