Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2205

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

Pages: 112
Proposed Standard
Errata
Updated by:  275039364495594664376780
Part 4 of 4 – Pages 77 to 112
First   Prev   None

Top   ToC   RFC2205 - Page 77   prevText
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.
Top   ToC   RFC2205 - Page 78
      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.
Top   ToC   RFC2205 - Page 79
   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.
Top   ToC   RFC2205 - Page 80
   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.
Top   ToC   RFC2205 - Page 81
   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
Top   ToC   RFC2205 - Page 82
                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.
Top   ToC   RFC2205 - Page 83
   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)            +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
Top   ToC   RFC2205 - Page 84
   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
Top   ToC   RFC2205 - Page 85
                011b - 111b: Reserved

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

              WF 10001b
              FF 01010b
              SE 10010b
Top   ToC   RFC2205 - Page 86
   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].
Top   ToC   RFC2205 - Page 87
   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.
Top   ToC   RFC2205 - Page 88
      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.
Top   ToC   RFC2205 - Page 89
   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.
Top   ToC   RFC2205 - Page 90
   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.
Top   ToC   RFC2205 - Page 91
   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)           +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+-------------+
Top   ToC   RFC2205 - Page 92
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.
Top   ToC   RFC2205 - Page 93
        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:

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

        -    Sub-code = 2: Requested bandwidth unavailable

        -    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.
Top   ToC   RFC2205 - Page 94
   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.
Top   ToC   RFC2205 - Page 95
   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:

        -    Sub-code = 01: Service conflict

             Trying to merge two incompatible service requests.

        -    Sub-code = 02: Service unsupported

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

        -    Sub-code = 03: Bad Flowspec value

             Malformed or unreasonable request.

        -    Sub-code = 04: Bad Tspec value

             Malformed or unreasonable request.

        -    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.
Top   ToC   RFC2205 - Page 96
   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
Top   ToC   RFC2205 - Page 97
   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.
Top   ToC   RFC2205 - Page 98
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'.
Top   ToC   RFC2205 - Page 99
   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.
Top   ToC   RFC2205 - Page 100
   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
Top   ToC   RFC2205 - Page 101
   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.
Top   ToC   RFC2205 - Page 102
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".
Top   ToC   RFC2205 - Page 103
   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.
Top   ToC   RFC2205 - Page 104
   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.
Top   ToC   RFC2205 - Page 105
   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.
Top   ToC   RFC2205 - Page 106
   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.
Top   ToC   RFC2205 - Page 107
   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.
Top   ToC   RFC2205 - Page 108
   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.
Top   ToC   RFC2205 - Page 109
   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.
Top   ToC   RFC2205 - Page 110
   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".
Top   ToC   RFC2205 - Page 111
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.
Top   ToC   RFC2205 - Page 112
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