rfc3175.txt

RFC 的详细文档！

   per aggregate reservation).  For example, if Guaranteed Service
   reservations are mapped to the EF DSCP throughout the aggregation
   region, there may be a reservation for each aggregator/deaggregator
   pair in each router, but only the EF DSCP needs to be inspected at
   each interior interface, and only a single queue is used for all EF
   traffic.







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


1.4.2.  Deaggregator Determination

   The first question is "How do we determine the
   Aggregator/Deaggregator pair that are responsible for aggregating a
   particular E2E flow through the aggregation region?"

   Determination of the aggregator is trivial: we know that an E2E flow
   has arrived at an aggregator when its Path message arrives at a
   router on an exterior interface and must be forwarded on an interior
   interface.

   Determination of the deaggregator is more involved.  If an SPF
   routing protocol, such as OSPF or IS-IS, is in use, and if it has
   been extended to advertise information on Deaggregation roles, it can
   tell us the set of routers from which the deaggregator will be
   chosen.  In principle, if the aggregator and deaggregator are in the
   same area, then the identity of the deaggregator could be determined
   from the link state database.  However, this approach would not work
   in multi-area environments or for distance vector protocols.

   One method for Deaggregator determination is manual configuration.
   With this method the network operator would configure the Aggregator
   and the Deaggregator with the necessary information.

   Another method allows automatic Deaggregator determination and
   corresponding Aggregator notification.  When the E2E RSVP Path
   message transits from an interior interface to an exterior interface,
   the deaggregating router must advise the aggregating router of the
   correlation between itself and the flow.  This has the nice attribute
   of not being specific to the routing protocol.  It also has the
   property of automatically adjusting to route changes.  For instance,
   if because of a topology change, another Deaggregator is now on the
   shortest path, this method will automatically identify the new
   Deaggregator and swap to it.

1.4.3.  Mapping E2E Reservations Onto Aggregate Reservations

   As discussed above, there may be multiple Aggregate Reservations
   between the same Aggregator/Deaggregator pair.  The rules for mapping
   E2E reservations onto aggregate reservations are policy decisions
   which depend on the network environment and network administrator's
   objectives.  Such a policy is outside the scope of this specification
   and we simply assume that such a policy is defined by the network
   administrator.  We also assume that such a policy is somehow
   accessible to the Aggregators/Deaggregators but the details of how
   this policy is made accessible to Aggregators/Deaggregators (Local
   Configuration, COPS, LDAP, etc.) is outside the scope of this
   specification.



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


   An example of very simple policy would be that all the E2E
   reservations are mapped onto a single Aggregate Reservation (i.e.,
   single DSCP) between a given pair of Aggregator/Deaggregator.

   Another example of policy, which takes into account the Int-Serv
   service type requested by the receiver (and signalled in the E2E
   Resv), would be where Guaranteed Service E2E reservations are mapped
   onto one DSCP in the aggregation region and where Controlled Load E2E
   reservations are mapped onto another DSCP.

   A third example of policy would be one where the mapping of E2E
   reservations onto Aggregate Reservations take into account Policy
   Objects (such as information authenticating the end user) which may
   be included by the sender in the E2E path and/or by the receiver in
   the E2E Resv.

   Regardless of the actual policy, a range of options are conceivable
   for where the decision to map an E2E reservation onto an aggregate
   reservation is taken and how this decision is communicated between
   Aggregator and Deaggregator.  Both Aggregator and Deaggregator could
   be assumed to make such a decision independently.  However, this
   would either require definition of additional procedures to solve
   inconsistent mapping decisions (i.e., Aggregator and Deaggregator
   decide to map a given E2E reservation onto different Aggregate
   Reservations) or would result in possible undetected misbehavior in
   the case of inconsistent decisions.

   For simplicity and reliability, we assign the responsibility of the
   mapping decision entirely to the Deaggregator.  The Aggregator is
   notified of the selected mapping by the Deaggregator and follows this
   decision.  The Deaggregator was chosen rather than the Aggregator
   because the Deaggregator is the first to have access to all the
   information required to make such a decision (in particular receipt
   of the E2E Resv which indicates the requested Int-Serv service type
   and includes information signalled by the receiver).  This allows
   faster operations such as set-up or size adjustment of an Aggregate
   Reservation in a number of situations resulting in faster E2E
   reservation establishment.

1.4.4.  Size of Aggregate Reservations

   A range of options exist for determining the size of the aggregate
   reservation, presenting a tradeoff between simplicity and
   scalability.  Simplistically, the size of the aggregate reservation
   needs to be greater than or equal to the sum of the bandwidth of the
   E2E reservations it aggregates, and its burst capacity must be
   greater than or equal to the sum of their burst capacities.  However,
   if followed religiously, this leads us to change the bandwidth of the



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


   aggregate reservation each time an underlying E2E reservation
   changes, which loses one of the key benefits of aggregation, the
   reduction of message processing cost in the aggregation region.

   We assume, therefore, that there is some policy, not defined in this
   specification (although sample policies are suggested which have the
   necessary characteristics).  This policy maintains the amount of
   bandwidth required on a given aggregate reservation by taking account
   of the sum of the bandwidths of its underlying E2E reservations,
   while endeavoring to change it infrequently.  This may require some
   level of trend analysis.  If there is a significant probability that
   in the next interval of time the current aggregate reservation will
   be exhausted, the router must predict the necessary bandwidth and
   request it.  If the router has a significant amount of bandwidth
   reserved but has very little probability of using it, the policy may
   be to predict the amount of bandwidth required and release the
   excess.

   This policy is likely to benefit from introduction of some hysteresis
   (i.e., ensure that the trigger condition for aggregate reservation
   size increase is sufficiently different from the trigger condition
   for aggregate reservation size decrease) to avoid oscillation in
   stable conditions.

   Clearly, the definition and operation of such policies are as much
   business issues as they are technical, and are out of the scope of
   this document.

