rfc3175.txt

RFC 的详细文档！

   To implement aggregation, we define a number of elements of
   procedure.

2.1.  Receipt of E2E Path Message By Aggregating Router

   The very first event is the arrival of the E2E Path message at an
   exterior interface of an aggregator.  Standard RSVP procedures [RSVP]
   are followed for this, including onto what set of interfaces the
   message should be forwarded.  These interfaces comprise zero or more
   exterior interfaces and zero or more interior interfaces.  (If the
   number of interior interfaces is zero, the router is not acting as an
   aggregator for this E2E flow.)

   Service on exterior interfaces is handled as defined in [RSVP].

   Service on interior interfaces is complicated by the fact that the
   message needs to be included in some aggregate reservation, but at
   this point it is not known which one, because the deaggregator is not
   known.  Therefore, the E2E Path message is forwarded on the interior
   interface(s) using the IP Protocol number RSVP-E2E-IGNORE, but in
   every other respect identically to the way it would be sent by an
   RSVP router that was not performing aggregation.

2.2.  Handling Of E2E Path Message By Interior Routers

   At this point, the E2E Path message traverses zero or more interior
   routers.  Interior routers receive the E2E Path message on an
   interior interface and forward it on another interior interface.  The
   Router Alert IP Option alerts interior routers to check internally,
   but they find that the IP Protocol is RSVP-E2E-IGNORE and the next
   hop interface is interior.  As such, they simply forward it as a
   normal IP datagram.




Baker, et al.               Standards Track                    [Page 15]

RFC 3175              RSVP Reservation Aggregation        September 2001


2.3.  Receipt of E2E Path Message By Deaggregating Router

   The E2E Path message finally arrives at a deaggregating router, which
   receives it on an interior interface and forwards it on an exterior
   interface.  Again, the Router Alert IP Option alerts it to intercept
   the message, but this time the IP Protocol is RSVP-E2E-IGNORE and the
   next hop interface is an exterior interface.

   Before forwarding the E2E Path towards the receiver, the Deaggregator
   should update its ADSPEC.  This update is to reflect the impact of
   the aggregation region onto the QoS to be achieved E2E by the flow.
   Such information can be collected by the ADSPEC of Aggregate Path
   messages travelling from the Aggregator to the Deaggregator.  Thus,
   to enable correct updating of the ADSPEC, a deaggregating router may
   wait as described below for the arrival of an aggregate Path before
   forwarding the E2E Path.

   When receiving the E2E Path, depending on the policy for mapping E2E
   reservation onto Aggregate Reservations, the Deaggregator may or may
   not be in a position to decide which DSCP the E2E flow for the
   processed E2E Path is going to be mapped onto, as described above.
   If the Deaggregator is in a position to know the mapping at this
   point, then the Deaggregator first checks that there is an Aggregate
   Path in place for the corresponding DSCP.  If so, then the
   Deaggregator uses the ADSPEC of this Aggregate Path to update the
   ADSPEC of the E2E Path and then forwards the E2E Path towards the
   receiver.  If not, then the Deaggregator requests establishment of
   the corresponding Aggregate Path by sending an E2E PathErr message
   with an error code of NEW-AGGREGATE-NEEDED and the desired DSCP
   encoded in the DCLASS Object.  The Deaggregator may also at the same
   time request establishment of an aggregate reservation for other
   DSCPs.  When receiving the Aggregate Path for the desired DSCP, the
   Deaggregator then uses the ADSPEC of this Aggregate Path to update
   the ADSPEC of the E2E Path.

   If the Deaggregator is not in a position to know the mapping at this
   point, then the Deaggregator uses the information contained in the
   ADSPEC of one Aggregate Path or of multiple Aggregate Paths to update
   the E2E Path ADSPEC.  Similarly, if one or more of the necessary
   Aggregate Paths is not yet established, the Deaggregator requests
   establishment of the corresponding Aggregate Path by sending an E2E
   PathErr message with an error code of NEW-AGGREGATE-NEEDED and the
   desired DSCP encoded in the respective DCLASS Object.  When receiving
   the Aggregate Path for the desired DSCP, the Deaggregator then uses
   the ADSPEC of this Aggregate Path to update the ADSPEC of the E2E
   Path.





