GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2205

Network Working Group R. Braden, Ed. Request for Comments: 2205 ISI Category: Standards Track L. Zhang

                                                                UCLA
                                                           S. Berson
                                                                 ISI
                                                           S. Herzog
                                                        IBM Research
                                                            S. Jamin
                                                   Univ. of Michigan
                                                      September 1997
              Resource ReSerVation Protocol (RSVP) --
                 Version 1 Functional Specification

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Abstract

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

Braden, Ed., et. al. Standards Track [Page 1] RFC 2205 RSVP September 1997

Table of Contents

 1. Introduction ................................................... 4
    1.1 Data Flows ................................................. 7
    1.2 Reservation Model .......................................... 8
    1.3 Reservation Styles .........................................11
    1.4 Examples of Styles .........................................14
 2. RSVP Protocol Mechanisms .......................................19
    2.1 RSVP Messages ..............................................19
    2.2 Merging Flowspecs ..........................................21
    2.3 Soft State .................................................22
    2.4 Teardown ...................................................24
    2.5 Errors .....................................................25
    2.6 Confirmation ...............................................27
    2.7 Policy Control .............................................27
    2.8 Security ...................................................28
    2.9 Non-RSVP Clouds ............................................29
    2.10 Host Model ................................................30
 3. RSVP Functional Specification ..................................32
    3.1 RSVP Message Formats .......................................32
    3.2 Port Usage .................................................47
    3.3 Sending RSVP Messages ......................................48
    3.4 Avoiding RSVP Message Loops ................................50
    3.5 Blockade State .............................................54
    3.6 Local Repair ...............................................56
    3.7 Time Parameters ............................................57
    3.8 Traffic Policing and Non-Integrated Service Hops ...........58
    3.9 Multihomed Hosts ...........................................59
    3.10 Future Compatibility ......................................61
    3.11 RSVP Interfaces ...........................................63
 4. Acknowledgments ................................................76
 APPENDIX A. Object Definitions ....................................77
 APPENDIX B. Error Codes and Values ................................92
 APPENDIX C. UDP Encapsulation .....................................98
 APPENDIX D. Glossary .............................................102
 REFERENCES .......................................................111
 SECURITY CONSIDERATIONS ..........................................111
 AUTHORS' ADDRESSES ...............................................112

Braden, Ed., et. al. Standards Track [Page 2] RFC 2205 RSVP September 1997

 What's Changed
 This revision contains the following very minor changes from the ID14
 version.
    o    For clarity, each message type is now defined separately in
         Section 3.1.
    o    We added more precise and complete rules for accepting Path
         messages for unicast and multicast destinations (Section
         3.1.3).
    o    We added more precise and complete rules for processing and
         forwarding PathTear messages (Section 3.1.5).
    o    A note was added that a SCOPE object will be ignored if it
         appears in a ResvTear message (Section 3.1.6).
    o    A note was added that a SENDER_TSPEC or ADSPEC object will be
         ignored if it appears in a PathTear message (Section 3.1.5).
    o    The obsolete error code Ambiguous Filter Spec (09) was
         removed, and a new (and more consistent) name was given to
         error code 08 (Appendix B).
    o    In the generic interface to traffic control, the Adspec was
         added as a parameter to the AddFlow and ModFlow calls
         (3.11.2).  This is needed to accommodate a node that updates
         the slack term (S) of Guaranteed service.
    o    An error subtype was added for an Adspec error (Appendix B).
    o    Additional explanation was added for handling a CONFIRM
         object (Section 3.1.4).
    o    The rules for forwarding objects with unknown class type were
         clarified.
    o    Additional discussion was added to the Introduction and to
         Section 3.11.2 about the relationship of RSVP to the link
         layer.  (Section 3.10).
    o    Section 2.7 on Policy and Security was split into two
         sections, and some additional discussion of security was
         included.
    o    There were some minor editorial improvements.

Braden, Ed., et. al. Standards Track [Page 3] RFC 2205 RSVP September 1997

1. Introduction

 This document defines RSVP, a resource reservation setup protocol
 designed for an integrated services Internet [RSVP93, RFC 1633].  The
 RSVP protocol is used by a host to request specific qualities of
 service from the network for particular application data streams or
 flows.  RSVP is also used by routers to deliver quality-of-service
 (QoS) requests to all nodes along the path(s) of the flows and to
 establish and maintain state to provide the requested service.  RSVP
 requests will generally result in resources being reserved in each
 node along the data path.
 RSVP requests resources for simplex flows, i.e., it requests
 resources in only one direction.  Therefore, RSVP treats a sender as
 logically distinct from a receiver, although the same application
 process may act as both a sender and a receiver at the same time.
 RSVP operates on top of IPv4 or IPv6, occupying the place of a
 transport protocol in the protocol stack.  However, RSVP does not
 transport application data but is rather an Internet control
 protocol, like ICMP, IGMP, or routing protocols.  Like the
 implementations of routing and management protocols, an
 implementation of RSVP will typically execute in the background, not
 in the data forwarding path, as shown in Figure 1.
 RSVP is not itself a routing protocol; RSVP is designed to operate
 with current and future unicast and multicast routing protocols.  An
 RSVP process consults the local routing database(s) to obtain routes.
 In the multicast case, for example, a host sends IGMP messages to
 join a multicast group and then sends RSVP messages to reserve
 resources along the delivery path(s) of that group.  Routing
 protocols determine where packets get forwarded; RSVP is only
 concerned with the QoS of those packets that are forwarded in
 accordance with routing.
 In order to efficiently accommodate large groups, dynamic group
 membership, and heterogeneous receiver requirements, RSVP makes
 receivers responsible for requesting a specific QoS [RSVP93].  A QoS
 request from a receiver host application is passed to the local RSVP
 process.  The RSVP protocol then carries the request to all the nodes
 (routers and hosts) along the reverse data path(s) to the data
 source(s), but only as far as the router where the receiver's data
 path joins the multicast distribution tree.  As a result, RSVP's
 reservation overhead is in general logarithmic rather than linear in
 the number of receivers.

Braden, Ed., et. al. Standards Track [Page 4] RFC 2205 RSVP September 1997

            HOST                              ROUTER

_

