rfc2205.txt

中、英文RFC文档大全打包下载完全版 .

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


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

      The state maintained by RSVP is dynamic; to change the set of
      senders Si or to change any QoS request, a host simply starts
      sending revised Path and/or Resv messages.  The result will be an
      appropriate adjustment in the RSVP state in all nodes along the
      path; unused state will time out if it is not explicitly torn
      down.

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

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

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





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


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

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

                     Figure 10: Independent Reservations


   2.4 Teardown

      RSVP "teardown" messages remove path or reservation state
      immediately.  Although it is not necessary to explicitly tear down
      an old reservation, we recommend that all end hosts send a
      teardown request as soon as an application finishes.

      There are two types of RSVP teardown message, PathTear and
      ResvTear.  A PathTear message travels towards all receivers
      downstream from its point of initiation and deletes path state, as
      well as all dependent reservation state, along the way.  An
      ResvTear message deletes reservation state and travels towards all
      senders upstream from its point of initiation.  A PathTear
      (ResvTear) message may be conceptualized as a reversed-sense Path
      message (Resv message, respectively).

      A teardown request may be initiated either by an application in an
      end system (sender or receiver), or by a router as the result of
      state timeout or service preemption.  Once initiated, a teardown
      request must be forwarded hop-by-hop without delay.  A teardown
      message deletes the specified state in the node where it is
      received.  As always, this state change will be propagated
      immediately to the next node, but only if there will be a net
      change after merging.  As a result, a ResvTear message will prune
      the reservation state back (only) as far as possible.




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


      Like all other RSVP messages, teardown requests are not delivered
      reliably.  The loss of a teardown request message will not cause a
      protocol failure because the unused state will eventually time out
      even though it is not explicitly deleted.  If a teardown message
      is lost, the router that failed to receive that message will time
      out its state and initiate a new teardown message beyond the loss
      point.  Assuming that RSVP message loss probability is small, the
      longest time to delete state will seldom exceed one refresh
      timeout period.

      It should be possible to tear down any subset of the established
      state.  For path state, the granularity for teardown is a single
      sender.  For reservation state, the granularity is an individual
      filter spec.  For example, refer to Figure 7.  Receiver R1 could
      send a ResvTear message for sender S2 only (or for any subset of
      the filter spec list), leaving S1 in place.

      A ResvTear message specifies the style and filters; any flowspec
      is ignored.  Whatever flowspec is in place will be removed if all
      its filter specs are torn down.

   2.5 Errors

      There are two RSVP error messages, ResvErr and PathErr.  PathErr
      messages are very simple; they are simply sent upstream to the
      sender that created the error, and they do not change path state
      in the nodes though which they pass.  There are only a few
      possible causes of path errors.

      However, there are a number of ways for a syntactically valid
      reservation request to fail at some node along the path.  A node
      may also decide to preempt an established reservation.  The
      handling of ResvErr messages is somewhat complex (Section 3.5).
      Since a request that fails may be the result of merging a number
      of requests, a reservation error must be reported to all of the
      responsible receivers.  In addition, merging heterogeneous
      requests creates a potential difficulty known as the "killer
      reservation" problem, in which one request could deny service to
      another.  There are actually two killer-reservation problems.

      1.   The first killer reservation problem (KR-I) arises when there
           is already a reservation Q0 in place.  If another receiver
           now makes a larger reservation Q1 > Q0, the result of merging
           Q0 and Q1 may be rejected by admission control in some
           upstream node.  This must not deny service to Q0.






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


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

      2.   The second killer reservation problem (KR-II) is the
           converse: the receiver making a reservation Q1 is persistent
           even though Admission Control is failing for Q1 in some node.
           This must not prevent a different receiver from now
           establishing a smaller reservation Q0 that would succeed if
           not merged with Q1.

           To solve this problem, a ResvErr message establishes
           additional state, called "blockade state", in each node
           through which it passes.  Blockade state in a node modifies
           the merging procedure to omit the offending flowspec (Q1 in
           the example) from the merge, allowing a smaller request to be
           forwarded and established.  The Q1 reservation state is said
           to be "blockaded".  Detailed rules are presented in Section
           3.5.

      A reservation request that fails Admission Control creates
      blockade state but is left in place in nodes downstream of the
      failure point.  It has been suggested that these reservations
      downstream from the failure represent "wasted" reservations and
      should be timed out if not actively deleted.  However, the
      downstream reservations are left in place, for the following
      reasons:

      o    There are two possible reasons for a receiver persisting in a
           failed reservation: (1) it is polling for resource
           availability along the entire path, or (2) it wants to obtain
           the desired QoS along as much of the path as possible.
           Certainly in the second case, and perhaps in the first case,
           the receiver will want to hold onto the reservations it has
           made downstream from the failure.

      o    If these downstream reservations were not retained, the
           responsiveness of RSVP to certain transient failures would be
           impaired.  For example, suppose a route "flaps" to an
           alternate route that is congested, so an existing reservation
           suddenly fails, then quickly recovers to the original route.
           The blockade state in each downstream router must not remove
           the state or prevent its immediate refresh.

      o    If we did not refresh the downstream reservations, they might
           time out, to be restored every Tb seconds (where Tb is the
           blockade state timeout interval).  Such intermittent behavior
           might be very distressing for users.



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


   2.6 Confirmation

      To request a confirmation for its reservation request, a receiver
      Rj includes in the Resv message a confirmation-request object
      containing Rj's IP address.  At each merge point, only the largest
      flowspec and any accompanying confirmation-request object is
      forwarded upstream.  If the reservation request from Rj is equal
      to or smaller than the reservation in place on a node, its Resv is
      not forwarded further, and if the Resv included a confirmation-
      request object, a ResvConf message is sent back to Rj.  If the
      confirmation request is forwarded, it is forwarded immediately,
      and no more than once for each request.

      This confirmation mechanism has the following consequences:

      o    A new reservation request with a flowspec larger than any in
           place for a session will normally result in either a ResvErr
           or a ResvConf message back to the receiver from each sender.
           In this case, the ResvConf message will be an end-to-end
           confirmation.

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


   2.7 Policy Control

      RSVP-mediated QoS requests allow particular user(s) to obtain
      preferential access to network resources.  To prevent abuse, some
      form of back pressure will generally be required on users who make
      reservations.  For example, such back pressure may be accomplished
      by administrative access policies, or it may depend upon some form
      of user feedback such as real or virtual billing for the "cost" of
      a reservation.  In any case, reliable user identification and
      selective admission will generally be needed when a reservation is
      requested.

      The term "policy control" is used for the mechanisms required to
      support access policies and back pressure for RSVP reservations.
      When a new reservation is requested, each node must answer two
      questions: "Are enough resources available to meet this request?"



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


      and "Is this user allowed to make this reservation?"  These two
      decisions are termed the "admission control" decision and the
      "policy control" decision, respectively, and both must be
      favorable in order for RSVP to make a reservation.  Different
      administrative domains in the Internet may have different
      reservation policies.

      The input to policy control is referred to as "policy data", which
      RSVP carries in POLICY_DATA objects.  Policy data may include
      credentials identifying users or user classes, account numbers,
      limits, quotas, etc.  Like flowspecs, policy data is opaque to
      RSVP, which simply passes it to policy control when required.
      Similarly, merging of policy data must be done by the policy
      control mechanism rather than by RSVP itself.  Note that the merge
      points for policy data are likely to be at the boundaries of
      ad