rfc2205.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

            Figure 7: Shared-Explicit (SE) Reservation Example



      The three examples just shown assume that data packets from S1,
      S2, and S3 are routed to both outgoing interfaces.  The top part
      of Figure 8 shows another routing assumption: data packets from S2
      and S3 are not forwarded to interface (c), e.g., because the
      network topology provides a shorter path for these senders towards
      R1, not traversing this node.  The bottom part of Figure 8 shows
      WF style reservations under this assumption.  Since there is no
      route from (b) to (c), the reservation forwarded out interface (b)
      considers only the reservation on interface (d).



















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


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

                       Router Configuration


                             |
               Sends         |       Reserves             Receives
                             |
                             |       _______
         WF( *{4B} ) <- (a)  |  (c) | * {4B}|   (c) <- WF( *{4B} )
                             |      |_______|
                             |
      -----------------------|----------------------------------------
                             |       _______
         WF( *{3B} ) <- (b)  |  (d) | * {3B}|   (d) <- WF( * {3B} )
                             |      |_______|       <- WF( * {2B} )

             Figure 8: WF Reservation Example -- Partial Routing


























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


2. RSVP Protocol Mechanisms

   2.1 RSVP Messages


       Previous       Incoming           Outgoing             Next
       Hops           Interfaces         Interfaces           Hops

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

                         Figure 9: Router Using RSVP



      Figure 9 illustrates RSVP's model of a router node.  Each data
      flow arrives from a "previous hop" through a corresponding
      "incoming interface" and departs through one or more "outgoing
      interface"(s).  The same interface may act in both the incoming
      and outgoing roles for different data flows in the same session.
      Multiple previous hops and/or next hops may be reached through a
      given physical interface; for example, the figure implies that D
      and D' are connected to (d) with a broadcast LAN.

      There are two fundamental RSVP message types: Resv and Path.

      Each receiver host sends RSVP reservation request (Resv) messages
      upstream towards the senders.  These messages must follow exactly
      the reverse of the path(s) the data packets will use, upstream to
      all the sender hosts included in the sender selection.  They
      create and maintain "reservation state" in each node along the
      path(s).  Resv messages must finally be delivered to the sender
      hosts themselves, so that the hosts can set up appropriate traffic
      control parameters for the first hop.  The processing of Resv
      messages was discussed previously in Section 1.2.




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


      Each RSVP sender host transmits RSVP "Path" messages downstream
      along the uni-/multicast routes provided by the routing
      protocol(s), following the paths of the data.  These Path messages
      store "path state" in each node along the way.  This path state
      includes at least the unicast IP address of the previous hop node,
      which is used to route the Resv messages hop-by-hop in the reverse
      direction.  (In the future, some routing protocols may supply
      reverse path forwarding information directly, replacing the
      reverse-routing function of path state).

      A Path message contains the following information in addition to
      the previous hop address:

      o    Sender Template

           A Path message is required to carry a Sender Template, which
           describes the format of data packets that the sender will
           originate.  This template is in the form of a filter spec
           that could be used to select this sender's packets from
           others in the same session on the same link.

           Sender Templates have exactly the same expressive power and
           format as filter specs that appear in Resv messages.
           Therefore a Sender Template may specify only the sender IP
           address and optionally the UDP/TCP sender port, and it
           assumes the protocol Id specified for the session.

      o    Sender Tspec

           A Path message is required to carry a Sender Tspec, which
           defines the traffic characteristics of the data flow that the
           sender will generate.  This Tspec is used by traffic control
           to prevent over-reservation, and perhaps unnecessary
           Admission Control failures.

      o    Adspec

           A Path message may carry a package of OPWA advertising
           information, known as an "Adspec".  An Adspec received in a
           Path message is passed to the local traffic control, which
           returns an updated Adspec; the updated version is then
           forwarded in Path messages sent downstream.









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


      Path messages are sent with the same source and destination
      addresses as the data, so that they will be routed correctly
      through non-RSVP clouds (see Section 2.9).  On the other hand,
      Resv messages are sent hop-by-hop; each RSVP-speaking node
      forwards a Resv message to the unicast address of a previous RSVP
      hop.

   2.2 Merging Flowspecs

      A Resv message forwarded to a previous hop carries a flowspec that
      is the "largest" of the flowspecs requested by the next hops to
      which the data flow will be sent (however, see Section 3.5 for a
      different merging rule used in certain cases).  We say the
      flowspecs have been "merged".  The examples shown in Section 1.4
      illustrated another case of merging, when there are multiple
      reservation requests from different next hops for the same session
      and with the same filter spec, but RSVP should install only one
      reservation on that interface.  Here again, the installed
      reservation should have an effective flowspec that is the
      "largest" of the flowspecs requested by the different next hops.

      Since flowspecs are opaque to RSVP, the actual rules for comparing
      flowspecs must be defined and implemented outside RSVP proper.
      The comparison rules are defined in the appropriate integrated
      service specification document.  An RSVP implementation will need
      to call service-specific routines to perform flowspec merging.

      Note that flowspecs are generally multi-dimensional vectors; they
      may contain both Tspec and Rspec components, each of which may
      itself be multi-dimensional.  Therefore, it may not be possible to
      strictly order two flowspecs.  For example, if one request calls
      for a higher bandwidth and another calls for a tighter delay
      bound, one is not "larger" than the other.  In such a case,
      instead of taking the larger, the service-specific merging
      routines must be able to return a third flowspec that is at least
      as large as each; mathematically, this is the "least upper bound"
      (LUB).  In some cases, a flowspec at least as small is needed;
      this is the "greatest lower bound" (GLB) GLB (Greatest Lower
      Bound).

      The following steps are used to calculate the effective flowspec
      (Re, Te) to be installed on an interface [RFC 2210].  Here Te is
      the effective Tspec and Re is the effective Rspec.








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


      1.   An effective flowspec is determined for the outgoing
           interface.  Depending upon the link-layer technology, this
           may require merging flowspecs from different next hops; this
           means computing the effective flowspec as the LUB of the
           flowspecs.  Note that what flowspecs to merge is determined
           by the link layer medium (see Section 3.11.2), while how to
           merge them is determined by the service model in use [RFC
           2210].

           The result is a flowspec that is opaque to RSVP but actually
           consists of the pair (Re, Resv_Te), where is Re is the
           effective Rspec and Resv_Te is the effective Tspec.

      2.   A service-specific calculation of Path_Te, the sum of all
           Tspecs that were supplied in Path messages from different
           previous hops (e.g., some or all of A, B, and B' in Figure
           9), is performed.

      3.   (Re, Resv_Te) and Path_Te are passed to traffic control.
           Traffic control will compute the effective flowspec as the
           "minimum" of Path_Te and Resv_Te, in a service-dependent
           manner.

      Section 3.11.6 defines a generic set of service-specific calls to
      compare flowspecs, to compute the LUB and GLB of flowspecs, and to
      compare and sum Tspecs.

   2.3 Soft State

      RSVP takes a "soft state" approach to managing the reservation
      state in routers and hosts.  RSVP soft state is created and
      periodically refreshed by Path and Resv messages.  The state is
      deleted if no matching refresh messages arrive before the
      expiration of a "cleanup timeout" interval.  State may also be
      deleted by an explicit "teardown" message, described in the next
      section.  At the expiration of each "refresh timeout" period and
      after a state change, RSVP scans its state to build and forward
      Path and Resv refresh messages to succeeding hops.

      Path and Resv messages are idempotent.  When a route changes, the
      next Path message will initialize the path state on the new route,
      and future Resv messages will establish reservation state there;
      the state on the now-unused segment of the route will time out.
      Thus, whether a message is "new" or a "refresh" is determined
      separately at each node, depending upon the existence of state at
      that node.