_ | | | | | | _ _ | | |Appli- | | | |RSVP | | | | | | cation| | RSVP ←————————–> RSVP ←———> | | ←→ | | | _
process _ Routing process _
_._ –>Polcy ←→ –>Polcy
.._ Cntrl process .._ Cntrl
data _ .| | | |_|| |===|===========|==|==========| |===|==========|==|==========| | | ——–| | _ | | | ——–| | _ | | | | | —→Admis|| | | | | —→Admis|| | _VV_ _V |Cntrl|| | _VV_ V_ |Cntrl|| | | | | | |_|| | | | | ||_|| | |Class-| | Packet | | | |Class-| | Packet | | | | ifier|=⇒Schedulr|===============⇒ ifier|=⇒Schedulr|==========⇒ | | data | || |data | | | | |_| || Figure 1: RSVP in Hosts and Routers Quality of service is implemented for a particular data flow by mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group. During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control Braden, Ed., et. al. Standards Track [Page 5] RFC 2205 RSVP September 1997 determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development. Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted. In summary, RSVP has the following attributes: o RSVP makes resource reservations for both unicast and many-to- many multicast applications, adapting dynamically to changing group membership as well as to changing routes. o RSVP is simplex, i.e., it makes reservations for unidirectional data flows. o RSVP is receiver-oriented, i.e., the receiver of a data flow initiates and maintains the resource reservation used for that flow. o RSVP maintains "soft" state in routers and hosts, providing graceful support for dynamic membership changes and automatic adaptation to routing changes. o RSVP is not a routing protocol but depends upon present and future routing protocols. o RSVP transports and maintains traffic control and policy control parameters that are opaque to RSVP. Braden, Ed., et. al. Standards Track [Page 6] RFC 2205 RSVP September 1997 o RSVP provides several reservation models or "styles" (defined below) to fit a variety of applications. o RSVP provides transparent operation through routers that do not support it. o RSVP supports both IPv4 and IPv6. Further discussion on the objectives and general justification for RSVP design are presented in [RSVP93] and [RFC 1633]. The remainder of this section describes the RSVP reservation services. Section 2 presents an overview of the RSVP protocol mechanisms. Section 3 contains the functional specification of RSVP, while Section 4 presents explicit message processing rules. Appendix A defines the variable-length typed data objects used in the RSVP protocol. Appendix B defines error codes and values. Appendix C defines a UDP encapsulation of RSVP messages, for hosts whose operating systems provide inadequate raw network I/O support. 1.1 Data Flows RSVP defines a "session" to be a data flow with a particular destination and transport-layer protocol. RSVP treats each session independently, and this document often omits the implied qualification "for the same session". An RSVP session is defined by the triple: (DestAddress, ProtocolId [, DstPort]). Here DestAddress, the IP destination address of the data packets, may be a unicast or multicast address. ProtocolId is the IP protocol ID. The optional DstPort parameter is a "generalized destination port", i.e., some further demultiplexing point in the transport or application protocol layer. DstPort could be defined by a UDP/TCP destination port field, by an equivalent field in another transport protocol, or by some application-specific information. Although the RSVP protocol is designed to be easily extensible for greater generality, the basic protocol documented here supports only UDP/TCP ports as generalized ports. Note that it is not strictly necessary to include DstPort in the session definition when DestAddress is multicast, since different sessions can always have different multicast addresses. However, DstPort is necessary to allow more than one unicast session addressed to the same receiver host. Braden, Ed., et. al. Standards Track [Page 7] RFC 2205 RSVP September 1997 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 multicast routing. Multicast distribution forwards a copy of each data packet from a sender Si to every receiver Rj; a unicast distribution session has a single receiver R. Each sender Si may be running in a unique Internet host, or a single host may contain multiple senders distinguished by "generalized source ports". Senders Receivers _ ( ) ==⇒ R1 S1 ==⇒ ( Multicast ) ( ) ==⇒ R2 ( distribution ) S2 ==⇒ ( ) ( by Internet ) ==⇒ R3 (_) Figure 2: Multicast Distribution Session For unicast transmission, there will be a single destination host but there may be multiple senders; RSVP can set up reservations for multipoint-to-single-point transmission. 1.2 Reservation Model An elementary RSVP reservation request consists of a "flowspec" together with a "filter spec"; this pair is called a "flow descriptor". The flowspec specifies a desired QoS. The filter spec, together with a session specification, defines the set of data packets – the "flow" – to receive the QoS defined by the flowspec. The flowspec is used to set parameters in the node's packet scheduler or other link layer mechanism, while the filter spec is used to set parameters in the packet classifier. Data packets that are addressed to a particular session but do not match any of the filter specs for that session are handled as best-effort traffic. The flowspec in a reservation request will generally include a service class and two sets of numeric parameters: (1) an "Rspec" (R for `reserve') that defines the desired QoS, and (2) a "Tspec" (T for `traffic') that describes the data flow. The formats and contents of Tspecs and Rspecs are determined by the integrated service models [RFC 2210] and are generally opaque to RSVP. Braden, Ed., et. al. Standards Track [Page 8] RFC 2205 RSVP September 1997 The exact format of a filter spec depends upon whether IPv4 or IPv6 is in use; see Appendix A. In the most general approach [RSVP93], filter specs may select arbitrary subsets of the packets in a given session. Such subsets might be defined in terms of senders (i.e., sender IP address and generalized source port), in terms of a higher-level protocol, or generally in terms of any fields in any protocol headers in the packet. For example, filter specs might be used to select different subflows of a hierarchically-encoded video stream by selecting on fields in an application-layer header. In the interest of simplicity (and to minimize layer violation), the basic filter spec format defined in the present RSVP specification has a very restricted form: sender IP address and optionally the UDP/TCP port number SrcPort. Because the UDP/TCP port numbers are used for packet classification, each router must be able to examine these fields. This raises three potential problems. 1. It is necessary to avoid IP fragmentation of a data flow for which a resource reservation is desired. Document [RFC 2210] specifies a procedure for applications using RSVP facilities to compute the minimum MTU over a multicast tree and return the result to the senders. 2. IPv6 inserts a variable number of variable-length Internet- layer headers before the transport header, increasing the difficulty and cost of packet classification for QoS. Efficient classification of IPv6 data packets could be obtained using the Flow Label field of the IPv6 header. The details will be provided in the future. 3. IP-level Security, under either IPv4 or IPv6, may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers. A small extension to RSVP for IP Security under IPv4 and IPv6 is described separately in [RFC 2207]. RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Note: in this document, we define the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flow. Braden, Ed., et. al. Standards Track [Page 9] RFC 2205 RSVP September 1997 At each intermediate node, a reservation request triggers two general actions, as follows: 1. Make a reservation on a link The RSVP process passes the request to admission control and policy control. If either test fails, the reservation is rejected and the RSVP process returns an error message to the appropriate receiver(s). If both succeed, the node sets the packet classifier to select the data packets defined by the filter spec, and it interacts with the appropriate link layer to obtain the desired QoS defined by the flowspec. The detailed rules for satisfying an RSVP QoS request depend upon the particular link layer technology in use on each interface. Specifications are under development in the ISSLL Working Group for mapping reservation requests into popular link layer technologies. For a simple leased line, the desired QoS will be obtained from the packet scheduler in the link layer driver, for example. If the link-layer technology implements its own QoS management capability, then RSVP must negotiate with the link layer to obtain the requested QoS. Note that the action to control QoS occurs at the place where the data enters the link-layer medium, i.e., at the upstream end of the logical or physical link, although an RSVP reservation request originates from receiver(s) downstream. 2. Forward the request upstream A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be " merged" as reservations travel upstream. When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. A successful reservation request propagates upstream along the multicast tree until it reaches a point where an existing reservation is equal or greater Braden, Ed., et. al. Standards Track [Page 10] RFC 2205 RSVP September 1997 than that being requested. At that point, the arriving request is merged with the reservation in place and need not be forwarded further; the node may then send a reservation confirmation message back to the receiver. Note that the receipt of a confirmation is only a high-probability indication, not a guarantee, that the requested service is in place all the way to the sender(s), as explained in Section 2.6. The basic RSVP reservation model is "one pass": a receiver sends a reservation request upstream, and each node in the path either accepts or rejects the request. This scheme provides no easy way for a receiver to find out the resulting end-to-end service. Therefore, RSVP supports an enhancement to one-pass service known as "One Pass With Advertising" (OPWA) [OPWA95]. With OPWA, RSVP control packets are sent downstream, following the data paths, to gather information that may be used to predict the end-to-end QoS. The results ("advertisements") are delivered by RSVP to the receiver hosts and perhaps to the receiver applications. The advertisements may then be used by the receiver to construct, or to dynamically adjust, an appropriate reservation request. 1.3 Reservation Styles A reservation request includes a set of options that are collectively called the reservation "style". One reservation option concerns the treatment of reservations for different senders within the same session: establish a "distinct" reservation for each upstream sender, or else make a single reservation that is "shared" among all packets of selected senders. Another reservation option controls the selection of senders; it may be an "explicit" list of all selected senders, or a "wildcard" that implicitly selects all the senders to the session. In an explicit sender-selection reservation, each filter spec must match exactly one sender, while in a wildcard sender-selection no filter spec is needed. Braden, Ed., et. al. Standards Track [Page 11] RFC 2205 RSVP September 1997 Sender || Reservations: Selection || Distinct | Shared _||
               Figure 3: Reservation Attributes and Styles
    The following styles are currently defined (see Figure 3):
    o    Wildcard-Filter (WF) Style
         The WF style implies the options: "shared" reservation and
         "wildcard" sender selection.  Thus, a WF-style reservation
         creates a single reservation shared by flows from all
         upstream senders.  This reservation may be thought of as a
         shared "pipe", whose "size" is the largest of the resource
         requests from all receivers, independent of the number of
         senders using it.  A WF-style reservation is propagated
         upstream towards all sender hosts, and it automatically
         extends to new senders as they appear.
         Symbolically, we can represent a WF-style reservation request
         by:
             WF( * {Q})
         where the asterisk represents wildcard sender selection and Q
         represents the flowspec.
    o    Fixed-Filter (FF) Style
         The FF style implies the options: "distinct" reservations and
         "explicit" sender selection.  Thus, an elementary FF-style
         reservation request creates a distinct reservation for data
         packets from a particular sender, not sharing them with other
         senders' packets for the same session.

Braden, Ed., et. al. Standards Track [Page 12] RFC 2205 RSVP September 1997

         Symbolically, we can represent an elementary FF reservation
         request by:
             FF( S{Q})
         where S is the selected sender and Q is the corresponding
         flowspec; the pair forms a flow descriptor.  RSVP allows
         multiple elementary FF-style reservations to be requested at
         the same time, using a list of flow descriptors:
             FF( S1{Q1}, S2{Q2}, ...)
         The total reservation on a link for a given session is the
         `sum' of Q1, Q2, ... for all requested senders.
    o    Shared Explicit (SE) Style
         The SE style implies the options: "shared" reservation and
         "explicit" sender selection.  Thus, an SE-style reservation
         creates a single reservation shared by selected upstream
         senders.  Unlike the WF style, the SE style allows a receiver
         to explicitly specify the set of senders to be included.
         We can represent an SE reservation request containing a
         flowspec Q and a list of senders S1, S2, ... by:
             SE( (S1,S2,...){Q} )
    Shared reservations, created by WF and SE styles, are appropriate
    for those multicast applications in which multiple data sources
    are unlikely to transmit simultaneously.  Packetized audio is an
    example of an application suitable for shared reservations; since
    a limited number of people talk at once, each receiver might issue
    a WF or SE reservation request for twice the bandwidth required
    for one sender (to allow some over-speaking).  On the other hand,
    the FF style, which creates distinct reservations for the flows
    from different senders, is appropriate for video signals.
    The RSVP rules disallow merging of shared reservations with
    distinct reservations, since these modes are fundamentally
    incompatible.  They also disallow merging explicit sender
    selection with wildcard sender selection, since this might produce
    an unexpected service for a receiver that specified explicit
    selection.  As a result of these prohibitions, WF, SE, and FF
    styles are all mutually incompatible.

Braden, Ed., et. al. Standards Track [Page 13] RFC 2205 RSVP September 1997

    It would seem possible to simulate the effect of a WF reservation
    using the SE style.  When an application asked for WF, the RSVP
    process on the receiver host could use local state to create an
    equivalent SE reservation that explicitly listed all senders.
    However, an SE reservation forces the packet classifier in each
    node to explicitly select each sender in the list, while a WF
    allows the packet classifier to simply "wild card" the sender
    address and port.  When there is a large list of senders, a WF
    style reservation can therefore result in considerably less
    overhead than an equivalent SE style reservation.  For this
    reason, both SE and WF are included in the protocol.
    Other reservation options and styles may be defined in the future.
 1.4 Examples of Styles
    This section presents examples of each of the reservation styles
    and shows the effects of merging.
    Figure 4 illustrates a router with two incoming interfaces,
    labeled (a) and (b), through which flows will arrive, and two
    outgoing interfaces, labeled (c) and (d), through which data will
    be forwarded.  This topology will be assumed in the examples that
    follow.  There are three upstream senders; packets from sender S1
    (S2 and S3) arrive through previous hop (a) ((b), respectively).
    There are also three downstream receivers; packets bound for R1
    (R2 and R3) are routed via outgoing interface (c) ((d),
    respectively).  We furthermore assume that outgoing interface (d)
    is connected to a broadcast LAN, i.e., that replication occurs in
    the network; R2 and R3 are reached via different next hop routers
    (not shown).
    We must also specify the multicast routes within the node of
    Figure 4.  Assume first that data packets from each Si shown in
    Figure 4 are routed to both outgoing interfaces.  Under this
    assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter,
    Fixed-Filter, and Shared-Explicit reservations, respectively.

Braden, Ed., et. al. Standards Track [Page 14] RFC 2205 RSVP September 1997

                       ________________
                   (a)|                | (c)
    ( S1 ) ---------->|                |----------> ( R1 )
                      |     Router     |      |
                   (b)|                | (d)  |---> ( R2 )
    ( S2,S3 ) ------->|                |------|
                      |________________|      |---> ( R3 )
                                              |
                      Figure 4: Router Configuration
    For simplicity, these examples show flowspecs as one-dimensional
    multiples of some base resource quantity B.  The "Receives" column
    shows the RSVP reservation requests received over outgoing
    interfaces (c) and (d), and the "Reserves" column shows the
    resulting reservation state for each interface.   The "Sends"
    column shows the reservation requests that are sent upstream to
    previous hops (a) and (b).  In the "Reserves" column, each box
    represents one reserved "pipe" on the outgoing link, with the
    corresponding flow descriptor.
    Figure 5, showing the WF style, illustrates two distinct
    situations in which merging is required.  (1) Each of the two next
    hops on interface (d) results in a separate RSVP reservation
    request, as shown; these two requests must be merged into the
    effective flowspec, 3B, that is used to make the reservation on
    interface (d).  (2) The reservations on the interfaces (c) and (d)
    must be merged in order to forward the reservation requests
    upstream; as a result, the larger flowspec 4B is forwarded
    upstream to each previous hop.

Braden, Ed., et. al. Standards Track [Page 15] RFC 2205 RSVP September 1997

                           |
             Sends         |       Reserves             Receives
                           |
                           |       _______
       WF( *{4B} ) <- (a)  |  (c) | * {4B}|    (c) <- WF( *{4B} )
                           |      |_______|
                           |
    -----------------------|----------------------------------------
                           |       _______
       WF( *{4B} ) <- (b)  |  (d) | * {3B}|    (d) <- WF( *{3B} )
                           |      |_______|        <- WF( *{2B} )
            Figure 5: Wildcard-Filter (WF) Reservation Example
    Figure 6 shows Fixed-Filter (FF) style reservations.  For each
    outgoing interface, there is a separate reservation for each
    source that has been requested, but this reservation will be
    shared among all the receivers that made the request.  The flow
    descriptors for senders S2 and S3, received through outgoing
    interfaces (c) and (d), are packed (not merged) into the request
    forwarded to previous hop (b).  On the other hand, the three
    different flow descriptors specifying sender S1 are merged into
    the single request FF( S1{4B} ) that is sent to previous hop (a).
                        |
          Sends         |       Reserves             Receives
                        |
                        |       ________
   FF( S1{4B} ) <- (a)  |  (c) | S1{4B} |  (c) <- FF( S1{4B}, S2{5B} )
                        |      |________|
                        |      | S2{5B} |
                        |      |________|
   ---------------------|---------------------------------------------
                        |       ________
                <- (b)  |  (d) | S1{3B} |  (d) <- FF( S1{3B}, S3{B} )
   FF( S2{5B}, S3{B} )  |      |________|      <- FF( S1{B} )
                        |      | S3{B}  |
                        |      |________|
            Figure 6: Fixed-Filter (FF) Reservation Example

Braden, Ed., et. al. Standards Track [Page 16] RFC 2205 RSVP September 1997

    Figure 7 shows an example of Shared-Explicit (SE) style
    reservations.  When SE-style reservations are merged, the
    resulting filter spec is the union of the original filter specs,
    and the resulting flowspec is the largest flowspec.
                        |
          Sends         |       Reserves             Receives
                        |
                        |       ________
   SE( S1{3B} ) <- (a)  |  (c) |(S1,S2) |   (c) <- SE( (S1,S2){B} )
                        |      |   {B}  |
                        |      |________|
   ---------------------|---------------------------------------------
                        |      __________
                <- (b)  | (d) |(S1,S2,S3)|  (d) <- SE( (S1,S3){3B} )
   SE( (S2,S3){3B} )    |     |   {3B}   |      <- SE( S2{2B} )
                        |     |__________|
          Figure 7: Shared-Explicit (SE) Reservation Example
    The three examples just shown assume that data packets from S1,
    S2, and S3 are routed to both outgoing interfaces.  The top part
    of Figure 8 shows another routing assumption: data packets from S2
    and S3 are not forwarded to interface (c), e.g., because the
    network topology provides a shorter path for these senders towards
    R1, not traversing this node.  The bottom part of Figure 8 shows
    WF style reservations under this assumption.  Since there is no
    route from (b) to (c), the reservation forwarded out interface (b)
    considers only the reservation on interface (d).

Braden, Ed., et. al. Standards Track [Page 17] RFC 2205 RSVP September 1997

                       _______________
                   (a)|               | (c)
    ( S1 ) ---------->| >-----------> |----------> ( R1 )
                      |    >          |
                      |      >        |
                   (b)|        >      | (d)
    ( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 )
                      |_______________|
                     Router Configuration
                           |
             Sends         |       Reserves             Receives
                           |
                           |       _______
       WF( *{4B} ) <- (a)  |  (c) | * {4B}|   (c) <- WF( *{4B} )
                           |      |_______|
                           |
    -----------------------|----------------------------------------
                           |       _______
       WF( *{3B} ) <- (b)  |  (d) | * {3B}|   (d) <- WF( * {3B} )
                           |      |_______|       <- WF( * {2B} )
           Figure 8: WF Reservation Example -- Partial Routing

Braden, Ed., et. al. Standards Track [Page 18] RFC 2205 RSVP September 1997

2. RSVP Protocol Mechanisms

 2.1 RSVP Messages
     Previous       Incoming           Outgoing             Next
     Hops           Interfaces         Interfaces           Hops
     _____             _____________________                _____
    |     | data -->  |                     |  data -->    |     |
    |  A  |-----------| a                 c |--------------|  C  |
    |_____| Path -->  |                     |  Path -->    |_____|
            <-- Resv  |                     |  <-- Resv     _____
     _____            |       ROUTER        |           |  |     |
    |     |  |        |                     |           |--|  D  |
    |  B  |--| data-->|                     |  data --> |  |_____|
    |_____|  |--------| b                 d |-----------|
             | Path-->|                     |  Path --> |   _____
     _____   | <--Resv|_____________________|  <-- Resv |  |     |
    |     |  |                                          |--|  D' |
    |  B' |--|                                          |  |_____|
    |_____|  |                                          |
                       Figure 9: Router Using RSVP
    Figure 9 illustrates RSVP's model of a router node.  Each data
    flow arrives from a "previous hop" through a corresponding
    "incoming interface" and departs through one or more "outgoing
    interface"(s).  The same interface may act in both the incoming
    and outgoing roles for different data flows in the same session.
    Multiple previous hops and/or next hops may be reached through a
    given physical interface; for example, the figure implies that D
    and D' are connected to (d) with a broadcast LAN.
    There are two fundamental RSVP message types: Resv and Path.
    Each receiver host sends RSVP reservation request (Resv) messages
    upstream towards the senders.  These messages must follow exactly
    the reverse of the path(s) the data packets will use, upstream to
    all the sender hosts included in the sender selection.  They
    create and maintain "reservation state" in each node along the
    path(s).  Resv messages must finally be delivered to the sender
    hosts themselves, so that the hosts can set up appropriate traffic
    control parameters for the first hop.  The processing of Resv
    messages was discussed previously in Section 1.2.

Braden, Ed., et. al. Standards Track [Page 19] RFC 2205 RSVP September 1997

    Each RSVP sender host transmits RSVP "Path" messages downstream
    along the uni-/multicast routes provided by the routing
    protocol(s), following the paths of the data.  These Path messages
    store "path state" in each node along the way.  This path state
    includes at least the unicast IP address of the previous hop node,
    which is used to route the Resv messages hop-by-hop in the reverse
    direction.  (In the future, some routing protocols may supply
    reverse path forwarding information directly, replacing the
    reverse-routing function of path state).
    A Path message contains the following information in addition to
    the previous hop address:
    o    Sender Template
         A Path message is required to carry a Sender Template, which
         describes the format of data packets that the sender will
         originate.  This template is in the form of a filter spec
         that could be used to select this sender's packets from
         others in the same session on the same link.
         Sender Templates have exactly the same expressive power and
         format as filter specs that appear in Resv messages.
         Therefore a Sender Template may specify only the sender IP
         address and optionally the UDP/TCP sender port, and it
         assumes the protocol Id specified for the session.
    o    Sender Tspec
         A Path message is required to carry a Sender Tspec, which
         defines the traffic characteristics of the data flow that the
         sender will generate.  This Tspec is used by traffic control
         to prevent over-reservation, and perhaps unnecessary
         Admission Control failures.
    o    Adspec
         A Path message may carry a package of OPWA advertising
         information, known as an "Adspec".  An Adspec received in a
         Path message is passed to the local traffic control, which
         returns an updated Adspec; the updated version is then
         forwarded in Path messages sent downstream.

Braden, Ed., et. al. Standards Track [Page 20] RFC 2205 RSVP September 1997

    Path messages are sent with the same source and destination
    addresses as the data, so that they will be routed correctly
    through non-RSVP clouds (see Section 2.9).  On the other hand,
    Resv messages are sent hop-by-hop; each RSVP-speaking node
    forwards a Resv message to the unicast address of a previous RSVP
    hop.
 2.2 Merging Flowspecs
    A Resv message forwarded to a previous hop carries a flowspec that
    is the "largest" of the flowspecs requested by the next hops to
    which the data flow will be sent (however, see Section 3.5 for a
    different merging rule used in certain cases).  We say the
    flowspecs have been "merged".  The examples shown in Section 1.4
    illustrated another case of merging, when there are multiple
    reservation requests from different next hops for the same session
    and with the same filter spec, but RSVP should install only one
    reservation on that interface.  Here again, the installed
    reservation should have an effective flowspec that is the
    "largest" of the flowspecs requested by the different next hops.
    Since flowspecs are opaque to RSVP, the actual rules for comparing
    flowspecs must be defined and implemented outside RSVP proper.
    The comparison rules are defined in the appropriate integrated
    service specification document.  An RSVP implementation will need
    to call service-specific routines to perform flowspec merging.
    Note that flowspecs are generally multi-dimensional vectors; they
    may contain both Tspec and Rspec components, each of which may
    itself be multi-dimensional.  Therefore, it may not be possible to
    strictly order two flowspecs.  For example, if one request calls
    for a higher bandwidth and another calls for a tighter delay
    bound, one is not "larger" than the other.  In such a case,
    instead of taking the larger, the service-specific merging
    routines must be able to return a third flowspec that is at least
    as large as each; mathematically, this is the "least upper bound"
    (LUB).  In some cases, a flowspec at least as small is needed;
    this is the "greatest lower bound" (GLB) GLB (Greatest Lower
    Bound).
    The following steps are used to calculate the effective flowspec
    (Re, Te) to be installed on an interface [RFC 2210].  Here Te is
    the effective Tspec and Re is the effective Rspec.

Braden, Ed., et. al. Standards Track [Page 21] RFC 2205 RSVP September 1997

    1.   An effective flowspec is determined for the outgoing
         interface.  Depending upon the link-layer technology, this
         may require merging flowspecs from different next hops; this
         means computing the effective flowspec as the LUB of the
         flowspecs.  Note that what flowspecs to merge is determined
         by the link layer medium (see Section 3.11.2), while how to
         merge them is determined by the service model in use [RFC
         2210].
         The result is a flowspec that is opaque to RSVP but actually
         consists of the pair (Re, Resv_Te), where is Re is the
         effective Rspec and Resv_Te is the effective Tspec.
    2.   A service-specific calculation of Path_Te, the sum of all
         Tspecs that were supplied in Path messages from different
         previous hops (e.g., some or all of A, B, and B' in Figure
         9), is performed.
    3.   (Re, Resv_Te) and Path_Te are passed to traffic control.
         Traffic control will compute the effective flowspec as the
         "minimum" of Path_Te and Resv_Te, in a service-dependent
         manner.
    Section 3.11.6 defines a generic set of service-specific calls to
    compare flowspecs, to compute the LUB and GLB of flowspecs, and to
    compare and sum Tspecs.
 2.3 Soft State
    RSVP takes a "soft state" approach to managing the reservation
    state in routers and hosts.  RSVP soft state is created and
    periodically refreshed by Path and Resv messages.  The state is
    deleted if no matching refresh messages arrive before the
    expiration of a "cleanup timeout" interval.  State may also be
    deleted by an explicit "teardown" message, described in the next
    section.  At the expiration of each "refresh timeout" period and
    after a state change, RSVP scans its state to build and forward
    Path and Resv refresh messages to succeeding hops.
    Path and Resv messages are idempotent.  When a route changes, the
    next Path message will initialize the path state on the new route,
    and future Resv messages will establish reservation state there;
    the state on the now-unused segment of the route will time out.
    Thus, whether a message is "new" or a "refresh" is determined
    separately at each node, depending upon the existence of state at
    that node.

Braden, Ed., et. al. Standards Track [Page 22] RFC 2205 RSVP September 1997

    RSVP sends its messages as IP datagrams with no reliability
    enhancement.  Periodic transmission of refresh messages by hosts
    and routers is expected to handle the occasional loss of an RSVP
    message.  If the effective cleanup timeout is set to K times the
    refresh timeout period, then RSVP can tolerate K-1 successive RSVP
    packet losses without falsely deleting state.  The network traffic
    control mechanism should be statically configured to grant some
    minimal bandwidth for RSVP messages to protect them from
    congestion losses.
    The state maintained by RSVP is dynamic; to change the set of
    senders Si or to change any QoS request, a host simply starts
    sending revised Path and/or Resv messages.  The result will be an
    appropriate adjustment in the RSVP state in all nodes along the
    path; unused state will time out if it is not explicitly torn
    down.
    In steady state, state is refreshed hop-by-hop to allow merging.
    When the received state differs from the stored state, the stored
    state is updated.  If this update results in modification of state
    to be forwarded in refresh messages, these refresh messages must
    be generated and forwarded immediately, so that state changes can
    be propagated end-to-end without delay.  However, propagation of a
    change stops when and if it reaches a point where merging causes
    no resulting state change.  This minimizes RSVP control traffic
    due to changes and is essential for scaling to large multicast
    groups.
    State that is received through a particular interface I* should
    never be forwarded out the same interface.  Conversely, state that
    is forwarded out interface I* must be computed using only state
    that arrived on interfaces different from I*.  A trivial example
    of this rule is illustrated in Figure 10, which shows a transit
    router with one sender and one receiver on each interface (and
    assumes one next/previous hop per interface).  Interfaces (a) and
    (c) serve as both outgoing and incoming interfaces for this
    session.  Both receivers are making wildcard-style reservations,
    in which the Resv messages are forwarded to all previous hops for
    senders in the group, with the exception of the next hop from
    which they came.  The result is independent reservations in the
    two directions.
    There is an additional rule governing the forwarding of Resv
    messages: state from Resv messages received from outgoing
    interface Io should be forwarded to incoming interface Ii only if
    Path messages from Ii are forwarded to Io.

Braden, Ed., et. al. Standards Track [Page 23] RFC 2205 RSVP September 1997

                       ________________
                    a |                | c
    ( R1, S1 ) <----->|     Router     |<-----> ( R2, S2 )
                      |________________|
           Send                |        Receive
                               |
      WF( *{3B}) <-- (a)       |     (c) <-- WF( *{3B})
                               |
           Receive             |          Send
                               |
      WF( *{4B}) --> (a)       |     (c) --> WF( *{4B})
                               |
           Reserve on (a)      |        Reserve on (c)
            __________         |        __________
           |  * {4B}  |        |       |   * {3B} |
           |__________|        |       |__________|
                               |
                   Figure 10: Independent Reservations
 2.4 Teardown
    RSVP "teardown" messages remove path or reservation state
    immediately.  Although it is not necessary to explicitly tear down
    an old reservation, we recommend that all end hosts send a
    teardown request as soon as an application finishes.
    There are two types of RSVP teardown message, PathTear and
    ResvTear.  A PathTear message travels towards all receivers
    downstream from its point of initiation and deletes path state, as
    well as all dependent reservation state, along the way.  An
    ResvTear message deletes reservation state and travels towards all
    senders upstream from its point of initiation.  A PathTear
    (ResvTear) message may be conceptualized as a reversed-sense Path
    message (Resv message, respectively).
    A teardown request may be initiated either by an application in an
    end system (sender or receiver), or by a router as the result of
    state timeout or service preemption.  Once initiated, a teardown
    request must be forwarded hop-by-hop without delay.  A teardown
    message deletes the specified state in the node where it is
    received.  As always, this state change will be propagated
    immediately to the next node, but only if there will be a net
    change after merging.  As a result, a ResvTear message will prune
    the reservation state back (only) as far as possible.

Braden, Ed., et. al. Standards Track [Page 24] RFC 2205 RSVP September 1997

    Like all other RSVP messages, teardown requests are not delivered
    reliably.  The loss of a teardown request message will not cause a
    protocol failure because the unused state will eventually time out
    even though it is not explicitly deleted.  If a teardown message
    is lost, the router that failed to receive that message will time
    out its state and initiate a new teardown message beyond the loss
    point.  Assuming that RSVP message loss probability is small, the
    longest time to delete state will seldom exceed one refresh
    timeout period.
    It should be possible to tear down any subset of the established
    state.  For path state, the granularity for teardown is a single
    sender.  For reservation state, the granularity is an individual
    filter spec.  For example, refer to Figure 7.  Receiver R1 could
    send a ResvTear message for sender S2 only (or for any subset of
    the filter spec list), leaving S1 in place.
    A ResvTear message specifies the style and filters; any flowspec
    is ignored.  Whatever flowspec is in place will be removed if all
    its filter specs are torn down.
 2.5 Errors
    There are two RSVP error messages, ResvErr and PathErr.  PathErr
    messages are very simple; they are simply sent upstream to the
    sender that created the error, and they do not change path state
    in the nodes though which they pass.  There are only a few
    possible causes of path errors.
    However, there are a number of ways for a syntactically valid
    reservation request to fail at some node along the path.  A node
    may also decide to preempt an established reservation.  The
    handling of ResvErr messages is somewhat complex (Section 3.5).
    Since a request that fails may be the result of merging a number
    of requests, a reservation error must be reported to all of the
    responsible receivers.  In addition, merging heterogeneous
    requests creates a potential difficulty known as the "killer
    reservation" problem, in which one request could deny service to
    another.  There are actually two killer-reservation problems.
    1.   The first killer reservation problem (KR-I) arises when there
         is already a reservation Q0 in place.  If another receiver
         now makes a larger reservation Q1 > Q0, the result of merging
         Q0 and Q1 may be rejected by admission control in some
         upstream node.  This must not deny service to Q0.

Braden, Ed., et. al. Standards Track [Page 25] RFC 2205 RSVP September 1997

         The solution to this problem is simple: when admission
         control fails for a reservation request, any existing
         reservation is left in place.
    2.   The second killer reservation problem (KR-II) is the
         converse: the receiver making a reservation Q1 is persistent
         even though Admission Control is failing for Q1 in some node.
         This must not prevent a different receiver from now
         establishing a smaller reservation Q0 that would succeed if
         not merged with Q1.
         To solve this problem, a ResvErr message establishes
         additional state, called "blockade state", in each node
         through which it passes.  Blockade state in a node modifies
         the merging procedure to omit the offending flowspec (Q1 in
         the example) from the merge, allowing a smaller request to be
         forwarded and established.  The Q1 reservation state is said
         to be "blockaded".  Detailed rules are presented in Section
         3.5.
    A reservation request that fails Admission Control creates
    blockade state but is left in place in nodes downstream of the
    failure point.  It has been suggested that these reservations
    downstream from the failure represent "wasted" reservations and
    should be timed out if not actively deleted.  However, the
    downstream reservations are left in place, for the following
    reasons:
    o    There are two possible reasons for a receiver persisting in a
         failed reservation: (1) it is polling for resource
         availability along the entire path, or (2) it wants to obtain
         the desired QoS along as much of the path as possible.
         Certainly in the second case, and perhaps in the first case,
         the receiver will want to hold onto the reservations it has
         made downstream from the failure.
    o    If these downstream reservations were not retained, the
         responsiveness of RSVP to certain transient failures would be
         impaired.  For example, suppose a route "flaps" to an
         alternate route that is congested, so an existing reservation
         suddenly fails, then quickly recovers to the original route.
         The blockade state in each downstream router must not remove
         the state or prevent its immediate refresh.
    o    If we did not refresh the downstream reservations, they might
         time out, to be restored every Tb seconds (where Tb is the
         blockade state timeout interval).  Such intermittent behavior
         might be very distressing for users.

Braden, Ed., et. al. Standards Track [Page 26] RFC 2205 RSVP September 1997

 2.6 Confirmation
    To request a confirmation for its reservation request, a receiver
    Rj includes in the Resv message a confirmation-request object
    containing Rj's IP address.  At each merge point, only the largest
    flowspec and any accompanying confirmation-request object is
    forwarded upstream.  If the reservation request from Rj is equal
    to or smaller than the reservation in place on a node, its Resv is
    not forwarded further, and if the Resv included a confirmation-
    request object, a ResvConf message is sent back to Rj.  If the
    confirmation request is forwarded, it is forwarded immediately,
    and no more than once for each request.
    This confirmation mechanism has the following consequences:
    o    A new reservation request with a flowspec larger than any in
         place for a session will normally result in either a ResvErr
         or a ResvConf message back to the receiver from each sender.
         In this case, the ResvConf message will be an end-to-end
         confirmation.
    o    The receipt of a ResvConf gives no guarantees.  Assume the
         first two reservation requests from receivers R1 and R2
         arrive at the node where they are merged.  R2, whose
         reservation was the second to arrive at that node, may
         receive a ResvConf from that node while R1's request has not
         yet propagated all the way to a matching sender and may still
         fail.  Thus, R2 may receive a ResvConf although there is no
         end-to-end reservation in place; furthermore, R2 may receive
         a ResvConf followed by a ResvErr.
 2.7 Policy Control
    RSVP-mediated QoS requests allow particular user(s) to obtain
    preferential access to network resources.  To prevent abuse, some
    form of back pressure will generally be required on users who make
    reservations.  For example, such back pressure may be accomplished
    by administrative access policies, or it may depend upon some form
    of user feedback such as real or virtual billing for the "cost" of
    a reservation.  In any case, reliable user identification and
    selective admission will generally be needed when a reservation is
    requested.
    The term "policy control" is used for the mechanisms required to
    support access policies and back pressure for RSVP reservations.
    When a new reservation is requested, each node must answer two
    questions: "Are enough resources available to meet this request?"

Braden, Ed., et. al. Standards Track [Page 27] RFC 2205 RSVP September 1997

    and "Is this user allowed to make this reservation?"  These two
    decisions are termed the "admission control" decision and the
    "policy control" decision, respectively, and both must be
    favorable in order for RSVP to make a reservation.  Different
    administrative domains in the Internet may have different
    reservation policies.
    The input to policy control is referred to as "policy data", which
    RSVP carries in POLICY_DATA objects.  Policy data may include
    credentials identifying users or user classes, account numbers,
    limits, quotas, etc.  Like flowspecs, policy data is opaque to
    RSVP, which simply passes it to policy control when required.
    Similarly, merging of policy data must be done by the policy
    control mechanism rather than by RSVP itself.  Note that the merge
    points for policy data are likely to be at the boundaries of
    administrative domains.  It may therefore be necessary to carry
    accumulated and unmerged policy data upstream through multiple
    nodes before reaching one of these merge points.
    Carrying user-provided policy data in Resv messages presents a
    potential scaling problem.  When a multicast group has a large
    number of receivers, it will be impossible or undesirable to carry
    all receivers' policy data upstream.  The policy data will have to
    be administratively merged at places near the receivers, to avoid
    excessive policy data.  Further discussion of these issues and an
    example of a policy control scheme will be found in [PolArch96].
    Specifications for the format of policy data objects and RSVP
    processing rules for them are under development.
 2.8 Security
    RSVP raises the following security issues.
    o    Message integrity and node authentication
         Corrupted or spoofed reservation requests could lead to theft
         of service by unauthorized parties or to denial of service
         caused by locking up network resources.  RSVP protects
         against such attacks with a hop-by-hop authentication
         mechanism using an encrypted hash function.  The mechanism is
         supported by INTEGRITY objects that may appear in any RSVP
         message.  These objects use a keyed cryptographic digest
         technique, which assumes that RSVP neighbors share a secret.
         Although this mechanism is part of the base RSVP
         specification, it is described in a companion document
         [Baker96].

Braden, Ed., et. al. Standards Track [Page 28] RFC 2205 RSVP September 1997

         Widespread use of the RSVP integrity mechanism will require
         the availability of the long-sought key management and
         distribution infrastructure for routers.  Until that
         infrastructure becomes available, manual key management will
         be required to secure RSVP message integrity.
    o    User authentication
         Policy control will depend upon positive authentication of
         the user responsible for each reservation request.  Policy
         data may therefore include cryptographically protected user
         certificates.  Specification of such certificates is a future
         issue.
         Even without globally-verifiable user certificates, it may be
         possible to provide practical user authentication in many
         cases by establishing a chain of trust, using the hop-by-hop
         INTEGRITY mechanism described earlier.
    o    Secure data streams
         The first two security issues concerned RSVP's operation.  A
         third security issue concerns resource reservations for
         secure data streams.  In particular, the use of IPSEC (IP
         Security) in the data stream poses a problem for RSVP:  if
         the transport and higher level headers are encrypted, RSVP's
         generalized port numbers cannot be used to define a session
         or a sender.
         To solve this problem, an RSVP extension has been defined in
         which the security association identifier (IPSEC SPI) plays a
         role roughly equivalent to the generalized ports [RFC 2207].
 2.9 Non-RSVP Clouds
    It is impossible to deploy RSVP (or any new protocol) at the same
    moment throughout the entire Internet.  Furthermore, RSVP may
    never be deployed everywhere.  RSVP must therefore provide correct
    protocol operation even when two RSVP-capable routers are joined
    by an arbitrary "cloud" of non-RSVP routers.  Of course, an
    intermediate cloud that does not support RSVP is unable to perform
    resource reservation.  However, if such a cloud has sufficient
    capacity, it may still provide useful realtime service.
    RSVP is designed to operate correctly through such a non-RSVP
    cloud.  Both RSVP and non-RSVP routers forward Path messages
    towards the destination address using their local uni-/multicast
    routing table.  Therefore, the routing of Path messages will be

Braden, Ed., et. al. Standards Track [Page 29] RFC 2205 RSVP September 1997

    unaffected by non-RSVP routers in the path.  When a Path message
    traverses a non-RSVP cloud, it carries to the next RSVP-capable
    node the IP address of the last RSVP-capable router before
    entering the cloud.  An Resv message is then forwarded directly to
    the next RSVP-capable router on the path(s) back towards the
    source.
    Even though RSVP operates correctly through a non-RSVP cloud, the
    non-RSVP-capable nodes will in general perturb the QoS provided to
    a receiver.  Therefore, RSVP passes a `NonRSVP' flag bit to the
    local traffic control mechanism when there are non-RSVP-capable
    hops in the path to a given sender.  Traffic control combines this
    flag bit with its own sources of information, and forwards the
    composed information on integrated service capability along the
    path to receivers using Adspecs [RFC 2210].
    Some topologies of RSVP routers and non-RSVP routers can cause
    Resv messages to arrive at the wrong RSVP-capable node, or to
    arrive at the wrong interface of the correct node.  An RSVP
    process must be prepared to handle either situation.  If the
    destination address does not match any local interface and the
    message is not a Path or PathTear, the message must be forwarded
    without further processing by this node.  To handle the wrong
    interface case, a "Logical Interface Handle" (LIH) is used.  The
    previous hop information included in a Path message includes not
    only the IP address of the previous node but also an LIH defining
    the logical outgoing interface; both values are stored in the path
    state.  A Resv message arriving at the addressed node carries both
    the IP address and the LIH of the correct outgoing interface, i.e,
    the interface that should receive the requested reservation,
    regardless of which interface it arrives on.
    The LIH may also be useful when RSVP reservations are made over a
    complex link layer, to map between IP layer and link layer flow
    entities.
 2.10 Host Model
    Before a session can be created, the session identification
    (DestAddress, ProtocolId [, DstPort]) must be assigned and
    communicated to all the senders and receivers by some out-of-band
    mechanism.  When an RSVP session is being set up, the following
    events happen at the end systems.

Braden, Ed., et. al. Standards Track [Page 30] RFC 2205 RSVP September 1997

    H1   A receiver joins the multicast group specified by
         DestAddress, using IGMP.
    H2   A potential sender starts sending RSVP Path messages to the
         DestAddress.
    H3   A receiver application receives a Path message.
    H4   A receiver starts sending appropriate Resv messages,
         specifying the desired flow descriptors.
    H5   A sender application receives a Resv message.
    H6   A sender starts sending data packets.
    There are several synchronization considerations.
    o    H1 and H2 may happen in either order.
    o    Suppose that a new sender starts sending data (H6) but there
         are no multicast routes because no receivers have joined the
         group (H1).  Then the data will be dropped at some router
         node (which node depends upon the routing protocol) until
         receivers(s) appear.
    o    Suppose that a new sender starts sending Path messages (H2)
         and data (H6) simultaneously, and there are receivers but no
         Resv messages have reached the sender yet (e.g., because its
         Path messages have not yet propagated to the receiver(s)).
         Then the initial data may arrive at receivers without the
         desired QoS.  The sender could mitigate this problem by
         awaiting arrival of the first Resv message (H5); however,
         receivers that are farther away may not have reservations in
         place yet.
    o    If a receiver starts sending Resv messages (H4) before
         receiving any Path messages (H3), RSVP will return error
         messages to the receiver.
         The receiver may simply choose to ignore such error messages,
         or it may avoid them by waiting for Path messages before
         sending Resv messages.
    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.11.1 discusses the general requirements and
    outlines a generic interface.

Braden, Ed., et. al. Standards Track [Page 31] RFC 2205 RSVP September 1997

3. RSVP Functional Specification

 3.1 RSVP Message Formats
    An RSVP message consists of a common header, followed by a body
    consisting of a variable number of variable-length, typed
    "objects".  The following subsections define the formats of the
    common header, the standard object header, and each of the RSVP
    message types.
    For each RSVP message type, there is a set of rules for the
    permissible choice of object types.  These rules are specified
    using Backus-Naur Form (BNF) augmented with square brackets
    surrounding optional sub-sequences.  The BNF implies an order for
    the objects in a message.  However, in many (but not all) cases,
    object order makes no logical difference.  An implementation
    should create messages with the objects in the order shown here,
    but accept the objects in any permissible order.
    3.1.1 Common Header
              0             1              2             3
       +-------------+-------------+-------------+-------------+
       | Vers | Flags|  Msg Type   |       RSVP Checksum       |
       +-------------+-------------+-------------+-------------+
       |  Send_TTL   | (Reserved)  |        RSVP Length        |
       +-------------+-------------+-------------+-------------+
       The fields in the common header are as follows:
       Vers: 4 bits
            Protocol version number.  This is version 1.
       Flags: 4 bits
            0x01-0x08: Reserved
                 No flag bits are defined yet.
       Msg Type: 8 bits
            1 = Path
            2 = Resv

Braden, Ed., et. al. Standards Track [Page 32] RFC 2205 RSVP September 1997

            3 = PathErr
            4 = ResvErr
            5 = PathTear
            6 = ResvTear
            7 = ResvConf
       RSVP Checksum: 16 bits
            The one's complement of the one's complement sum of the
            message, with the checksum field replaced by zero for the
            purpose of computing the checksum.  An all-zero value
            means that no checksum was transmitted.
       Send_TTL: 8 bits
            The IP TTL value with which the message was sent.  See
            Section 3.8.
       RSVP Length: 16 bits
            The total length of this RSVP message in bytes, including
            the common header and the variable-length objects that
            follow.
    3.1.2 Object Formats
       Every object consists of one or more 32-bit words with a one-
       word header, with the following format:
              0             1              2             3
       +-------------+-------------+-------------+-------------+
       |       Length (bytes)      |  Class-Num  |   C-Type    |
       +-------------+-------------+-------------+-------------+
       |                                                       |
       //                  (Object contents)                   //
       |                                                       |
       +-------------+-------------+-------------+-------------+

Braden, Ed., et. al. Standards Track [Page 33] RFC 2205 RSVP September 1997

       An object header has the following fields:
       Length
            A 16-bit field containing the total object length in
            bytes.  Must always be a multiple of 4, and at least 4.
       Class-Num
            Identifies the object class; values of this field are
            defined in Appendix A.  Each object class has a name,
            which is always capitalized in this document.  An RSVP
            implementation must recognize the following classes:
            NULL
                 A NULL object has a Class-Num of zero, and its C-Type
                 is ignored.  Its length must be at least 4, but can
                 be any multiple of 4.  A NULL object may appear
                 anywhere in a sequence of objects, and its contents
                 will be ignored by the receiver.
            SESSION
                 Contains the IP destination address (DestAddress),
                 the IP protocol id, and some form of generalized
                 destination port, to define a specific session for
                 the other objects that follow.  Required in every
                 RSVP message.
            RSVP_HOP
                 Carries the IP address of the RSVP-capable node that
                 sent this message and a logical outgoing interface
                 handle (LIH; see Section 3.3).  This document refers
                 to a RSVP_HOP object as a PHOP ("previous hop")
                 object for downstream messages or as a NHOP (" next
                 hop") object for upstream messages.
            TIME_VALUES
                 Contains the value for the refresh period R used by
                 the creator of the message; see Section 3.7.
                 Required in every Path and Resv message.

Braden, Ed., et. al. Standards Track [Page 34] RFC 2205 RSVP September 1997

            STYLE
                 Defines the reservation style plus style-specific
                 information that is not in FLOWSPEC or FILTER_SPEC
                 objects.  Required in every Resv message.
            FLOWSPEC
                 Defines a desired QoS, in a Resv message.
            FILTER_SPEC
                 Defines a subset of session data packets that should
                 receive the desired QoS (specified by a FLOWSPEC
                 object), in a Resv message.
            SENDER_TEMPLATE
                 Contains a sender IP address and perhaps some
                 additional demultiplexing information to identify a
                 sender.  Required in a Path message.
            SENDER_TSPEC
                 Defines the traffic characteristics of a sender's
                 data flow.  Required in a Path message.
            ADSPEC
                 Carries OPWA data, in a Path message.
            ERROR_SPEC
                 Specifies an error in a PathErr, ResvErr, or a
                 confirmation in a ResvConf message.
            POLICY_DATA
                 Carries information that will allow a local policy
                 module to decide whether an associated reservation is
                 administratively permitted.  May appear in Path,
                 Resv, PathErr, or ResvErr message.
                 The use of POLICY_DATA objects is not fully specified
                 at this time; a future document will fill this gap.

Braden, Ed., et. al. Standards Track [Page 35] RFC 2205 RSVP September 1997

            INTEGRITY
                 Carries cryptographic data to authenticate the
                 originating node and to verify the contents of this
                 RSVP message.  The use of the INTEGRITY object is
                 described in [Baker96].
            SCOPE
                 Carries an explicit list of sender hosts towards
                 which the information in the message is to be
                 forwarded.  May appear in a Resv, ResvErr, or
                 ResvTear message.  See Section 3.4.
            RESV_CONFIRM
                 Carries the IP address of a receiver that requested a
                 confirmation.  May appear in a Resv or ResvConf
                 message.
       C-Type
            Object type, unique within Class-Num.  Values are defined
            in Appendix A.
       The maximum object content length is 65528 bytes.  The Class-
       Num and C-Type fields may be used together as a 16-bit number
       to define a unique type for each object.
       The high-order two bits of the Class-Num is used to determine
       what action a node should take if it does not recognize the
       Class-Num of an object; see Section 3.10.
    3.1.3 Path Messages
       Each sender host periodically sends a Path message for each
       data flow it originates.  It contains a SENDER_TEMPLATE object
       defining the format of the data packets and a SENDER_TSPEC
       object specifying the traffic characteristics of the flow.
       Optionally, it may contain may be an ADSPEC object carrying
       advertising (OPWA) data for the flow.
       A Path message travels from a sender to receiver(s) along the
       same path(s) used by the data packets.  The IP source address
       of a Path message must be an address of the sender it
       describes, while the destination address must be the
       DestAddress for the session.  These addresses assure that the
       message will be correctly routed through a non-RSVP cloud.

Braden, Ed., et. al. Standards Track [Page 36] RFC 2205 RSVP September 1997

       The format of a Path message is as follows:
         <Path Message> ::= <Common Header> [ <INTEGRITY> ]
                                   <SESSION> <RSVP_HOP>
                                   <TIME_VALUES>
                                  [ <POLICY_DATA> ... ]
                                  [ <sender descriptor> ]
         <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
                                  [ <ADSPEC> ]
       If the INTEGRITY object is present, it must immediately follow
       the common header.  There are no other requirements on
       transmission order, although the above order is recommended.
       Any number of POLICY_DATA objects may appear.
       The PHOP (i.e., RSVP_HOP) object of each Path message contains
       the previous hop address, i.e., the IP address of the interface
       through which the Path message was most recently sent.  It also
       carries a logical interface handle (LIH).
       Each RSVP-capable node along the path(s) captures a Path
       message and processes it to create path state for the sender
       defined by the SENDER_TEMPLATE and SESSION objects.  Any
       POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in
       the path state.  If an error is encountered while processing a
       Path message, a PathErr message is sent to the originating
       sender of the Path message.  Path messages must satisfy the
       rules on SrcPort and DstPort in Section 3.2.
       Periodically, the RSVP process at a node scans the path state
       to create new Path messages to forward towards the receiver(s).
       Each message contains a sender descriptor defining one sender,
       and carries the original sender's IP address as its IP source
       address.  Path messages eventually reach the applications on
       all receivers; however, they are not looped back to a receiver
       running in the same application process as the sender.
       The RSVP process forwards Path messages and replicates them as
       required by multicast sessions, using routing information it
       obtains from the appropriate uni-/multicast routing process.
       The route depends upon the session DestAddress, and for some

Braden, Ed., et. al. Standards Track [Page 37] RFC 2205 RSVP September 1997

       routing protocols also upon the source (sender's IP) address.
       The routing information generally includes the list of zero or
       more outgoing interfaces to which the Path message is to be
       forwarded.  Because each outgoing interface has a different IP
       address, the Path messages sent out different interfaces
       contain different PHOP addresses.  In addition, ADSPEC objects
       carried in Path messages will also generally differ for
       different outgoing interfaces.
       Path state for a given session and sender may not necessarily
       have a unique PHOP or unique incoming interface.  There are two
       cases, corresponding to multicast and unicast sessions.
       o    Multicast Sessions
            Multicast routing allows a stable distribution tree in
            which Path messages from the same sender arrive from more
            than one PHOP, and RSVP must be prepared to maintain all
            such path state.  The RSVP rules for handling this
            situation are contained in Section 3.9.  RSVP must not
            forward (according to the rules of Section 3.9) Path
            messages that arrive on an incoming interface different
            from that provided by routing.
       o    Unicast Sessions
            For a short period following a unicast route change
            upstream, a node may receive Path messages from multiple
            PHOPs for a given (session, sender) pair.  The node cannot
            reliably determine which is the right PHOP, although the
            node will receive data from only one of the PHOPs at a
            time.  One implementation choice for RSVP is to ignore
            PHOP in matching unicast past state, and allow the PHOP to
            flip among the candidates.  Another implementation choice
            is to maintain path state for each PHOP and to send Resv
            messages upstream towards all such PHOPs.  In either case,
            the situation is a transient; the unused path state will
            time out or be torn down (because upstream path state
            timed out).
    3.1.4 Resv Messages
       Resv messages carry reservation requests hop-by-hop from
       receivers to senders, along the reverse paths of data flows for
       the session.  The IP destination address of a Resv message is
       the unicast address of a previous-hop node, obtained from the
       path state.  The IP source address is an address of the node
       that sent the message.

Braden, Ed., et. al. Standards Track [Page 38] RFC 2205 RSVP September 1997

       The Resv message format is as follows:
         <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
                                 <SESSION>  <RSVP_HOP>
                                 <TIME_VALUES>
                                 [ <RESV_CONFIRM> ]  [ <SCOPE> ]
                                 [ <POLICY_DATA> ... ]
                                 <STYLE> <flow descriptor list>
         <flow descriptor list> ::=  <empty> |
                          <flow descriptor list> <flow descriptor>
       If the INTEGRITY object is present, it must immediately follow
       the common header.  The STYLE object followed by the flow
       descriptor list must occur at the end of the message, and
       objects within the flow descriptor list must follow the BNF
       given below.  There are no other requirements on transmission
       order, although the above order is recommended.
       The NHOP (i.e., the RSVP_HOP) object contains the IP address of
       the interface through which the Resv message was sent and the
       LIH for the logical interface on which the reservation is
       required.
       The appearance of a RESV_CONFIRM object signals a request for a
       reservation confirmation and carries the IP address of the
       receiver to which the ResvConf should be sent.  Any number of
       POLICY_DATA objects may appear.
       The BNF above defines a flow descriptor list as simply a list
       of flow descriptors.  The following style-dependent rules
       specify in more detail the composition of a valid flow
       descriptor list for each of the reservation styles.
       o    WF Style:
              <flow descriptor list> ::=  <WF flow descriptor>
              <WF flow descriptor> ::= <FLOWSPEC>

Braden, Ed., et. al. Standards Track [Page 39] RFC 2205 RSVP September 1997

       o    FF style:
              <flow descriptor list> ::=
                        <FLOWSPEC>  <FILTER_SPEC>  |
                        <flow descriptor list> <FF flow descriptor>
              <FF flow descriptor> ::=
                        [ <FLOWSPEC> ] <FILTER_SPEC>
            Each elementary FF style request is defined by a single
            (FLOWSPEC, FILTER_SPEC) pair, and multiple such requests
            may be packed into the flow descriptor list of a single
            Resv message.  A FLOWSPEC object can be omitted if it is
            identical to the most recent such object that appeared in
            the list; the first FF flow descriptor must contain a
            FLOWSPEC.
       o    SE style:
              <flow descriptor list> ::= <SE flow descriptor>
              <SE flow descriptor> ::=
                                     <FLOWSPEC> <filter spec list>
              <filter spec list> ::=  <FILTER_SPEC>
                                |  <filter spec list> <FILTER_SPEC>
       The reservation scope, i.e., the set of senders towards which a
       particular reservation is to be forwarded (after merging), is
       determined as follows:
       o    Explicit sender selection
            The reservation is forwarded to all senders whose
            SENDER_TEMPLATE objects recorded in the path state match a
            FILTER_SPEC object in the reservation.  This match must
            follow the rules of Section 3.2.

Braden, Ed., et. al. Standards Track [Page 40] RFC 2205 RSVP September 1997

       o    Wildcard sender selection
            A request with wildcard sender selection will match all
            senders that route to the given outgoing interface.
            Whenever a Resv message with wildcard sender selection is
            forwarded to more than one previous hop, a SCOPE object
            must be included in the message (see Section 3.4 below);
            in this case, the scope for forwarding the reservation is
            constrained to just the sender IP addresses explicitly
            listed in the SCOPE object.
            A Resv message that is forwarded by a node is generally
            the result of merging a set of incoming Resv messages
            (that are not blockaded; see Section 3.5).  If one of
            these merged messages contains a RESV_CONFIRM object and
            has a FLOWSPEC larger than the FLOWSPECs of the other
            merged reservation requests, then this RESV_CONFIRM object
            is forwarded in the outgoing Resv message.  A RESV_CONFIRM
            object in one of the other merged requests (whose
            flowspecs are equal to, smaller than, or incomparable to,
            the merged flowspec, and which is not blockaded) will
            trigger the generation of an ResvConf message containing
            the RESV_CONFIRM.  A RESV_CONFIRM object in a request that
            is blockaded will be neither forwarded nor returned; it
            will be dropped in the current node.
    3.1.5 Path Teardown Messages
       Receipt of a PathTear (path teardown) message deletes matching
       path state.  Matching state must have match the SESSION,
       SENDER_TEMPLATE, and PHOP objects.  In addition, a PathTear
       message for a multicast session can only match path state for
       the incoming interface on which the PathTear arrived.  If there
       is no matching path state, a PathTear message should be
       discarded and not forwarded.
       PathTear messages are initiated explicitly by senders or by
       path state timeout in any node, and they travel downstream
       towards all receivers.  A unicast PathTear must not be
       forwarded if there is path state for the same (session, sender)
       pair but a different PHOP.  Forwarding of multicast PathTear
       messages is governed by the rules of Section 3.9.

Braden, Ed., et. al. Standards Track [Page 41] RFC 2205 RSVP September 1997

       A PathTear message must be routed exactly like the
       corresponding Path message.  Therefore, its IP destination
       address must be the session DestAddress, and its IP source
       address must be the sender address from the path state being
       torn down.
           <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
                                       <SESSION> <RSVP_HOP>
                                      [ <sender descriptor> ]
           <sender descriptor> ::= (see earlier definition)
       A PathTear message may include a SENDER_TSPEC or ADSPEC object
       in its sender descriptor, but these must be ignored.  The order
       requirements are as given earlier for a Path message, but the
       above order is recommended.
       Deletion of path state as the result of a PathTear message or a
       timeout must also adjust related reservation state as required
       to maintain consistency in the local node.  The adjustment
       depends upon the reservation style.  For example, suppose a
       PathTear deletes the path state for a sender S.  If the style
       specifies explicit sender selection (FF or SE), any reservation
       with a filter spec matching S should be deleted; if the style
       has wildcard sender selection (WF), the reservation should be
       deleted if S is the last sender to the session.  These
       reservation changes should not trigger an immediate Resv
       refresh message, since the PathTear message has already made
       the required changes upstream.  They should not trigger a
       ResvErr message, since the result could be to generate a shower
       of such messages.
    3.1.6 Resv Teardown Messages
       Receipt of a ResvTear (reservation teardown) message deletes
       matching reservation state.  Matching reservation state must
       match the SESSION, STYLE, and FILTER_SPEC objects as well as
       the LIH in the RSVP_HOP object.  If there is no matching
       reservation state, a ResvTear message should be discarded.  A
       ResvTear message may tear down any subset of the filter specs
       in FF-style or SE-style reservation state.
       ResvTear messages are initiated explicitly by receivers or by
       any node in which reservation state has timed out, and they
       travel upstream towards all matching senders.

Braden, Ed., et. al. Standards Track [Page 42] RFC 2205 RSVP September 1997

       A ResvTear message must be routed like the corresponding Resv
       message, and its IP destination address will be the unicast
       address of a previous hop.
           <ResvTear Message> ::= <Common Header> [<INTEGRITY>]
                                       <SESSION> <RSVP_HOP>
                                       [ <SCOPE> ] <STYLE>
                                       <flow descriptor list>
           <flow descriptor list> ::= (see earlier definition)
       FLOWSPEC objects in the flow descriptor list of a ResvTear
       message will be ignored and may be omitted.  The order
       requirements for INTEGRITY object, sender descriptor, STYLE
       object, and flow descriptor list are as given earlier for a
       Resv message, but the above order is recommended.  A ResvTear
       message may include a SCOPE object, but it must be ignored.
       A ResvTear message will cease to be forwarded at the node where
       merging would have suppressed forwarding of the corresponding
       Resv message.  Depending upon the resulting state change in a
       node, receipt of a ResvTear message may cause a ResvTear
       message to be forwarded, a modified Resv message to be
       forwarded, or no message to be forwarded.  These three cases
       can be illustrated in the case of the FF-style reservations
       shown in Figure 6.
       o    If receiver R2 sends a ResvTear message for its
            reservation S3{B}, the corresponding reservation is
            removed from interface (d) and a ResvTear for S3{B} is
            forwarded out (b).
       o    If receiver R1 sends a ResvTear for its reservation
            S1{4B}, the corresponding reservation is removed from
            interface (c) and a modified Resv message FF( S1{3B} ) is
            immediately forwarded out (a).
       o    If receiver R3 sends a ResvTear message for S1{B}, there
            is no change in the effective reservation S1{3B} on (d)
            and no message is forwarded.

Braden, Ed., et. al. Standards Track [Page 43] RFC 2205 RSVP September 1997

    3.1.7 Path Error Messages
       PathErr (path error) messages report errors in processing Path
       messages.  They are travel upstream towards senders and are
       routed hop-by-hop using the path state.  At each hop, the IP
       destination address is the unicast address of a previous hop.
       PathErr messages do not modify the state of any node through
       which they pass; they are only reported to the sender
       application.
         <PathErr message> ::= <Common Header> [ <INTEGRITY> ]
                                    <SESSION> <ERROR_SPEC>
                                    [ <POLICY_DATA> ...]
                                   [ <sender descriptor> ]
         <sender descriptor> ::= (see earlier definition)
       The ERROR_SPEC object specifies the error and includes the IP
       address of the node that detected the error (Error Node
       Address).  One or more POLICY_DATA objects may be included
       message to provide relevant information.  The sender descriptor
       is copied from the message in error.  The object order
       requirements are as given earlier for a Path message, but the
       above order is recommended.
    3.1.8 Resv Error Messages
       ResvErr (reservation error) messages report errors in
       processing Resv messages, or they may report the spontaneous
       disruption of a reservation, e.g., by administrative
       preemption.
       ResvErr messages travel downstream towards the appropriate
       receivers, routed hop-by-hop using the reservation state.  At
       each hop, the IP destination address is the unicast address of
       a next-hop node.

Braden, Ed., et. al. Standards Track [Page 44] RFC 2205 RSVP September 1997

         <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
                                    <SESSION>  <RSVP_HOP>
                                    <ERROR_SPEC>  [ <SCOPE> ]
                                    [ <POLICY_DATA> ...]
                                  <STYLE> [ <error flow descriptor> ]
       The ERROR_SPEC object specifies the error and includes the IP
       address of the node that detected the error (Error Node
       Address).  One or more POLICY_DATA objects may be included in
       an error message to provide relevant information (e.g.,, when a
       policy control error is being reported).  The RSVP_HOP object
       contains the previous hop address, and the STYLE object is
       copied from the Resv message in error.  The use of the SCOPE
       object in a ResvErr message is defined below in Section 3.4.
       The object order requirements are as given for Resv messages,
       but the above order is recommended.
       The following style-dependent rules define the composition of a
       valid error flow descriptor; the object order requirements are
       as given earlier for flow descriptor.
       o    WF Style:
                <error flow descriptor> ::= <WF flow descriptor>
       o    FF style:
                <error flow descriptor> ::= <FF flow descriptor>
            Each flow descriptor in a FF-style Resv message must be
            processed independently, and a separate ResvErr message
            must be generated for each one that is in error.
       o    SE style:
                <error flow descriptor> ::= <SE flow descriptor>
            An SE-style ResvErr message may list the subset of the
            filter specs in the corresponding Resv message to which
            the error applies.

Braden, Ed., et. al. Standards Track [Page 45] RFC 2205 RSVP September 1997

       Note that a ResvErr message contains only one flow descriptor.
       Therefore, a Resv message that contains N > 1 flow descriptors
       (FF style) may create up to N separate ResvErr messages.
       Generally speaking, a ResvErr message should be forwarded
       towards all receivers that may have caused the error being
       reported.  More specifically:
       o    The node that detects an error in a reservation request
            sends a ResvErr message to the next hop node from which
            the erroneous reservation came.
            This ResvErr message must contain the information required
            to define the error and to route the error message in
            later hops.  It therefore includes an ERROR_SPEC object, a
            copy of the STYLE object, and the appropriate error flow
            descriptor.  If the error is an admission control failure
            while attempting to increase an existing reservation, then
            the existing reservation must be left in place and the
            InPlace flag bit must be on in the ERROR_SPEC of the
            ResvErr message.
       o    Succeeding nodes forward the ResvErr message to next hops
            that have local reservation state.  For reservations with
            wildcard scope, there is an additional limitation on
            forwarding ResvErr messages, to avoid loops; see Section
            3.4.  There is also a rule restricting the forwarding of a
            Resv message after an Admission Control failure; see
            Section 3.5.
            A ResvErr message that is forwarded should carry the
            FILTER_SPEC(s) from the corresponding reservation state.
       o    When a ResvErr message reaches a receiver, the STYLE
            object, flow descriptor list, and ERROR_SPEC object
            (including its flags) should be delivered to the receiver
            application.
    3.1.9 Confirmation Messages
       ResvConf messages are sent to (probabilistically) acknowledge
       reservation requests.  A ResvConf message is sent as the result
       of the appearance of a RESV_CONFIRM object in a Resv message.

Braden, Ed., et. al. Standards Track [Page 46] RFC 2205 RSVP September 1997

       A ResvConf message is sent to the unicast address of a receiver
       host; the address is obtained from the RESV_CONFIRM object.
       However, a ResvConf message is forwarded to the receiver hop-
       by-hop, to accommodate the hop-by-hop integrity check
       mechanism.
         <ResvConf message> ::= <Common Header> [ <INTEGRITY> ]
                                    <SESSION> <ERROR_SPEC>
                                    <RESV_CONFIRM>
                                    <STYLE> <flow descriptor list>
         <flow descriptor list> ::= (see earlier definition)
       The object order requirements are the same as those given
       earlier for a Resv message, but the above order is recommended.
       The RESV_CONFIRM object is a copy of that object in the Resv
       message that triggered the confirmation.  The ERROR_SPEC is
       used only to carry the IP address of the originating node, in
       the Error Node Address; the Error Code and Value are zero to
       indicate a confirmation.  The flow descriptor list specifies
       the particular reservations that are being confirmed; it may be
       a subset of flow descriptor list of the Resv that requested the
       confirmation.
 3.2 Port Usage
    An RSVP session is normally defined by the triple: (DestAddress,
    ProtocolId, DstPort).  Here DstPort is a UDP/TCP destination port
    field (i.e., a 16-bit quantity carried at octet offset +2 in the
    transport header).  DstPort may be omitted (set to zero) if the
    ProtocolId specifies a protocol that does not have a destination
    port field in the format used by UDP and TCP.
    RSVP allows any value for ProtocolId.  However, end-system
    implementations of RSVP may know about certain values for this
    field, and in particular the values for UDP and TCP (17 and 6,
    respectively).  An end system may give an error to an application
    that either:
    o    specifies a non-zero DstPort for a protocol that does not
         have UDP/TCP-like ports, or

Braden, Ed., et. al. Standards Track [Page 47] RFC 2205 RSVP September 1997

    o    specifies a zero DstPort for a protocol that does have
         UDP/TCP-like ports.
    Filter specs and sender templates specify the pair: (SrcAddress,
    SrcPort), where SrcPort is a UDP/TCP source port field (i.e., a
    16-bit quantity carried at octet offset +0 in the transport
    header).   SrcPort may be omitted (set to zero) in certain cases.
    The following rules hold for the use of zero DstPort and/or
    SrcPort fields in RSVP.
    1.   Destination ports must be consistent.
         Path state and reservation state for the same DestAddress and
         ProtocolId must each have DstPort values that are all zero or
         all non-zero.  Violation of this condition in a node is a
         "Conflicting Dest Ports" error.
    2.   Destination ports rule.
         If DstPort in a session definition is zero, all SrcPort
         fields used for that session must also be zero.  The
         assumption here is that the protocol does not have UDP/TCP-
         like ports.   Violation of this condition in a node is a "Bad
         Src Ports" error.
    3.   Source Ports must be consistent.
         A sender host must not send path state both with and without
         a zero SrcPort.  Violation of this condition is a
         "Conflicting Sender Port" error.
    Note that RSVP has no "wildcard" ports, i.e., a zero port cannot
    match a non-zero port.
 3.3 Sending RSVP Messages
    RSVP messages are sent hop-by-hop between RSVP-capable routers as
    "raw" IP datagrams with protocol number 46.  Raw IP datagrams are
    also intended to be used between an end system and the first/last
    hop router, although it is also possible to encapsulate RSVP
    messages as UDP datagrams for end-system communication, as
    described in Appendix C.  UDP encapsulation is needed for systems
    that cannot do raw network I/O.

Braden, Ed., et. al. Standards Track [Page 48] RFC 2205 RSVP September 1997

    Path, PathTear, and ResvConf messages must be sent with the Router
    Alert IP option [RFC 2113] in their IP headers.  This option may
    be used in the fast forwarding path of a high-speed router to
    detect datagrams that require special processing.
    Upon the arrival of an RSVP message M that changes the state, a
    node must forward the state modification immediately.  However,
    this must not trigger sending a message out the interface through
    which M arrived (which could happen if the implementation simply
    triggered an immediate refresh of all state for the session).
    This rule is necessary to prevent packet storms on broadcast LANs.
    In this version of the spec, each RSVP message must occupy exactly
    one IP datagram.  If it exceeds the MTU, such a datagram will be
    fragmented by IP and reassembled at the recipient node.  This has
    several consequences:
    o    A single RSVP message may not exceed the maximum IP datagram
         size, approximately 64K bytes.
    o    A congested non-RSVP cloud could lose individual message
         fragments, and any lost fragment will lose the entire
         message.
    Future versions of the protocol will provide solutions for these
    problems if they prove burdensome.  The most likely direction will
    be to perform "semantic fragmentation", i.e., break the path or
    reservation state being transmitted into multiple self-contained
    messages, each of an acceptable size.
    RSVP uses its periodic refresh mechanisms to recover from
    occasional packet losses.  Under network overload, however,
    substantial losses of RSVP messages could cause a failure of
    resource reservations.  To control the queuing delay and dropping
    of RSVP packets, routers should be configured to offer them a
    preferred class of service.  If RSVP packets experience noticeable
    losses when crossing a congested non-RSVP cloud, a larger value
    can be used for the timeout factor K (see section 3.7).
    Some multicast routing protocols provide for "multicast tunnels",
    which do IP encapsulation of multicast packets for transmission
    through routers that do not have multicast capability.  A
    multicast tunnel looks like a logical outgoing interface that is
    mapped into some physical interface.  A multicast routing protocol
    that supports tunnels will describe a route using a list of
    logical rather than physical interfaces.  RSVP can operate across
    such multicast tunnels in the following manner:

Braden, Ed., et. al. Standards Track [Page 49] RFC 2205 RSVP September 1997

    1.   When a node N forwards a Path message out a logical outgoing
         interface L, it includes in the message some encoding of the
         identity of L, called the "logical interface handle" or LIH.
         The LIH value is carried in the RSVP_HOP object.
    2.   The next hop node N' stores the LIH value in its path state.
    3.   When N' sends a Resv message to N, it includes the LIH value
         from the path state (again, in the RSVP_HOP object).
    4.   When the Resv message arrives at N, its LIH value provides
         the information necessary to attach the reservation to the
         appropriate logical interface.  Note that N creates and
         interprets the LIH; it is an opaque value to N'.
    Note that this only solves the routing problem posed by tunnels.
    The tunnel appears to RSVP as a non-RSVP cloud.  To establish RSVP
    reservations within the tunnel, additional machinery will be
    required, to be defined in the future.
 3.4 Avoiding RSVP Message Loops
    Forwarding of RSVP messages must avoid looping.  In steady state,
    Path and Resv messages are forwarded on each hop only once per
    refresh period.  This avoids looping packets, but there is still
    the possibility of an "auto-refresh" loop, clocked by the refresh
    period.  Such auto-refresh loops keep state active "forever", even
    if the end nodes have ceased refreshing it, until the receivers
    leave the multicast group and/or the senders stop sending Path
    messages.  On the other hand, error and teardown messages are
    forwarded immediately and are therefore subject to direct looping.
    Consider each message type.
    o    Path Messages
         Path messages are forwarded in exactly the same way as IP
         data packets.  Therefore there should be no loops of Path
         messages (except perhaps for transient routing loops, which
         we ignore here), even in a topology with cycles.
    o    PathTear Messages
         PathTear messages use the same routing as Path messages and
         therefore cannot loop.

Braden, Ed., et. al. Standards Track [Page 50] RFC 2205 RSVP September 1997

    o    PathErr Messages
         Since Path messages do not loop, they create path state
         defining a loop-free reverse path to each sender.  PathErr
         messages are always directed to particular senders and
         therefore cannot loop.
    o    Resv Messages
         Resv messages directed to particular senders (i.e., with
         explicit sender selection) cannot loop.  However, Resv
         messages with wildcard sender selection (WF style) have a
         potential for auto-refresh looping.
    o    ResvTear Messages
         Although ResvTear messages are routed the same as Resv
         messages, during the second pass around a loop there will be
         no state so any ResvTear message will be dropped.  Hence
         there is no looping problem here.
    o    ResvErr Messages
         ResvErr messages for WF style reservations may loop for
         essentially the same reasons that Resv messages loop.
    o    ResvConf Messages
         ResvConf messages are forwarded towards a fixed unicast
         receiver address and cannot loop.
    If the topology has no loops, then looping of Resv and ResvErr
    messages with wildcard sender selection can be avoided by simply
    enforcing the rule given earlier: state that is received through a
    particular interface must never be forwarded out the same
    interface.  However, when the topology does have cycles, further
    effort is needed to prevent auto-refresh loops of wildcard Resv
    messages and fast loops of wildcard ResvErr messages.  The
    solution to this problem adopted by this protocol specification is
    for such messages to carry an explicit sender address list in a
    SCOPE object.

Braden, Ed., et. al. Standards Track [Page 51] RFC 2205 RSVP September 1997

    When a Resv message with WF style is to be forwarded to a
    particular previous hop, a new SCOPE object is computed from the
    SCOPE objects that were received in matching Resv messages.  If
    the computed SCOPE object is empty, the message is not forwarded
    to the previous hop; otherwise, the message is sent containing the
    new SCOPE object.  The rules for computing a new SCOPE object for
    a Resv message are as follows:
    1.   The union is formed of the sets of sender IP addresses listed
         in all SCOPE objects in the reservation state for the given
         session.
         If reservation state from some NHOP does not contain a SCOPE
         object, a substitute sender list must be created and included
         in the union.  For a message that arrived on outgoing
         interface OI, the substitute list is the set of senders that
         route to OI.
    2.   Any local senders (i.e., any sender applications on this
         node) are removed from this set.
    3.   If the SCOPE object is to be sent to PHOP, remove from the
         set any senders that did not come from PHOP.
    Figure 11 shows an example of wildcard-scoped (WF style) Resv
    messages.  The address lists within SCOPE objects are shown in
    square brackets.  Note that there may be additional connections
    among the nodes, creating looping topology that is not shown.

Braden, Ed., et. al. Standards Track [Page 52] RFC 2205 RSVP September 1997

                       ________________
                    a |                | c
         R4, S4<----->|     Router     |<-----> R2, S2, S3
                      |                |
                    b |                |
         R1, S1<----->|                |
                      |________________|
        Send on (a):           |    Receive on (c):
                               |
           <-- WF( [S4] )      |       <-- WF( [S4, S1])
                               |
        Send on (b):           |
                               |
           <-- WF( [S1] )      |
                               |
        Receive on (a):        |    Send on (c):
                               |
           WF( [S1,S2,S3]) --> |       WF( [S2, S3]) -->
                               |
        Receive on (b):        |
                               |
           WF( [S2,S3,S4]) --> |
                               |
         Figure 11: SCOPE Objects in Wildcard-Scope Reservations
    SCOPE objects are not necessary if the multicast routing uses
    shared trees or if the reservation style has explicit sender
    selection.  Furthermore, attaching a SCOPE object to a reservation
    should be deferred to a node which has more than one previous hop
    for the reservation state.
    The following rules are used for SCOPE objects in ResvErr messages
    with WF style:
    1.   The node that detected the error initiates an ResvErr message
         containing a copy of the SCOPE object associated with the
         reservation state or message in error.
    2.   Suppose a wildcard-style ResvErr message arrives at a node
         with a SCOPE object containing the sender host address list
         L.  The node forwards the ResvErr message using the rules of
         Section 3.1.8.  However,

Braden, Ed., et. al. Standards Track [Page 53] RFC 2205 RSVP September 1997

         the ResvErr message forwarded out OI must contain a SCOPE
         object derived from L by including only those senders that
         route to OI.  If this SCOPE object is empty, the ResvErr
         message should not be sent out OI.
 3.5 Blockade State
    The basic rule for creating a Resv refresh message is to merge the
    flowspecs of the reservation requests in place in the node, by
    computing their LUB.  However, this rule is modified by the
    existence of "blockade state" resulting from ResvErr messages, to
    solve the KR-II problem (see Section 2.5).  The blockade state
    also enters into the routing of ResvErr messages for Admission
    Control failure.
    When a ResvErr message for an Admission Control failure is
    received, its flowspec Qe is used to create or refresh an element
    of local blockade state.  Each element of blockade state consists
    of a blockade flowspec Qb taken from the flowspec of the ResvErr
    message, and an associated blockade timer Tb.  When a blockade
    timer expires, the corresponding blockade state is deleted.
    The granularity of blockade state depends upon the style of the
    ResvErr message that created it.  For an explicit style, there may
    be a blockade state element (Qb(S),Tb(S)) for each sender S.  For
    a wildcard style, blockade state is per previous hop P.
    An element of blockade state with flowspec Qb is said to
    "blockade" a reservation with flowspec Qi if Qb is not (strictly)
    greater than Qi.  For example, suppose that the LUB of two
    flowspecs is computed by taking the max of each of their
    corresponding components.  Then Qb blockades Qi if for some
    component j, Qb[j] <= Qi[j].
    Suppose that a node receives a ResvErr message from previous hop P
    (or, if style is explicit, sender S) as the result of an Admission
    Control failure upstream.  Then:
    1.   An element of blockade state is created for P (or S) if it
         did not exist.
    2.   Qb(P) (or Qb(S)) is set equal to the flowspec Qe from the
         ResvErr message.
    3.   A corresponding blockade timer Tb(P) (or Tb(S)) is started or
         restarted for a time Kb*R.  Here Kb is a fixed multiplier and
         R is the refresh interval for reservation state.  Kb should
         be configurable.

Braden, Ed., et. al. Standards Track [Page 54] RFC 2205 RSVP September 1997

    4.   If there is some local reservation state that is not
         blockaded (see below), an immediate reservation refresh for P
         (or S) is generated.
    5.   The ResvErr message is forwarded to next hops in the
         following way.  If the InPlace bit is off, the ResvErr
         message is forwarded to all next hops for which there is
         reservation state.  If the InPlace bit is on, the ResvErr
         message is forwarded only to the next hops whose Qi is
         blockaded by Qb.
    Finally, we present the modified rule for merging flowspecs to
    create a reservation refresh message.
    o    If there are any local reservation requests Qi that are not
         blockaded, these are merged by computing their LUB.  The
         blockaded reservations are ignored; this allows forwarding of
         a smaller reservation that has not failed and may perhaps
         succeed, after a larger reservation fails.
    o    Otherwise (all local requests Qi are blockaded), they are
         merged by taking the GLB (Greatest Lower Bound) of the Qi's.
         (The use of some definition of "minimum" improves performance
         by bracketing the failure level between the largest that
         succeeds and the smallest that fails.  The choice of GLB in
         particular was made because it is simple to define and
         implement, and no reason is known for using a different
         definition of "minimum" here).
    This refresh merging algorithm is applied separately to each flow
    (each sender or PHOP) contributing to a shared reservation (WF or
    SE style).
    Figure 12 shows an example of the the application of blockade
    state for a shared reservation (WF style).  There are two previous
    hops labeled (a) and (b), and two next hops labeled (c) and (d).
    The larger reservation 4B arrived from (c) first, but it failed
    somewhere upstream via PHOP (a), but not via PHOP (b).  The
    figures show the final "steady state" after the smaller
    reservation 2B subsequently arrived from (d).  This steady state
    is perturbed roughly every Kb*R seconds, when the blockade state
    times out.  The next refresh then sends 4B to previous hop (a);
    presumably this will fail, sending a ResvErr message that will
    re-establish the blockade state, returning to the situation shown
    in the figure.  At the same time, the ResvErr message will be
    forwarded to next hop (c) and to all receivers downstream
    responsible for the 4B reservations.

Braden, Ed., et. al. Standards Track [Page 55] RFC 2205 RSVP September 1997

             Send     Blockade |   Reserve       Receive
                     State {Qb}|
                               |   ________
      (a) <- WF(*{2B})    {4B} |  | * {4B} | WF(*{4B}) <- (c)
                               |  |________|
                               |
    ---------------------------|-------------------------------
                               |
                               |   ________
      (b) <- WF(*{4B})   (none)|  | * {2B} | WF(*{2B}) <- (d)
                               |  |________|
                 Figure 12: Blockading with Shared Style
 3.6 Local Repair
    When a route changes, the next Path or Resv refresh message will
    establish path or reservation state (respectively) along the new
    route.  To provide fast adaptation to routing changes without the
    overhead of short refresh periods, the local routing protocol
    module can notify the RSVP process of route changes for particular
    destinations.  The RSVP process should use this information to
    trigger a quick refresh of state for these destinations, using the
    new route.
    The specific rules are as follows:
    o    When routing detects a change of the set of outgoing
         interfaces for destination G, RSVP should update the path
         state, wait for a short period W, and then send Path
         refreshes for all sessions G/* (i.e., for any session with
         destination G, regardless of destination port).
         The short wait period before sending Path refreshes is to
         allow the routing protocol to settle, and the value for W
         should be chosen accordingly.  Currently W = 2 sec is
         suggested; however, this value should be configurable per
         interface.
    o    When a Path message arrives with a Previous Hop address that
         differs from the one stored in the path state, RSVP should
         send immediate Resv refreshes to that PHOP.

Braden, Ed., et. al. Standards Track [Page 56] RFC 2205 RSVP September 1997

 3.7 Time Parameters
    There are two time parameters relevant to each element of RSVP
    path or reservation state in a node: the refresh period R between
    generation of successive refreshes for the state by the neighbor
    node, and the local state's lifetime L.  Each RSVP Resv or Path
    message may contain a TIME_VALUES object specifying the R value
    that was used to generate this (refresh) message.  This R value is
    then used to determine the value for L when the state is received
    and stored.  The values for R and L may vary from hop to hop.
    In more detail:
    1.   Floyd and Jacobson [FJ94] have shown that periodic messages
         generated by independent network nodes can become
         synchronized.  This can lead to disruption in network
         services as the periodic messages contend with other network
         traffic for link and forwarding resources.  Since RSVP sends
         periodic refresh messages, it must avoid message
         synchronization and ensure that any synchronization that may
         occur is not stable.
         For this reason, the refresh timer should be randomly set to
         a value in the range [0.5R, 1.5R].
    2.   To avoid premature loss of state, L must satisfy L >= (K +
         0.5)*1.5*R, where K is a small integer.  Then in the worst
         case, K-1 successive messages may be lost without state being
         deleted.  To compute a lifetime L for a collection of state
         with different R values R0, R1, ..., replace R by max(Ri).
         Currently K = 3 is suggested as the default.  However, it may
         be necessary to set a larger K value for hops with high loss
         rate.  K may be set either by manual configuration per
         interface, or by some adaptive technique that has not yet
         been specified.
    3.   Each Path or Resv message carries a TIME_VALUES object
         containing the refresh time R used to generate refreshes.
         The recipient node uses this R to determine the lifetime L of
         the stored state created or refreshed by the message.
    4.   The refresh time R is chosen locally by each node.  If the
         node does not implement local repair of reservations
         disrupted by route changes, a smaller R speeds up adaptation
         to routing changes, while increasing the RSVP overhead.  With
         local repair, a router can be more relaxed about R since the
         periodic refresh becomes only a backstop robustness

Braden, Ed., et. al. Standards Track [Page 57] RFC 2205 RSVP September 1997

         mechanism.  A node may therefore adjust the effective R
         dynamically to control the amount of overhead due to refresh
         messages.
         The current suggested default for R is 30 seconds.  However,
         the default value Rdef should be configurable per interface.
    5.   When R is changed dynamically, there is a limit on how fast
         it may increase.  Specifically, the ratio of two successive
         values R2/R1 must not exceed 1 + Slew.Max.
         Currently, Slew.Max is 0.30.  With K = 3, one packet may be
         lost without state timeout while R is increasing 30 percent
         per refresh cycle.
    6.   To improve robustness, a node may temporarily send refreshes
         more often than R after a state change (including initial
         state establishment).
    7.   The values of Rdef, K, and Slew.Max used in an implementation
         should be easily modifiable per interface, as experience may
         lead to different values.  The possibility of dynamically
         adapting K and/or Slew.Max in response to measured loss rates
         is for future study.
 3.8 Traffic Policing and Non-Integrated Service Hops
    Some QoS services may require traffic policing at some or all of
    (1) the edge of the network, (2) a merging point for data from
    multiple senders, and/or (3) a branch point where traffic flow
    from upstream may be greater than the downstream reservation being
    requested.  RSVP knows where such points occur and must so
    indicate to the traffic control mechanism.  On the other hand,
    RSVP does not interpret the service embodied in the flowspec and
    therefore does not know whether policing will actually be applied
    in any particular case.
    The RSVP process passes to traffic control a separate policing
    flag for each of these three situations.
    o    E_Police_Flag -- Entry Policing
         This flag is set in the first-hop RSVP node that implements
         traffic control (and is therefore capable of policing).
         For example, sender hosts must implement RSVP but currently
         many of them do not implement traffic control.  In this case,
         the E_Police_Flag should be off in the sender host, and it

Braden, Ed., et. al. Standards Track [Page 58] RFC 2205 RSVP September 1997

         should only be set on when the first node capable of traffic
         control is reached.  This is controlled by the E_Police flag
         in SESSION objects.
    o    M_Police_Flag -- Merge Policing
         This flag should be set on for a reservation using a shared
         style (WF or SE) when flows from more than one sender are
         being merged.
    o    B_Police_Flag -- Branch Policing
         This flag should be set on when the flowspec being installed
         is smaller than, or incomparable to, a FLOWSPEC in place on
         any other interface, for the same FILTER_SPEC and SESSION.
    RSVP must also test for the presence of non-RSVP hops in the path
    and pass this information to traffic control.  From this flag bit
    that the RSVP process supplies and from its own local knowledge,
    traffic control can detect the presence of a hop in the path that
    is not capable of QoS control, and it passes this information to
    the receivers in Adspecs [RFC 2210].
    With normal IP forwarding, RSVP can detect a non-RSVP hop by
    comparing the IP TTL with which a Path message is sent to the TTL
    with which it is received; for this purpose, the transmission TTL
    is placed in the common header.  However, the TTL is not always a
    reliable indicator of non-RSVP hops, and other means must
    sometimes be used.  For example, if the routing protocol uses IP
    encapsulating tunnels, then the routing protocol must inform RSVP
    when non-RSVP hops are included.  If no automatic mechanism will
    work, manual configuration will be required.
 3.9 Multihomed Hosts
    Accommodating multihomed hosts requires some special rules in
    RSVP.  We use the term `multihomed host' to cover both hosts (end
    systems) with more than one network interface and routers that are
    supporting local application programs.
    An application executing on a multihomed host may explicitly
    specify which interface any given flow will use for sending and/or
    for receiving data packets, to override the system-specified
    default interface.  The RSVP process must be aware of the default,
    and if an application sets a specific interface, it must also pass
    that information to RSVP.

