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 3 of 4 – Pages 47 to 76
First   Prev   Next

Top   ToC   RFC2205 - Page 47   prevText
   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
Top   ToC   RFC2205 - Page 48
      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.
Top   ToC   RFC2205 - Page 49
      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:
Top   ToC   RFC2205 - Page 50
      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.
Top   ToC   RFC2205 - Page 51
      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.
Top   ToC   RFC2205 - Page 52
      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.
Top   ToC   RFC2205 - Page 53
                         ________________
                      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,
Top   ToC   RFC2205 - Page 54
           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.
Top   ToC   RFC2205 - Page 55
      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.
Top   ToC   RFC2205 - Page 56
               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.
Top   ToC   RFC2205 - Page 57
   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
Top   ToC   RFC2205 - Page 58
           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
Top   ToC   RFC2205 - Page 59
           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.
Top   ToC   RFC2205 - Page 60
      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.
Top   ToC   RFC2205 - Page 61
           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.
Top   ToC   RFC2205 - Page 62
           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.
Top   ToC   RFC2205 - Page 63
   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 ] )
Top   ToC   RFC2205 - Page 64
              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:

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

              -    Source_Port

                   This is the UDP/TCP port from which the data will be
                   sent.

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

              -    Sender_Tspec

                   This parameter describes the traffic flow to be sent;
                   see [RFC 2210].

              -    Adspec

                   This parameter may be specified to initialize the
                   computation of QoS properties along the path; see
                   [RFC 2210].

              -    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.
Top   ToC   RFC2205 - Page 65
              -    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.
Top   ToC   RFC2205 - Page 66
         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.
Top   ToC   RFC2205 - Page 67
                   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,
Top   ToC   RFC2205 - Page 68
                                 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:

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

                   -    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,
Top   ToC   RFC2205 - Page 69
                                 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
Top   ToC   RFC2205 - Page 70
              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 )

                                        -> 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
Top   ToC   RFC2205 - Page 71
              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.
Top   ToC   RFC2205 - Page 72
         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,
Top   ToC   RFC2205 - Page 73
                                     Notify_flag )

                                 -> [ IncInterface, ] OutInterface_list


              Depending upon the routing protocol, the query may or may
              not depend upon SrcAddress, i.e., upon the sender host IP
              address, which is also the IP source address of the
              message.  Here IncInterface is the interface through which
              the packet is expected to arrive; some multicast routing
              protocols may not provide it.  If the Notify_flag is True,
              routing will save state necessary to issue unsolicited
              route change notification callbacks (see below) whenever
              the specified route changes.

              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.
Top   ToC   RFC2205 - Page 74
              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.
Top   ToC   RFC2205 - Page 75
      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
Top   ToC   RFC2205 - Page 76
              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.


(next page on part 4)

Next Section