1.4.5.  E2E Path ADSPEC update

   As described above, E2E RSVP messages are hidden from the Interior
   routers inside the aggregation region.  Consequently, the ADSPECs of
   E2E Path messages are not updated as they travel through the
   aggregation region.  Therefore, the Deaggregator for a flow is
   responsible for updating the ADSPEC in the corresponding E2E Path to
   reflect the impact of the aggregation region on the QoS that may be
   achieved end-to-end.  The Deaggregator should update the ADSPEC of
   the E2E Path as accurately as possible.

   Since Aggregate Path messages are processed inside the aggregation
   region, their ADSPEC is updated by Interior routers to reflect the
   impact of the aggregation region on the QoS that may be achieved
   within the interior region.  Consequently, the Deaggregator should
   make use of the information included in the ADSPEC from an Aggregate
   Path where available.  The Deaggregator may elect to wait until such
   information is available before forwarding the E2E Path in order to
   accurately update its ADSPEC.




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


   To maximize the information made available to the Deaggregator,
   whenever the Aggregator signals an Aggregate Path,  the Aggregator
   should include an ADSPEC with fragments for all service types
   supported in the aggregation region (even if the Aggregate Path
   corresponds to an Aggregate Reservation that only supports a subset
   of those service types).  Providing this information to the
   Deaggregator for every possible service type facilitates accurate and
   timely update of the E2E ADSPEC by the Deaggregator.

   Depending on the environment and on the policy for mapping E2E
   reservations onto Aggregate Reservations, to accurately update the
   E2E Path ADSPEC, the Deaggregator may for example:

   -  update all the E2E Path ADSPEC segments (Default General
      Parameters Fragment, Guaranteed Service Fragment, Controlled-Load
      Service Fragment) based on the ADSPEC of a single Aggregate Path,
      or

   -  update the E2E Path ADSPEC by taking into account the ADSPEC from
      multiple Aggregate Path messages (e.g.,.  update the Default
      General Parameters Fragment using the "worst" value for each
      parameter across all the Aggregate Paths' ADSPECs, update the
      Guaranteed Service Fragment using the Guaranteed Service Fragment
      from the ADSPEC of the Aggregate Path for the reservation used for
      Guaranteed Services).

   By taking into account the information contained in the ADSPEC of
   Aggregate Path(s) as mentioned above, the Deaggregator should be able
   to accurately update the E2E Path ADSPEC in most situations.

   However, we note that there may be particular situations where the
   E2E Path ADSPEC update cannot be made entirely accurately by the
   Deaggregator.  This is most likely to happen when the path taken
   across the aggregation region depends on the service requested in the
   E2E Resv, which is yet to arrive.  Such a situation could arise if,
   for example:

   -  The service mapping policy for the aggregation region is such that
      E2E reservations requesting Guaranteed Service are mapped to a
      different PHB that those requesting Controlled Load service.

   -  Diff-Serv aware routing is used in the aggregation region, so that
      packets with different DSCPs follow different paths (sending them
      over different MPLS label switched paths, for example).

   As a result, the ADSPEC for the aggregate reservation that supports
   guaranteed service may differ from the ADSPEC for the aggregate
   reservation that supports controlled load.



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


   Assume that the sender sends an E2E Path with an ADSPEC containing
   segments for both Guaranteed Services and Controlled Load.  Then, at
   the time of updating the E2E ADSPEC, the Deaggregator does not know
   which service type will actually be requested by the receiver and
   therefore cannot know which PHB will be used to transport this E2E
   flow and, in turn, cannot pick the right parameter values to factor
   in when updating the Default General Parameters Fragment.  As
   mentioned above, in this particular case, a conservative approach
   would be to always take into account the worst value for every
   parameter.  Regardless of whether this conservative approach is
   followed or some simpler approach such as taking into account one of
   the two Aggregate Path ADSPEC, the E2E Path ADSPEC will be inaccurate
   (over-optimistic or over-pessimistic) for at least one service type
   actually requested by the destination.

   Recognizing that entirely accurate update of E2E Path ADSPEC may not
   be possible in all situations, we recommend that a conservative
   approach be taken in such situations (over-pessimistic rather than
   over-optimistic) and that the E2E Path ADSPEC be corrected as soon as
   possible.  In the example described above, this would mean that as
   soon as the Deaggregator receives the E2E Resv from the receiver, the
   Deaggregator should generate another E2E Path with an accurately
   updated ADSPEC based on the knowledge of which aggregate reservation
   will actually carry the E2E flow.

1.4.6.  Intra-domain Routes