Braden, Ed., et. al. Standards Track [Page 59] RFC 2205 RSVP September 1997

    o    Sending Data
         A sender application uses an API call (SENDER in Section
         3.11.1) to declare to RSVP the characteristics of the data
         flow it will originate.  This call may optionally include the
         local IP address of the sender. If it is set by the
         application, this parameter must be the interface address for
         sending the data packets; otherwise, the system default
         interface is implied.
         The RSVP process on the host then sends Path messages for
         this application out the specified interface (only).
    o    Making Reservations
         A receiver application uses an API call (RESERVE in Section
         3.11.1) to request a reservation from RSVP.  This call may
         optionally include the local IP address of the receiver,
         i.e., the interface address for receiving data packets.  In
         the case of multicast sessions, this is the interface on
         which the group has been joined.  If the parameter is
         omitted, the system default interface is used.
         In general, the RSVP process should send Resv messages for an
         application out the specified interface.  However, when the
         application is executing on a router and the session is
         multicast, a more complex situation arises.   Suppose in this
         case that a receiver application joins the group on an
         interface Iapp that differs from Isp, the shortest-path
         interface to the sender.  Then there are two possible ways
         for multicast routing to deliver data packets to the
         application.  The RSVP process must determine which case
         holds by examining the path state, to decide which incoming
         interface to use for sending Resv messages.
         1.   The multicast routing protocol may create a separate
              branch of the multicast distribution `tree' to deliver
              to Iapp.  In this case, there will be path state for
              both interfaces Isp and Iapp.  The path state on Iapp
              should only match a reservation from the local
              application; it must be marked "Local_only" by the RSVP
              process.  If "Local_only" path state for Iapp exists,
              the Resv message should be sent out Iapp.
              Note that it is possible for the path state blocks for
              Isp and Iapp to have the same next hop, if there is an
              intervening non-RSVP cloud.

Braden, Ed., et. al. Standards Track [Page 60] RFC 2205 RSVP September 1997

         2.   The multicast routing protocol may forward data within
              the router from Isp to Iapp.  In this case, Iapp will
              appear in the list of outgoing interfaces of the path
              state for Isp, and the Resv message should be sent out
              Isp.
         3.   When Path and PathTear messages are forwarded, path
              state marked "Local_Only" must be ignored.
 3.10 Future Compatibility
    We may expect that in the future new object C-Types will be
    defined for existing object classes, and perhaps new object
    classes will be defined.  It will be desirable to employ such new
    objects within the Internet using older implementations that do
    not recognize them.  Unfortunately, this is only possible to a
    limited degree with reasonable complexity.  The rules are as
    follows (`b' represents a bit).
    1.   Unknown Class
         There are three possible ways that an RSVP implementation can
         treat an object with unknown class.  This choice is
         determined by the two high-order bits of the Class-Num octet,
         as follows.
         o    Class-Num = 0bbbbbbb
              The entire message should be rejected and an "Unknown
              Object Class" error returned.
         o    Class-Num = 10bbbbbb
              The node should ignore the object, neither forwarding it
              nor sending an error message.
         o    Class-Num = 11bbbbbb
              The node should ignore the object but forward it,
              unexamined and unmodified, in all messages resulting
              from this message.
         The following more detailed rules hold for unknown-class
         objects with a Class-Num of the form 11bbbbbb:
         1.   Such unknown-class objects received in PathTear,
              ResvTear, PathErr, or ResvErr messages should be
              forwarded immediately in the same messages.