Baker, et al.               Standards Track                    [Page 16]

RFC 3175              RSVP Reservation Aggregation        September 2001


   Generating a E2E PathErr message with an error code of NEW-
   AGGREGATE-NEEDED should not result in any Path state being removed,
   but should result in the aggregating router initiating the necessary
   aggregate Path message, as described in the following section.

   The deaggregating router changes the E2E Path message's IP Protocol
   from RSVP-E2E-IGNORE to RSVP and forwards the E2E Path message
   towards its intended destination.

2.4.  Initiation of New Aggregate Path Message By Aggregating Router

   The aggregating Router is responsible for generating a new Aggregate
   Path for a DSCP when receiving a E2E PathErr message with the error
   code NEW-AGGREGATE-NEEDED from the deaggregator.  The DSCP value to
   include in the Aggregate Path Session is found in the DCLASS Object
   of the received E2E PathErr message.  The identity of the
   deaggregator itself is found in the ERROR SPECIFICATION of the E2E
   PathErr message.  The destination address of the aggregate Path
   message is the address of the deaggregating router, and the message
   is sent with IP protocol number RSVP.

   Existing RSVP procedures specify that the size of a reservation
   established for a flow is set to the minimum of the Path SENDER_TSPEC
   and the Resv FLOW_SPEC.  Consequently, the size of an Aggregate
   Reservation cannot be larger than the SENDER_TSPEC included in the
   Aggregate Path by the Aggregator.  To ensure that Aggregate
   Reservations can be sized by the Deaggregator without undesired
   limitations, the Aggregating router should always attempt to include
   in the Aggregate Path a SENDER_TSPEC which is at least as large as
   the size that would actually be required as determined by the
   Deaggregator.  One method to achieve this is to use a SENDER_TSPEC
   which is obviously larger than the highest load of E2E reservations
   that may be supported onto this network.  Another method is for the
   Aggregator to keep track of which flows are mapped onto a DSCP and
   always add their E2E Path SENDER_TSPEC into the Aggregate Path
   SENDER_TSPEC (and possibly also add some additional bandwidth in
   anticipation of future E2E reservations).

   The aggregating router is notified of the mapping from an E2E flow to
   a DSCP in two ways.  First, when the aggregating router receives a
   E2E PathErr with error code NEW-AGGREGATE-NEEDED, the Aggregator is
   notified that the corresponding E2E flow is (at least temporarily)
   mapped onto a given DSCP.  Secondly, when the aggregating router
   receives an E2E Resv containing a DCLASS Object (as described further
   below), the Aggregating Router is notified that the corresponding E2E
   flow is mapped onto a given DSCP.





Baker, et al.               Standards Track                    [Page 17]

RFC 3175              RSVP Reservation Aggregation        September 2001