Braden, Ed., et. al. Standards Track [Page 61] RFC 2205 RSVP September 1997

         2.   Such unknown-class objects received in Path or Resv
              messages should be saved with the corresponding state
              and forwarded in any refresh message resulting from that
              state.
         3.   When a Resv refresh is generated by merging multiple
              reservation requests, the refresh message should include
              the union of unknown-class objects from the component
              requests.  Only one copy of each unique unknown-class
              object should be included in this union.
         4.   The original order of such unknown-class objects need
              not be retained; however, the message that is forwarded
              must obey the general order requirements for its message
              type.
         Although objects with unknown class cannot be merged, these
         rules will forward such objects until they reach a node that
         knows how to merge them.  Forwarding objects with unknown
         class enables incremental deployment of new objects; however,
         the scaling limitations of doing so must be carefully
         examined before a new object class is deployed with both high
         bits on.
    2.   Unknown C-Type for Known Class
         One might expect the known Class-Num to provide information
         that could allow intelligent handling of such an object.
         However, in practice such class-dependent handling is
         complex, and in many cases it is not useful.
         Generally, the appearance of an object with unknown C-Type
         should result in rejection of the entire message and
         generation of an error message (ResvErr or PathErr as
         appropriate).  The error message will include the Class-Num
         and C-Type that failed (see Appendix B); the end system that
         originated the failed message may be able to use this
         information to retry the request using a different C-Type
         object, repeating this process until it runs out of
         alternatives or succeeds.
         Objects of certain classes (FLOWSPEC, ADSPEC, and
         POLICY_DATA) are opaque to RSVP, which simply hands them to
         traffic control or policy modules.  Depending upon its
         internal rules, either of the latter modules may reject a C-
         Type and inform the RSVP process; RSVP should then reject the
         message and send an error, as described in the previous
         paragraph.

Braden, Ed., et. al. Standards Track [Page 62] RFC 2205 RSVP September 1997

 3.11 RSVP Interfaces
    RSVP on a router has interfaces to routing and to traffic control.
    RSVP on a host has an interface to applications (i.e, an API) and
    also an interface to traffic control (if it exists on the host).
    3.11.1 Application/RSVP Interface
       This section describes a generic interface between an
       application and an RSVP control process.  The details of a real
       interface may be operating-system dependent; the following can
       only suggest the basic functions to be performed.  Some of
       these calls cause information to be returned asynchronously.
       o    Register Session
            Call: SESSION( DestAddress , ProtocolId, DstPort
                       [ , SESSION_object ]
                       [ , Upcall_Proc_addr ] )  -> Session-id
            This call initiates RSVP processing for a session, defined
            by DestAddress together with ProtocolId and possibly a
            port number DstPort.  If successful, the SESSION call
            returns immediately with a local session identifier
            Session-id, which may be used in subsequent calls.
            The Upcall_Proc_addr parameter defines the address of an
            upcall procedure to receive asynchronous error or event
            notification; see below.  The SESSION_object parameter is
            included as an escape mechanism to support some more
            general definition of the session ("generalized
            destination port"), should that be necessary in the
            future.  Normally SESSION_object will be omitted.
       o    Define Sender
            Call: SENDER( Session-id
                       [ , Source_Address ]  [ , Source_Port ]
                       [ , Sender_Template ]
                       [ , Sender_Tspec ]    [ , Adspec ]
                       [ , Data_TTL ]        [ , Policy_data ] )

Braden, Ed., et. al. Standards Track [Page 63] RFC 2205 RSVP September 1997

            A sender uses this call to define, or to modify the
            definition of, the attributes of the data flow.  The first
            SENDER call for the session registered as `Session-id'
            will cause RSVP to begin sending Path messages for this
            session; later calls will modify the path information.
            The SENDER parameters are interpreted as follows:
  1. Source_Address
                 This is the address of the interface from which the
                 data will be sent.  If it is omitted, a default
                 interface will be used.  This parameter is needed
                 only on a multihomed sender host.
  1. Source_Port
                 This is the UDP/TCP port from which the data will be
                 sent.
  1. 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.
  1. Sender_Tspec
                 This parameter describes the traffic flow to be sent;
                 see [RFC 2210].
  1. Adspec
                 This parameter may be specified to initialize the
                 computation of QoS properties along the path; see
                 [RFC 2210].
  1. 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.

Braden, Ed., et. al. Standards Track [Page 64] RFC 2205 RSVP September 1997

  1. Policy_data
                 This optional parameter passes policy data for the
                 sender.  This data may be supplied by a system
                 service, with the application treating it as opaque.
       o    Reserve
            Call: RESERVE( session-id, [ receiver_address , ]
                      [ CONF_flag, ] [ Policy_data, ]
                       style, style-dependent-parms )
            A receiver uses this call to make or to modify a resource
            reservation for the session registered as `session-id'.
            The 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 existing reservations may result in
            admission control failures).
            The optional `receiver_address' parameter may be used by a
            receiver on a multihomed host (or router); it is the IP
            address of one of the node's interfaces.  The CONF_flag
            should be set on if a reservation confirmation is desired,
            off otherwise.  The `Policy_data' parameter specifies
            policy data for the receiver, while the `style' parameter
            indicates the reservation style.  The rest of the
            parameters depend upon the style; generally these will be
            appropriate flowspecs and filter specs.
            The RESERVE call returns immediately.  Following a RESERVE
            call, an asynchronous ERROR/EVENT upcall may occur at any
            time.
       o    Release
            Call: RELEASE( session-id )
            This call removes RSVP state for the session specified by
            session-id.  The node then sends appropriate teardown
            messages and ceases sending refreshes for this session-id.

Braden, Ed., et. al. Standards Track [Page 65] RFC 2205 RSVP September 1997

       o    Error/Event Upcalls
            The general form of a upcall is as follows:
            Upcall: <Upcall_Proc>( ) -> session-id, Info_type,
                          information_parameters
            Here "Upcall_Proc" represents the upcall procedure whose
            address was supplied in the SESSION call.  This upcall may
            occur asynchronously at any time after a SESSION call and
            before a RELEASE call, to indicate an error or an event.
            Currently there are five upcall types, distinguished by
            the Info_type parameter.  The selection of information
            parameters depends upon the type.
            1.   Info_type = PATH_EVENT
                 A Path Event upcall results from receipt of the first
                 Path message for this session, indicating to a
                 receiver application that there is at least one
                 active sender, or if the path state changes.
                 Upcall: <Upcall_Proc>( ) -> session-id,
                             Info_type=PATH_EVENT,
                             Sender_Tspec, Sender_Template
                             [ , Adspec ] [ , Policy_data ]
                 This upcall presents the Sender_Tspec, the
                 Sender_Template, the Adspec, and any policy data from
                 a Path message.
            2.   Info_type = RESV_EVENT
                 A Resv Event upcall is triggered by the receipt of
                 the first RESV message, or by modification of a
                 previous reservation state, for this session.

Braden, Ed., et. al. Standards Track [Page 66] RFC 2205 RSVP September 1997

                 Upcall: <Upcall_Proc>( ) -> session-id,
                             Info_type=RESV_EVENT,
                             Style, Flowspec, Filter_Spec_list
                             [ , Policy_data ]
                 Here `Flowspec' will be the effective QoS that has
                 been received.  Note that an FF-style Resv message
                 may result in multiple RESV_EVENT upcalls, one for
                 each flow descriptor.
            3.   Info_type = PATH_ERROR
                 An Path Error event indicates an error in sender
                 information that was specified in a SENDER call.
                 Upcall: <Upcall_Proc>( ) -> session-id,
                               Info_type=PATH_ERROR,
                               Error_code , Error_value ,
                               Error_Node , Sender_Template
                               [ , Policy_data_list ]
                 The Error_code parameter will define the error, and
                 Error_value may supply some additional (perhaps
                 system-specific) data about the error.  The
                 Error_Node parameter will specify the IP address of
                 the node that detected the error.  The
                 Policy_data_list parameter, if present, will contain
                 any POLICY_DATA objects from the failed Path message.
            4.   Info_type = RESV_ERR
                 An Resv Error event indicates an error in a
                 reservation message to which this application
                 contributed.
                 Upcall: <Upcall_Proc>( ) -> session-id,
                               Info_type=RESV_ERROR,