2.5.  Handling of E2E Resv Message by Deaggregating Router

   Having sent the E2E Path message on toward the destination, the
   deaggregator must now expect to receive an E2E Resv for the session.
   On receipt, its responsibility is to ensure that there is sufficient
   bandwidth reserved within the aggregation region to support the new
   E2E reservation, and if there is, then to forward the E2E Resv to the
   aggregating router.

   The Deaggregating router first makes the final decision of which
   Aggregate Reservation (and thus which DSCP) this E2E reservation is
   to be mapped onto.  This decision is made according to the policy
   selected by the network administrator as described above.

   If this final mapping decision is such that the Deaggregator can now
   make a more accurate update of the E2E Path ADSPEC than done when
   forwarding the initial E2E Path, the Deaggregator should do so and
   generate a new E2E Path immediately in order to provide the accurate
   ADSPEC information to the receiver as soon as possible.  Otherwise,
   normal Refresh procedures should be followed for the E2E Path.

   If no Aggregate Reservation currently exists from the corresponding
   aggregating router with the corresponding DSCP, the Deaggregating
   router will establish a new Aggregate Reservation as described in the
   next section.

   If the corresponding Aggregate Reservation exists but has
   insufficient bandwidth reserved to accommodate the new E2E
   reservation (in addition to all the existing E2E reservations
   currently mapped onto it), it should follow the normal RSVP
   procedures [RSVP] for a reservation being placed with insufficient
   bandwidth to support the reservation.  It may also first attempt to
   increase the aggregate reservation that is supplying bandwidth by
   increasing the size of the FLOW_SPEC that it includes in the
   aggregate Resv that it sends upstream.  As discussed in the previous
   section, the Aggregating Router should ensure that the SENDER_TSPEC
   it includes in the Aggregate Path is always in excess of the
   FLOW_SPEC that may be requested in the Aggregate Resv by the
   Deaggregator, so that the Deaggregator is not unnecessarily prevented
   from effectively increasing the Aggregate Reservation bandwidth as
   required.

   When sufficient bandwidth is available on the corresponding aggregate
   reservation, the Deaggregating Router may simply send the E2E Resv
   message with IP Protocol RSVP to the aggregating router.  This
   message should include the DCLASS object to indicate which DSCP the
   aggregator must use for this E2E flow.  The deaggregator will also




Baker, et al.               Standards Track                    [Page 18]

RFC 3175              RSVP Reservation Aggregation        September 2001


   add the token bucket from the E2E Resv FLOWSPEC object into its
   internal understanding of how much of the Aggregate reservation is in
   use.

   As discussed above, in order to minimize the occurrence of situations
   where insufficient bandwidth is reserved on the corresponding
   Aggregate Reservation at the time of processing an E2E Resv, and in
   turn to avoid the delay associated with the increase of this
   aggregate bandwidth, the Deaggregator MAY anticipate the current
   demand and increase the Aggregate Reservations size ahead of actual
   requirements by E2E reservations.

2.6.  Initiation of New Aggregate Resv Message By Deaggregating Router

   Upon receiving an E2E Resv message on an exterior interface, and
   having determined the appropriate DSCP for the session according to
   the mapping policy, the Deaggregator looks for the corresponding path
   state for a session with the chosen DSCP.  If aggregate Path state
   exists, but no aggregate Resv state exists, the Deaggregator creates
   a new aggregate Resv.

   If no aggregate Path state exists for the appropriate DSCP, this may
   be because the Deaggregator could not decide earlier the final
   mapping for this E2E flow and elected to not establish Aggregate Path
   state for all DSCPs.  In that case, the Deaggregator should request
   establishment of the corresponding Aggregate Path by sending a E2E
   PathErr with error code of NEW-AGGREGATE-NEEDED and with a DCLASS
   containing the required DSCP.  This will trigger the Aggregator to
   establish the corresponding Aggregate Path.  Once the Deaggregator
   has determined that the aggregate Path state is established, it
   creates a new Aggregate Resv.

   The FLOW_SPEC of the new Aggregate Resv is set to a value not smaller
   than the requirement of the E2E reservation it is supporting.  The
   Aggregate Resv is sent toward the aggregator (i.e., to the previous
   hop), using the AGGREGATED-RSVP session and filter specifications
   defined below.  Since the DSCP is in the SESSION object, no DCLASS
   object is necessary.  The message should be reliably delivered using
   the mechanisms in [RFC2961] or, alternatively, the CONFIRM object may
   be used, to assure that the aggregate Resv does indeed arrive and is
   granted.  This enables the deaggregator to determine that the
   requested bandwidth is available to allocate to the E2E flows it
   supports.

   In order to minimize the occurrence of situations where no
   corresponding Aggregate Reservation is established at the time of
   processing an E2E Resv, and in turn to avoid the delay associated
   with the creation of this aggregate reservation, the Deaggregator MAY



Baker, et al.               Standards Track                    [Page 19]

RFC 3175              RSVP Reservation Aggregation        September 2001


   anticipate the current demand and create the Aggregate Reservation
   before receiving E2E Resv messages requiring bandwidth on those