Braden, Ed., et. al. Standards Track [Page 67] RFC 2205 RSVP September 1997

                               Error_code , Error_value ,
                               Error_Node , Error_flags ,
                               Flowspec, Filter_spec_list
                               [ , Policy_data_list ]
                 The Error_code parameter will define the error and
                 Error_value may supply some additional (perhaps
                 system-specific) data.  The Error_Node parameter will
                 specify the IP address of the node that detected the
                 event being reported.
                 There are two Error_flags:
  1. InPlace
                      This flag may be on for an Admission Control
                      failure, to indicate that there was, and is, a
                      reservation in place at the failure node.  This
                      flag is set at the failure point and forwarded
                      in ResvErr messages.
  1. NotGuilty
                      This flag may be on for an Admission Control
                      failure, to indicate that the flowspec requested
                      by this receiver was strictly less than the
                      flowspec that got the error.  This flag is set
                      at the receiver API.
                 Filter_spec_list and Flowspec will contain the
                 corresponding objects from the error flow descriptor
                 (see Section 3.1.8).  List_count will specify the
                 number of FILTER_SPECS in Filter_spec_list.  The
                 Policy_data_list parameter will contain any
                 POLICY_DATA objects from the ResvErr message.
            5.   Info_type = RESV_CONFIRM
                 A Confirmation event indicates that a ResvConf
                 message was received.
                 Upcall: <Upcall_Proc>( ) -> session-id,
                               Info_type=RESV_CONFIRM,

Braden, Ed., et. al. Standards Track [Page 68] RFC 2205 RSVP September 1997

                               Style, List_count,
                               Flowspec, Filter_spec_list
                               [ , Policy_data ]
                 The parameters are interpreted as in the Resv Error
                 upcall.
            Although RSVP messages indicating path or resv events 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.  All error and confirmation events
            should be reported to the application.
    3.11.2 RSVP/Traffic Control Interface
       It is difficult to present a generic interface to traffic
       control, because the details of establishing a reservation
       depend strongly upon the particular link layer technology in
       use on an interface.
       Merging of RSVP reservations is required because of multicast
       data delivery, which replicates data packets for delivery to
       different next-hop nodes.  At each such replication point, RSVP
       must merge reservation requests from the corresponding next
       hops by computing the "maximum" of their flowspecs.  At a given
       router or host, one or more of the following three replication
       locations may be in use.
       1.   IP layer
            IP multicast forwarding performs replication in the IP
            layer.  In this case, RSVP must merge the reservations
            that are in place on the corresponding outgoing interfaces
            in order to forward a request upstream.
       2.   "The network"
            Replication might take place downstream from the node,
            e.g., in a broadcast LAN, in link-layer switches, or in a
            mesh of non-RSVP-capable routers (see Section 2.8).   In

Braden, Ed., et. al. Standards Track [Page 69] RFC 2205 RSVP September 1997

            these cases, RSVP must merge the reservations from the
            different next hops in order to make the reservation on
            the single outgoing interface.  It must also merge
            reservations requests from all outgoing interfaces in
            order to forward a request upstream.
       3.   Link-layer driver
            For a multi-access technology, replication may occur in
            the link layer driver or interface card.  For example,
            this case might arise when there is a separate ATM point-
            to-point VC towards each next hop.  RSVP may need to apply
            traffic control independently to each VC, without merging
            requests from different next hops.
       In general, these complexities do not impact the protocol
       processing that is required by RSVP, except to determine
       exactly what reservation requests need to be merged.  It may be
       desirable to organize an RSVP implementation into two parts: a
       core that performs link-layer-independent processing, and a
       link-layer-dependent adaptation layer.  However, we present
       here a generic interface that assumes that replication can
       occur only at the IP layer or in "the network".
       o    Make a Reservation
            Call: TC_AddFlowspec( Interface, TC_Flowspec,
                              TC_Tspec, TC_Adspec, Police_Flags )
  1. > RHandle [, Fwd_Flowspec]
            The TC_Flowspec parameter defines the desired effective
            QoS to admission control; its value is computed as the
            maximum over the flowspecs of different next hops (see the
            Compare_Flowspecs call below).  The TC_Tspec parameter
            defines the effective sender Tspec Path_Te (see Section
            2.2).  The TC_Adspec parameter defines the effective
            Adspec.  The Police_Flags parameter carries the three
            flags E_Police_Flag, M_Police_Flag, and B_Police_Flag; see
            Section 3.8.
            If this call is successful, it establishes a new
            reservation channel corresponding to RHandle; otherwise,
            it returns an error code.  The opaque number RHandle is
            used by the caller for subsequent references to this
            reservation.  If the traffic control service updates the

Braden, Ed., et. al. Standards Track [Page 70] RFC 2205 RSVP September 1997

            flowspec, the call will also return the updated object as
            Fwd_Flowspec.
       o    Modify Reservation
            Call: TC_ModFlowspec( Interface, RHandle, TC_Flowspec,
                                TC_Tspec, TC_Adspec, Police_flags )
                                      [ -> Fwd_Flowspec ]
            This call is used to modify an existing reservation.
            TC_Flowspec is passed to Admission Control; if it is
            rejected, the current flowspec is left in force.  The
            corresponding filter specs, if any, are not affected.  The
            other parameters are defined as in TC_AddFlowspec.  If the
            service updates the flowspec, the call will also return
            the updated object as Fwd_Flowspec.
       o    Delete Flowspec
            Call: TC_DelFlowspec( Interface, RHandle )
            This call will delete an existing reservation, including
            the flowspec and all associated filter specs.
       o    Add Filter Spec
            Call: TC_AddFilter( Interface, RHandle,
                            Session , FilterSpec ) -> FHandle
            This call is used to associate an additional filter spec
            with the reservation specified by the given RHandle,
            following a successful TC_AddFlowspec call.  This call
            returns a filter handle FHandle.
       o    Delete Filter Spec
            Call: TC_DelFilter( Interface, FHandle )
            This call is used to remove a specific filter, specified
            by FHandle.

Braden, Ed., et. al. Standards Track [Page 71] RFC 2205 RSVP September 1997

       o    OPWA Update
            Call: TC_Advertise( Interface, Adspec,
                                Non_RSVP_Hop_flag ) -> New_Adspec
            This call is used for OPWA to compute the outgoing
            advertisement New_Adspec for a specified interface.  The
            flag bit Non_RSVP_Hop_flag should be set whenever the RSVP
            daemon detects that the previous RSVP hop included one or
            more non-RSVP-capable routers.  TC_Advertise will insert
            this information into New_Adspec to indicate that a non-
            integrated-service hop was found; see Section 3.8.
       o    Preemption Upcall
            Upcall: TC_Preempt() -> RHandle, Reason_code
            In order to grant a new reservation request, the admission
            control and/or policy control modules may preempt one or
            more existing reservations.  This will trigger a
            TC_Preempt() upcall to RSVP for each preempted
            reservation, passing the RHandle of the reservation and a
            sub-code indicating the reason.
    3.11.3 RSVP/Policy Control Interface
       This interface will be specified in a future document.
    3.11.4 RSVP/Routing Interface
       An RSVP implementation needs the following support from the
       routing mechanisms of the node.
       o    Route Query
            To forward Path and PathTear messages, an RSVP process
            must be able to query the routing process(s) for routes.
               Ucast_Route_Query( [ SrcAddress, ] DestAddress,
                                   Notify_flag ) -> OutInterface
               Mcast_Route_Query( [ SrcAddress, ] DestAddress,

Braden, Ed., et. al. Standards Track [Page 72] RFC 2205 RSVP September 1997

                                   Notify_flag )
  1. > [ IncInterface, ] OutInterface_list
            Depending upon the routing protocol, the query may or may
            not depend upon SrcAddress, i.e., upon the sender host IP
            address, which is also the IP source address of the
            message.  Here IncInterface is the interface through which
            the packet is expected to arrive; some multicast routing
            protocols may not provide it.  If the Notify_flag is True,
            routing will save state necessary to issue unsolicited
            route change notification callbacks (see below) whenever
            the specified route changes.
            A multicast route query may return an empty
            OutInterface_list if there are no receivers downstream of
            a particular router.  A route query may also return a `No
            such route' error, probably as a result of a transient
            inconsistency in the routing (since a Path or PathTear
            message for the requested route did arrive at this node).
            In either case, the local state should be updated as
            requested by the message, which cannot be forwarded
            further.  Updating local state will make path state
            available immediately for a new local receiver, or it will
            tear down path state immediately.
       o    Route Change Notification
            If requested by a route query with the Notify_flag True,
            the routing process may provide an asynchronous callback
            to the RSVP process that a specified route has changed.
               Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
                                              OutInterface
               Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
                             [ IncInterface, ] OutInterface_list
       o    Interface List Discovery
            RSVP must be able to learn what real and virtual
            interfaces are active, with their IP addresses.

Braden, Ed., et. al. Standards Track [Page 73] RFC 2205 RSVP September 1997

            It should be possible to logically disable an interface
            for RSVP.  When an interface is disabled for RSVP, a Path
            message should never be forwarded out that interface, and
            if an RSVP message is received on that interface, the
            message should be silently discarded (perhaps with local
            logging).
    3.11.5 RSVP/Packet I/O Interface
       An RSVP implementation needs the following support from the
       packet I/O and forwarding mechanisms of the node.
       o    Promiscuous Receive Mode for RSVP Messages
            Packets received for IP protocol 46 but not addressed to
            the node must be diverted to the RSVP program for
            processing, without being forwarded.  The RSVP messages to
            be diverted in this manner will include Path, PathTear,
            and ResvConf messages.  These message types carry the
            Router Alert IP option, which can be used to pick them out
            of a high-speed forwarding path.  Alternatively, the node
            can intercept all protocol 46 packets.
            On a router or multi-homed host, the identity of the
            interface (real or virtual) on which a diverted message is
            received, as well as the IP source address and IP TTL with
            which it arrived, must also be available to the RSVP
            process.
       o    Outgoing Link Specification
            RSVP must be able to force a (multicast) datagram to be
            sent on a specific outgoing real or virtual link,
            bypassing the normal routing mechanism.  A virtual link
            might be a multicast tunnel, for example.  Outgoing link
            specification is necessary to send different versions of
            an outgoing Path message on different interfaces, and to
            avoid routing loops in some cases.
       o    Source Address and TTL Specification
            RSVP must be able to specify the IP source address and IP
            TTL to be used when sending Path messages.
       o    Router Alert
            RSVP must be able to cause Path, PathTear, and ResvConf
            message to be sent with the Router Alert IP option.

Braden, Ed., et. al. Standards Track [Page 74] RFC 2205 RSVP September 1997

    3.11.6 Service-Dependent Manipulations
       Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP;
       their contents are defined in service specification documents.
       In order to manipulate these objects, RSVP process must have
       available to it the following service-dependent routines.
       o    Compare Flowspecs
               Compare_Flowspecs( Flowspec_1, Flowspec_2 ) ->
                                                      result_code
            The possible result_codes indicate: flowspecs are equal,
            Flowspec_1 is greater, Flowspec_2 is greater, flowspecs
            are incomparable but LUB can be computed, or flowspecs are
            incompatible.
            Note that comparing two flowspecs implicitly compares the
            Tspecs that are contained.  Although the RSVP process
            cannot itself parse a flowspec to extract the Tspec, it
            can use the Compare_Flowspecs call to implicitly calculate
            Resv_Te (see Section 2.2).
       o    Compute LUB of Flowspecs
               LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
                                                   Flowspec_LUB
       o    Compute GLB of Flowspecs
               GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
                                                   Flowspec_GLB
       o    Compare Tspecs
               Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code

Braden, Ed., et. al. Standards Track [Page 75] RFC 2205 RSVP September 1997

            The possible result_codes indicate: Tspecs are equal, or
            Tspecs are unequal.
       o    Sum Tspecs
               Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum
            This call is used to compute Path_Te (see Section 2.2).

4. Acknowledgments

 The design of RSVP is based upon research performed in 1992-1993 by a
 collaboration including Lixia Zhang (UCLA), Deborah Estrin
 (USC/ISI), Scott Shenker (Xerox PARC), Sugih Jamin (USC/Xerox PARC),
 and Daniel Zappala (USC).  Sugih Jamin developed the first prototype
 implementation of RSVP and successfully demonstrated it in May 1993.
 Shai Herzog, and later Steve Berson, continued development of RSVP
 prototypes.
 Since 1993, many members of the Internet research community have
 contributed to the design and development of RSVP; these include (in
 alphabetical order) Steve Berson, Bob Braden, Lee Breslau, Dave
 Clark, Deborah Estrin, Shai Herzog, Craig Partridge, Scott Shenker,
 John Wroclawski, Daniel Zappala, and Lixia Zhang.  In addition, a
 number of host and router vendors have made valuable contributions to
 the RSVP documents, particularly Fred Baker (Cisco), Mark Baugher
 (Intel), Lou Berger (Fore Systems), Don Hoffman (Sun), Steve Jakowski
 (NetManage), John Krawczyk (Bay Networks), and Bill Nowicki (SGI), as
 well as many others.

Braden, Ed., et. al. Standards Track [Page 76] RFC 2205 RSVP September 1997

APPENDIX A. Object Definitions

 C-Types are defined for the two Internet address families IPv4 and
 IPv6.  To accommodate other address families, additional C-Types
 could easily be defined.  These definitions are contained as an
 Appendix, to ease updating.
 All unused fields should be sent as zero and ignored on receipt.
 A.1 SESSION Class
    SESSION Class = 1.
    o    IPv4/UDP SESSION object: Class = 1, C-Type = 1
         +-------------+-------------+-------------+-------------+
         |             IPv4 DestAddress (4 bytes)                |
         +-------------+-------------+-------------+-------------+
         | Protocol Id |    Flags    |          DstPort          |
         +-------------+-------------+-------------+-------------+
    o    IPv6/UDP SESSION object: Class = 1, C-Type = 2
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +               IPv6 DestAddress (16 bytes)             +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+
         | Protocol Id |     Flags   |          DstPort          |
         +-------------+-------------+-------------+-------------+
    DestAddress
         The IP unicast or multicast destination address of the
         session.  This field must be non-zero.
    Protocol Id
         The IP Protocol Identifier for the data flow.  This field
         must be non-zero.

Braden, Ed., et. al. Standards Track [Page 77] RFC 2205 RSVP September 1997

    Flags
         0x01 = E_Police flag
              The E_Police flag is used in Path messages to determine
              the effective "edge" of the network, to control traffic
              policing.  If the sender host is not itself capable of
              traffic policing, it will set this bit on in Path
              messages it sends.  The first node whose RSVP is capable
              of traffic policing will do so (if appropriate to the
              service) and turn the flag off.
    DstPort
         The UDP/TCP destination port for the session.  Zero may be
         used to indicate `none'.
         Other SESSION C-Types could be defined in the future to
         support other demultiplexing conventions in the transport-
         layer or application layer.

Braden, Ed., et. al. Standards Track [Page 78] RFC 2205 RSVP September 1997

 A.2 RSVP_HOP Class
    RSVP_HOP class = 3.
    o    IPv4 RSVP_HOP object: Class = 3, C-Type = 1
         +-------------+-------------+-------------+-------------+
         |             IPv4 Next/Previous Hop Address            |
         +-------------+-------------+-------------+-------------+
         |                 Logical Interface Handle              |
         +-------------+-------------+-------------+-------------+
    o    IPv6 RSVP_HOP object: Class = 3, C-Type = 2
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +             IPv6 Next/Previous Hop Address            +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+
         |                Logical Interface Handle               |
         +-------------+-------------+-------------+-------------+
    This object carries the IP address of the interface through which
    the last RSVP-knowledgeable hop forwarded this message.  The
    Logical Interface Handle (LIH) is used to distinguish logical
    outgoing interfaces, as discussed in Sections 3.3 and 3.9.  A node
    receiving an LIH in a Path message saves its value and returns it
    in the HOP objects of subsequent Resv messages sent to the node
    that originated the LIH.  The LIH should be identically zero if
    there is no logical interface handle.

Braden, Ed., et. al. Standards Track [Page 79] RFC 2205 RSVP September 1997

 A.3 INTEGRITY Class
    INTEGRITY class = 4.
    See [Baker96].
 A.4 TIME_VALUES Class
    TIME_VALUES class = 5.
    o    TIME_VALUES Object: Class = 5, C-Type = 1
         +-------------+-------------+-------------+-------------+
         |                   Refresh Period R                    |
         +-------------+-------------+-------------+-------------+
    Refresh Period
         The refresh timeout period R used to generate this message;
         in milliseconds.

Braden, Ed., et. al. Standards Track [Page 80] RFC 2205 RSVP September 1997

 A.5 ERROR_SPEC Class
    ERROR_SPEC class = 6.
    o    IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
         +-------------+-------------+-------------+-------------+
         |            IPv4 Error Node Address (4 bytes)          |
         +-------------+-------------+-------------+-------------+
         |    Flags    |  Error Code |        Error Value        |
         +-------------+-------------+-------------+-------------+
    o    IPv6 ERROR_SPEC object: Class = 6, C-Type = 2
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +           IPv6 Error Node Address (16 bytes)          +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+
         |    Flags    |  Error Code |        Error Value        |
         +-------------+-------------+-------------+-------------+
    Error Node Address
         The IP address of the node in which the error was detected.
    Flags
         0x01 = InPlace
              This flag is used only for an ERROR_SPEC object in a
              ResvErr message.  If it on, this flag indicates that
              there was, and still is, a reservation in place at the
              failure point.
         0x02 = NotGuilty
              This flag is used only for an ERROR_SPEC object in a
              ResvErr message, and it is only set in the interface to

Braden, Ed., et. al. Standards Track [Page 81] RFC 2205 RSVP September 1997

              the receiver application.  If it on, this flag indicates
              that the FLOWSPEC that failed was strictly greater than
              the FLOWSPEC requested by this receiver.
    Error Code
         A one-octet error description.
    Error Value
         A two-octet field containing additional information about the
              error.  Its contents depend upon the Error Type.
    The values for Error Code and Error Value are defined in Appendix
    B.

Braden, Ed., et. al. Standards Track [Page 82] RFC 2205 RSVP September 1997

 A.6 SCOPE Class
    SCOPE class = 7.
    This object contains a list of IP addresses, used for routing
    messages with wildcard scope without loops.  The addresses must be
    listed in ascending numerical order.
    o    IPv4 SCOPE List object: Class = 7, C-Type = 1
         +-------------+-------------+-------------+-------------+
         |                IPv4 Src Address (4 bytes)             |
         +-------------+-------------+-------------+-------------+
         //                                                      //
         +-------------+-------------+-------------+-------------+
         |                IPv4 Src Address (4 bytes)             |
         +-------------+-------------+-------------+-------------+
    o    IPv6  SCOPE list object: Class = 7, C-Type = 2
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +                IPv6 Src Address (16 bytes)            +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+
         //                                                      //
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +                IPv6 Src Address (16 bytes)            +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+

Braden, Ed., et. al. Standards Track [Page 83] RFC 2205 RSVP September 1997

 A.7 STYLE Class
    STYLE class = 8.
    o    STYLE object: Class = 8, C-Type = 1
         +-------------+-------------+-------------+-------------+
         |   Flags     |              Option Vector              |
         +-------------+-------------+-------------+-------------+
    Flags: 8 bits
         (None assigned yet)
    Option Vector: 24 bits
         A set of bit fields giving values for the reservation
         options.  If new options are added in the future,
         corresponding fields in the option vector will be assigned
         from the least-significant end.  If a node does not recognize
         a style ID, it may interpret as much of the option vector as
         it can, ignoring new fields that may have been defined.
         The option vector bits are assigned (from the left) as
         follows:
         19 bits: Reserved
         2 bits: Sharing control
              00b: Reserved
              01b: Distinct reservations
              10b: Shared reservations
              11b: Reserved
         3 bits: Sender selection control
              000b: Reserved
              001b: Wildcard
              010b: Explicit

Braden, Ed., et. al. Standards Track [Page 84] RFC 2205 RSVP September 1997

              011b - 111b: Reserved
    The low order bits of the option vector are determined by the
    style, as follows:
            WF 10001b
            FF 01010b
            SE 10010b

Braden, Ed., et. al. Standards Track [Page 85] RFC 2205 RSVP September 1997

 A.8 FLOWSPEC Class
    FLOWSPEC class = 9.
    o    Reserved (obsolete) flowspec object: Class = 9, C-Type = 1
    o    Inv-serv Flowspec object: Class = 9, C-Type = 2
         The contents and encoding rules for this object are specified
         in documents prepared by the int-serv working group [RFC
         2210].

Braden, Ed., et. al. Standards Track [Page 86] RFC 2205 RSVP September 1997

 A.9 FILTER_SPEC Class
    FILTER_SPEC class = 10.
    o    IPv4 FILTER_SPEC object: Class = 10, C-Type = 1
         +-------------+-------------+-------------+-------------+
         |               IPv4 SrcAddress (4 bytes)               |
         +-------------+-------------+-------------+-------------+
         |    //////   |    //////   |          SrcPort          |
         +-------------+-------------+-------------+-------------+
    o    IPv6 FILTER_SPEC object: Class = 10, C-Type = 2
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +               IPv6 SrcAddress (16 bytes)              +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+
         |    //////   |    //////   |          SrcPort          |
         +-------------+-------------+-------------+-------------+
    o    IPv6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +               IPv6 SrcAddress (16 bytes)              +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+
         |   ///////   |         Flow Label (24 bits)            |
         +-------------+-------------+-------------+-------------+
    SrcAddress
         The IP source address for a sender host.  Must be non-zero.

Braden, Ed., et. al. Standards Track [Page 87] RFC 2205 RSVP September 1997

    SrcPort
         The UDP/TCP source port for a sender, or zero to indicate
         `none'.
    Flow Label
         A 24-bit Flow Label, defined in IPv6.  This value may be used
         by the packet classifier to efficiently identify the packets
         belonging to a particular (sender->destination) data flow.

Braden, Ed., et. al. Standards Track [Page 88] RFC 2205 RSVP September 1997

 A.10 SENDER_TEMPLATE Class
    SENDER_TEMPLATE class = 11.
    o    IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 1
         Definition same as IPv4/UDP FILTER_SPEC object.
    o    IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 2
         Definition same as IPv6/UDP FILTER_SPEC object.
    o    IPv6 Flow-label SENDER_TEMPLATE object: Class = 11, C-Type =
         3
 A.11 SENDER_TSPEC Class
    SENDER_TSPEC class = 12.
    o    Intserv SENDER_TSPEC object: Class = 12, C-Type = 2
         The contents and encoding rules for this object are specified
         in documents prepared by the int-serv working group.
 A.12 ADSPEC Class
    ADSPEC class = 13.
    o    Intserv ADSPEC object: Class = 13, C-Type = 2
         The contents and format for this object are specified in
         documents prepared by the int-serv working group.

Braden, Ed., et. al. Standards Track [Page 89] RFC 2205 RSVP September 1997

 A.13 POLICY_DATA Class
    POLICY_DATA class = 14.
    o    Type 1 POLICY_DATA object: Class = 14, C-Type = 1
         The contents of this object are for further study.

Braden, Ed., et. al. Standards Track [Page 90] RFC 2205 RSVP September 1997

 A.14 Resv_CONFIRM Class
    RESV_CONFIRM class = 15.
    o    IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1
         +-------------+-------------+-------------+-------------+
         |            IPv4 Receiver Address (4 bytes)            |
         +-------------+-------------+-------------+-------------+
    o    IPv6 RESV_CONFIRM object: Class = 15, C-Type = 2
         +-------------+-------------+-------------+-------------+
         |                                                       |
         +                                                       +
         |                                                       |
         +            IPv6 Receiver Address (16 bytes)           +
         |                                                       |
         +                                                       +
         |                                                       |
         +-------------+-------------+-------------+-------------+

Braden, Ed., et. al. Standards Track [Page 91] RFC 2205 RSVP September 1997

APPENDIX B. Error Codes and Values

 The following Error Codes may appear in ERROR_SPEC objects and be
 passed to end systems.  Except where noted, these Error Codes may
 appear only in ResvErr messages.
 o    Error Code = 00: Confirmation
      This code is reserved for use in the ERROR_SPEC object of a
      ResvConf message.  The Error Value will also be zero.
 o    Error Code = 01: Admission Control failure
      Reservation request was rejected by Admission Control due to
      unavailable resources.
      For this Error Code, the 16 bits of the Error Value field are:
         ssur cccc cccc cccc
      where the bits are:
      ss = 00: Low order 12 bits contain a globally-defined sub-code
           (values listed below).
      ss = 10: Low order 12 bits contain a organization-specific sub-
           code.  RSVP is not expected to be able to interpret this
           except as a numeric value.
      ss = 11: Low order 12 bits contain a service-specific sub-code.
           RSVP is not expected to be able to interpret this except as
           a numeric value.
           Since the traffic control mechanism might substitute a
           different service, this encoding may include some
           representation of the service in use.
           u = 0: RSVP rejects the message without updating local
           state.
      u = 1: RSVP may use message to update local state and forward
           the message.  This means that the message is informational.

Braden, Ed., et. al. Standards Track [Page 92] RFC 2205 RSVP September 1997

      r: Reserved bit, should be zero.
      cccc cccc cccc: 12 bit code.
      The following globally-defined sub-codes may appear in the low-
      order 12 bits when ssur = 0000:
  1. Sub-code = 1: Delay bound cannot be met
  1. Sub-code = 2: Requested bandwidth unavailable
  1. Sub-code = 3: MTU in flowspec larger than interface MTU.
 o    Error Code = 02: Policy Control failure
      Reservation or path message has been rejected for administrative
      reasons, for example, required credentials not submitted,
      insufficient quota or balance, or administrative preemption.
      This Error Code may appear in a PathErr or ResvErr message.
      Contents of the Error Value field are to be determined in the
      future.
 o    Error Code = 03: No path information for this Resv message.
      No path state for this session.  Resv message cannot be
      forwarded.
 o    Error Code = 04: No sender information for this Resv message.
      There is path state for this session, but it does not include
      the sender matching some flow descriptor contained in the Resv
      message.  Resv message cannot be forwarded.
 o    Error Code = 05: Conflicting reservation style
      Reservation style conflicts with style(s) of existing
      reservation state.  The Error Value field contains the low-order
      16 bits of the Option Vector of the existing style with which
      the conflict occurred.  This Resv message cannot be forwarded.
 o    Error Code = 06: Unknown reservation style
      Reservation style is unknown.  This Resv message cannot be
      forwarded.

Braden, Ed., et. al. Standards Track [Page 93] RFC 2205 RSVP September 1997

 o    Error Code = 07: Conflicting dest ports
      Sessions for same destination address and protocol have appeared
      with both zero and non-zero dest port fields.  This Error Code
      may appear in a PathErr or ResvErr message.
 o    Error Code = 08: Conflicting sender ports
      Sender port is both zero and non-zero in Path messages for the
      same session.  This Error Code may appear only in a PathErr
      message.
 o    Error Code = 09, 10, 11: (reserved)
 o    Error Code = 12: Service preempted
      The service request defined by the STYLE object and the flow
      descriptor has been administratively preempted.
      For this Error Code, the 16 bits of the Error Value field are:
         ssur cccc cccc cccc
      Here the high-order bits ssur are as defined under Error Code
      01.  The globally-defined sub-codes that may appear in the low-
      order 12 bits when ssur = 0000 are to be defined in the future.
 o    Error Code = 13: Unknown object class
      Error Value contains 16-bit value composed of (Class-Num, C-
      Type) of unknown object.  This error should be sent only if RSVP
      is going to reject the message, as determined by the high-order
      bits of the Class-Num.  This Error Code may appear in a PathErr
      or ResvErr message.
 o    Error Code = 14: Unknown object C-Type
      Error Value contains 16-bit value composed of (Class-Num, C-
      Type) of object.
 o    Error Code = 15-19: (reserved)
 o    Error Code = 20: Reserved for API
      Error Value field contains an API error code, for an API error
      that was detected asynchronously and must be reported via an
      upcall.

Braden, Ed., et. al. Standards Track [Page 94] RFC 2205 RSVP September 1997

 o    Error Code = 21: Traffic Control Error
      Traffic Control call failed due to the format or contents of the
      parameters to the request.  The Resv or Path message that caused
      the call cannot be forwarded, and repeating the call would be
      futile.
      For this Error Code, the 16 bits of the Error Value field are:
         ss00 cccc cccc cccc
      Here the high-order bits ss are as defined under Error Code 01.
      The following globally-defined sub-codes may appear in the low
      order 12 bits (cccc cccc cccc) when ss = 00:
  1. Sub-code = 01: Service conflict
           Trying to merge two incompatible service requests.
  1. Sub-code = 02: Service unsupported
           Traffic control can provide neither the requested service
           nor an acceptable replacement.
  1. Sub-code = 03: Bad Flowspec value
           Malformed or unreasonable request.
  1. Sub-code = 04: Bad Tspec value
           Malformed or unreasonable request.
  1. Sub-code = 05: Bad Adspec value
           Malformed or unreasonable request.
 o    Error Code = 22: Traffic Control System error
      A system error was detected and reported by the traffic control
      modules.  The Error Value will contain a system-specific value
      giving more information about the error.  RSVP is not expected
      to be able to interpret this value.

Braden, Ed., et. al. Standards Track [Page 95] RFC 2205 RSVP September 1997

 o    Error Code = 23: RSVP System error
      The Error Value field will provide implementation-dependent
      information on the error.  RSVP is not expected to be able to
      interpret this value.
 In general, every RSVP message is rebuilt at each hop, and the node
 that creates an RSVP message is responsible for its correct
 construction.  Similarly, each node is required to verify the correct
 construction of each RSVP message it receives.  Should a programming
 error allow an RSVP to create a malformed message, the error is not
 generally reported to end systems in an ERROR_SPEC object; instead,
 the error is simply logged locally, and perhaps reported through
 network management mechanisms.
 The only message formatting errors that are reported to end systems
 are those that may reflect version mismatches, and which the end
 system might be able to circumvent, e.g., by falling back to a
 previous CType for an object; see code 13 and 14 above.
 The choice of message formatting errors that an RSVP may detect and
 log locally is implementation-specific, but it will typically include
 the following:
 o    Wrong-length message: RSVP Length field does not match message
      length.
 o    Unknown or unsupported RSVP version.
 o    Bad RSVP checksum
 o    INTEGRITY failure
 o    Illegal RSVP message Type
 o    Illegal object length: not a multiple of 4, or less than 4.
 o    Next hop/Previous hop address in HOP object is illegal.
 o    Bad source port: Source port is non-zero in a filter spec or
      sender template for a session with destination port zero.
 o    Required object class (specify) missing
 o    Illegal object class (specify) in this message type.
 o    Violation of required object order

Braden, Ed., et. al. Standards Track [Page 96] RFC 2205 RSVP September 1997

 o    Flow descriptor count wrong for style or message type
 o    Logical Interface Handle invalid
 o    Unknown object Class-Num.
 o    Destination address of ResvConf message does not match Receiver
      Address in the RESV_CONFIRM object it contains.

Braden, Ed., et. al. Standards Track [Page 97] RFC 2205 RSVP September 1997

APPENDIX C. UDP Encapsulation

 An RSVP implementation will generally require the ability to perform
 "raw" network I/O, i.e., to send and receive IP datagrams using
 protocol 46.  However, some important classes of host systems may not
 support raw network I/O.  To use RSVP, such hosts must encapsulate
 RSVP messages in UDP.
 The basic UDP encapsulation scheme makes two assumptions:
 1.   All hosts are capable of sending and receiving multicast packets
      if multicast destinations are to be supported.
 2.   The first/last-hop routers are RSVP-capable.
 A method of relaxing the second assumption is given later.
 Let Hu be a "UDP-only" host that requires UDP encapsulation, and Hr a
 host that can do raw network I/O.  The UDP encapsulation scheme must
 allow RSVP interoperation among an arbitrary topology of Hr hosts, Hu
 hosts, and routers.
 Resv, ResvErr, ResvTear, and PathErr messages are sent to unicast
 addresses learned from the path or reservation state in the node.  If
 the node keeps track of which previous hops and which interfaces need
 UDP encapsulation, these messages can be sent using UDP encapsulation
 when necessary.  On the other hand, Path and PathTear messages are
 sent to the destination address for the session, which may be unicast
 or multicast.
 The tables in Figures 13 and 14 show the basic rules for UDP
 encapsulation of Path and PathTear messages, for unicast DestAddress
 and multicast DestAddress, respectively.  The other message types,
 which are sent unicast, should follow the unicast rules in Figure 13.
 Under the `RSVP Send' columns in these figures, the notation is
 `mode(destaddr, destport)'; destport is omitted for raw packets.  The
 `Receive' columns show the group that is joined and, where relevant,
 the UDP Listen port.
 It is useful to define two flavors of UDP encapsulation, one to be
 sent by Hu and the other to be sent by Hr and R, to avoid double
 processing by the recipient.  In practice, these two flavors are
 distinguished by differing UDP port numbers Pu and Pu'.

Braden, Ed., et. al. Standards Track [Page 98] RFC 2205 RSVP September 1997

 The following symbols are used in the tables.
 o    D is the DestAddress for the particular session.
 o    G* is a well-known group address of the form 224.0.0.14, i.e., a
      group that is limited to the local connected network.
 o    Pu and Pu' are two well-known UDP ports for UDP encapsulation of
      RSVP, with values 1698 and 1699.
 o    Ra is the IP address of the router interface `a'.
 o    Router interface `a' is on the local network connected to Hu and
      Hr.
 o
 The following notes apply to these figures:
    [Note 1] Hu sends a unicast Path message either to the destination
    address D, if D is local, or to the address Ra of the first-hop
    router.  Ra is presumably known to the host.
    [Note 2] Here D is the address of the local interface through
    which the message arrived.
    [Note 3] This assumes that the application has joined the group D.

Braden, Ed., et. al. Standards Track [Page 99] RFC 2205 RSVP September 1997

 UNICAST DESTINATION D:
                 RSVP               RSVP
 Node            Send               Receive
 ___       _____________          _______________
 Hu         UDP(D/Ra,Pu)          UDP(D,Pu)
               [Note 1]       and UDP(D,Pu')
                                     [Note 2]
 Hr         Raw(D)                Raw()
             and if (UDP)     and UDP(D, Pu)
             then UDP(D,Pu')         [Note 2]
                                  (Ignore Pu')
 R (Interface a):
            Raw(D)                Raw()
             and if (UDP)     and UDP(Ra, Pu)
             then UDP(D,Pu')      (Ignore Pu')
 Figure 13: UDP Encapsulation Rules for Unicast Path and Resv Messages
 MULTICAST DESTINATION D:
                RSVP                    RSVP
 Node           Send                    Receive
 ___           _____________        _________________
 Hu             UDP(G*,Pu)              UDP(D,Pu')
                                            [Note 3]
                                    and UDP(G*,Pu)
 Hr             Raw(D,Tr)               Raw()
                 and if (UDP)       and UDP(G*,Pu)
                   then UDP(D,Pu')     (Ignore Pu')
 R (Interface a):
                Raw(D,Tr)               Raw()
                 and if (UDP)       and UDP(G*,Pu)
                   then UDP(D,Pu')     (Ignore Pu')
    Figure 14: UDP Encapsulation Rules for Multicast Path Messages

Braden, Ed., et. al. Standards Track [Page 100] RFC 2205 RSVP September 1997

 A router may determine if its interface X needs UDP encapsulation by
 listening for UDP-encapsulated Path messages that were sent to either
 G* (multicast D) or to the address of interface X (unicast D).  There
 is one failure mode for this scheme:  if no host on the connected
 network acts as an RSVP sender, there will be no Path messages to
 trigger UDP encapsulation.  In this (unlikely) case, it will be
 necessary to explicitly configure UDP encapsulation on the local
 network interface of the router.
 When a UDP-encapsulated packet is received, the IP TTL is not
 available to the application on most systems.  The RSVP process that
 receives a UDP-encapsulated Path or PathTear message should therefore
 use the Send_TTL field of the RSVP common header as the effective
 receive TTL.  This may be overridden by manual configuration.
 We have assumed that the first-hop RSVP-capable router R is on the
 directly-connected network.  There are several possible approaches if
 this is not the case.
 1.   Hu can send both unicast and multicast sessions to UDP(Ra,Pu)
      with TTL=Ta
      Here Ta must be the TTL to exactly reach R.  If Ta is too small,
      the Path message will not reach R.  If Ta is too large, R and
      succeeding routers may forward the UDP packet until its hop
      count expires.  This will turn on UDP encapsulation between
      routers within the Internet, perhaps causing bogus UDP traffic.
      The host Hu must be explicitly configured with Ra and Ta.
 2.   A particular host on the LAN connected to Hu could be designated
      as an "RSVP relay host".  A relay host would listen on (G*,Pu)
      and forward any Path messages directly to R, although it would
      not be in the data path.  The relay host would have to be
      configured with Ra and Ta.

Braden, Ed., et. al. Standards Track [Page 101] RFC 2205 RSVP September 1997

APPENDIX D. Glossary

 o    Admission control
      A traffic control function that decides whether the packet
      scheduler in the node can supply the requested QoS while
      continuing to provide the QoS requested by previously-admitted
      requests.  See also "policy control" and "traffic control".
 o    Adspec
      An Adspec is a data element (object) in a Path message that
      carries a package of OPWA advertising information.  See "OPWA".
 o    Auto-refresh loop
      An auto-refresh loop is an error condition that occurs when a
      topological loop of routers continues to refresh existing
      reservation state even though all receivers have stopped
      requesting these reservations.  See section 3.4 for more
      information.
 o    Blockade state
      Blockade state helps to solve a "killer reservation" problem.
      See sections 2.5 and 3.5, and "killer reservation".
 o    Branch policing
      Traffic policing at a multicast branching point on an outgoing
      interface that has "less" resources reserved than another
      outgoing interface for the same flow.  See "traffic policing".
 o    C-Type
      The class type of an object; unique within class-name.  See
      "class-name".
 o    Class-name
      The class of an object.  See "object".
 o    DestAddress
      The IP destination address; part of session identification.  See
      "session".

Braden, Ed., et. al. Standards Track [Page 102] RFC 2205 RSVP September 1997

 o    Distinct style
      A (reservation) style attribute; separate resources are reserved
      for each different sender.  See also "shared style".
 o    Downstream
      Towards the data receiver(s).
 o    DstPort
      The IP (generalized) destination port used as part of a session.
      See "generalized destination port".
 o    Entry policing
      Traffic policing done at the first RSVP- (and policing-) capable
      router on a data path.
 o    ERROR_SPEC
      Object that carries the error report in a PathErr or ResvErr
      message.
 o    Explicit sender selection
      A (reservation) style attribute; all reserved senders are to be
      listed explicitly in the reservation message.  See also
      "wildcard sender selection".
 o    FF style
      Fixed Filter reservation style, which has explicit sender
      selection and distinct attributes.
 o    FilterSpec
      Together with the session information, defines the set of data
      packets to receive the QoS specified in a flowspec.  The
      filterspec is used to set parameters in the packet classifier
      function.  A filterspec may be carried in a FILTER_SPEC or
      SENDER_TEMPLATE object.
 o    Flow descriptor
      The combination of a flowspec and a filterspec.

Braden, Ed., et. al. Standards Track [Page 103] RFC 2205 RSVP September 1997

 o    Flowspec
      Defines the QoS to be provided for a flow.  The flowspec is used
      to set parameters in the packet scheduling function to provide
      the requested quality of service.  A flowspec is carried in a
      FLOWSPEC object.  The flowspec format is opaque to RSVP and is
      defined by the Integrated Services Working Group.
 o    Generalized destination port
      The component of a session definition that provides further
      transport or application protocol layer demultiplexing beyond
      DestAddress.  See "session".
 o    Generalized source port
      The component of a filter spec that provides further transport
      or application protocol layer demultiplexing beyond the sender
      address.
 o    GLB
      Greatest Lower Bound
 o    Incoming interface
      The interface on which data packets are expected to arrive, and
      on which Resv messages are sent.
 o    INTEGRITY
      Object of an RSVP control message that contains cryptographic
      data to authenticate the originating node and to verify the
      contents of an RSVP message.
 o    Killer reservation problem
      The killer reservation problem describes a case where a receiver
      attempting and failing to make a large QoS reservation prevents
      smaller QoS reservations from being established.  See Sections
      2.5 and 3.5 for more information.
 o    LIH
      The LIH (Logical Interface Handle) is used to help deal with
      non-RSVP clouds.  See Section 2.9 for more information.

Braden, Ed., et. al. Standards Track [Page 104] RFC 2205 RSVP September 1997

 o    Local repair
      Allows RSVP to rapidly adapt its reservations to changes in
      routing.  See Section 3.6 for more information.
 o    LPM
      Local Policy Module. the function that exerts policy control.
 o    LUB
      Least Upper Bound.
 o    Merge policing
      Traffic policing that takes place at data merge point of a
      shared reservation.
 o    Merging
      The process of taking the maximum (or more generally the least
      upper bound) of the reservations arriving on outgoing
      interfaces, and forwarding this maximum on the incoming
      interface.  See Section 2.2 for more information.
 o    MTU
      Maximum Transmission Unit.
 o    Next hop
      The next router in the direction of traffic flow.
 o    NHOP
      An object that carries the Next Hop information in RSVP control
      messages.
 o    Node
      A router or host system.
 o    Non-RSVP clouds
      Groups of hosts and routers that do not run RSVP.  Dealing with
      nodes that do not support RSVP is important for backwards
      compatibility.  See section 2.9.

Braden, Ed., et. al. Standards Track [Page 105] RFC 2205 RSVP September 1997

 o    Object
      An element of an RSVP control message; a type, length, value
      triplet.
 o    OPWA
      Abbreviation for "One Pass With Advertising".  Describes a
      reservation setup model in which (Path) messages sent downstream
      gather information that the receiver(s) can use to predict the
      end-to-end service.  The information that is gathered is called
      an advertisement.  See also "Adspec".
 o    Outgoing interface
      Interface through which data packets and Path messages are
      forwarded.
 o    Packet classifier
      Traffic control function in the primary data packet forwarding
      path that selects a service class for each packet, in accordance
      with the reservation state set up by RSVP.  The packet
      classifier may be combined with the routing function.  See also
      "traffic control".
 o    Packet scheduler
      Traffic control function in the primary data packet forwarding
      path that implements QoS for each flow, using one of the service
      models defined by the Integrated Services Working Group.  See
      also " traffic control".
 o    Path state
      Information kept in routers and hosts about all RSVP senders.
 o    PathErr
      Path Error RSVP control message.
 o    PathTear
      Path Teardown RSVP control message.

Braden, Ed., et. al. Standards Track [Page 106] RFC 2205 RSVP September 1997

 o    PHOP
      An object that carries the Previous Hop information in RSVP
      control messages.
 o    Police
      See traffic policing.
 o    Policy control
      A function that determines whether a new request for quality of
      service has administrative permission to make the requested
      reservation.  Policy control may also perform accounting (usage
      feedback) for a reservation.
 o    Policy data
      Data carried in a Path or Resv message and used as input to
      policy control to determine authorization and/or usage feedback
      for the given flow.
 o    Previous hop
      The previous router in the direction of traffic flow.  Resv
      messages flow towards previous hops.
 o    ProtocolId
      The component of session identification that specifies the IP
      protocol number used by the data stream.
 o    QoS
      Quality of Service.
 o    Reservation state
      Information kept in RSVP-capable nodes about successful RSVP
      reservation requests.
 o    Reservation style
      Describes a set of attributes for a reservation, including the
      sharing attributes and sender selection attributes.  See Section
      1.3 for details.

Braden, Ed., et. al. Standards Track [Page 107] RFC 2205 RSVP September 1997

 o    Resv message
      Reservation request RSVP control message.
 o    ResvConf
      Reservation Confirmation RSVP control message, confirms
      successful installation of a reservation at some upstream node.
 o    ResvErr
      Reservation Error control message, indicates that a reservation
      request has failed or an active reservation has been preempted.
 o    ResvTear
      Reservation Teardown RSVP control message, deletes reservation
      state.
 o    Rspec
      The component of a flowspec that defines a desired QoS.  The
      Rspec format is opaque to RSVP and is defined by the Integrated
      Services Working Group of the IETF.
 o    RSVP_HOP
      Object of an RSVP control message that carries the PHOP or NHOP
      address of the source of the message.
 o    Scope
      The set of sender hosts to which a given reservation request is
      to be propagated.
 o    SE style
      Shared Explicit reservation style, which has explicit sender
      selection and shared attributes.
 o    Semantic fragmentation
      A method of fragmenting a large RSVP message using information
      about the structure and contents of the message, so that each
      fragment is a logically complete RSVP message.

Braden, Ed., et. al. Standards Track [Page 108] RFC 2205 RSVP September 1997

 o    Sender template
      Parameter in a Path message that defines a sender; carried in a
      SENDER_TEMPLATE object.  It has the form of a filter spec that
      can be used to select this sender's packets from other packets
      in the same session on the same link.
 o    Sender Tspec
      Parameter in a Path message, a Tspec that characterizes the
      traffic parameters for the data flow from the corresponding
      sender.  It is carried in a SENDER_TSPEC object.
 o    Session
      An RSVP session defines one simplex unicast or multicast data
      flow for which reservations are required.  A session is
      identified by the destination address, transport-layer protocol,
      and an optional (generalized) destination port.
 o    Shared style
      A (reservation) style attribute: all reserved senders share the
      same reserved resources.  See also "distinct style".
 o    Soft state
      Control state in hosts and routers that will expire if not
      refreshed within a specified amount of time.
 o    STYLE
      Object of an RSVP message that specifies the desired reservation
      style.
 o    Style
      See "reservation style"
 o    TIME_VALUES
      Object in an RSVP control message that specifies the time period
      timer used for refreshing the state in this message.

Braden, Ed., et. al. Standards Track [Page 109] RFC 2205 RSVP September 1997

 o    Traffic control
      The entire set of machinery in the node that supplies requested
      QoS to data streams.  Traffic control includes packet
      classifier, packet scheduler, and admission control functions.
 o    Traffic policing
      The function, performed by traffic control, of forcing a given
      data flow into compliance with the traffic parameters implied by
      the reservation.  It may involve dropping non-compliant packets
      or sending them with lower priority, for example.
 o    TSpec
      A traffic parameter set that describes a flow.  The format of a
      Tspec is opaque to RSVP and is defined by the Integrated Service
      Working Group.
 o    UDP encapsulation
      A way for hosts that cannot use raw sockets to participate in
      RSVP by encapsulating the RSVP protocol (raw) packets in
      ordinary UDP packets.  See Section APPENDIX C for more
      information.
 o    Upstream
      Towards the traffic source.  RSVP Resv messages flow upstream.
 o    WF style
      Wildcard Filter reservation style, which has wildcard sender
      selection and shared attributes.
 o    Wildcard sender selection
      A (reservation) style attribute: traffic from any sender to a
      specific session receives the same QoS.  See also "explicit
      sender selection".

Braden, Ed., et. al. Standards Track [Page 110] RFC 2205 RSVP September 1997

References

[Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in

  Progress.

[RFC 1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services

  in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and
  PARC, June 1994.

[FJ94] Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing

  Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2,
  April, 1994.

[RFC 2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data

  Flows", RFC 2207, September 1997.

[RFC 2113] Katz, D., "IP Router Alert Option", RFC 2113, cisco Systems,

  February 1997.

[RFC 2210] Wroclawski, J., "The Use of RSVP with Integrated Services",

  RFC 2210, September 1997.

[PolArch96] Herzog, S., "Policy Control for RSVP: Architectural

  Overview".  Work in Progress.

[OPWA95] Shenker, S. and L. Breslau, "Two Issues in Reservation

  Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995.

[RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.

  Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network,
  September 1993.

Security Considerations

 See Section 2.8.

Braden, Ed., et. al. Standards Track [Page 111] RFC 2205 RSVP September 1997

Authors' Addresses

 Bob Braden
 USC Information Sciences Institute
 4676 Admiralty Way
 Marina del Rey, CA 90292
 Phone: (310) 822-1511
 EMail: Braden@ISI.EDU
 Lixia Zhang
 UCLA Computer Science Department
 4531G Boelter Hall
 Los Angeles, CA 90095-1596 USA
 Phone: 310-825-2695
 EMail: lixia@cs.ucla.edu
 Steve Berson
 USC Information Sciences Institute
 4676 Admiralty Way
 Marina del Rey, CA 90292
 Phone: (310) 822-1511
 EMail: Berson@ISI.EDU
 Shai Herzog
 IBM T. J. Watson Research Center
 P.O Box 704
 Yorktown Heights, NY 10598
 Phone: (914) 784-6059
 EMail: Herzog@WATSON.IBM.COM
 Sugih Jamin
 University of Michigan
 CSE/EECS
 1301 Beal Ave.
 Ann Arbor, MI 48109-2122
 Phone: (313) 763-1583
 EMail: jamin@EECS.UMICH.EDU

Braden, Ed., et. al. Standards Track [Page 112]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2205.txt · Last modified: 1997/09/30 19:47 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki