rfc3175.txt

RFC 的详细文档！

   aggregate reservations.

2.7.  Handling of Aggregate Resv Message by Interior Routers

   The aggregate Resv message is handled in essentially the same way as
   defined in [RSVP].  The Session object contains the address of the
   deaggregating router (or the group address for the session in the
   case of multicast) and the DSCP that has been chosen for the session.
   The Filterspec object identifies the aggregating router.  These
   routers perform admission control and resource allocation as usual
   and send the aggregate Resv on towards the aggregator.

2.8.  Handling of E2E Resv Message by Aggregating Router

   The receipt of the E2E Resv message with a DCLASS Object is the final
   confirmation to the aggregating router of the mapping of the E2E
   reservation onto an Aggregate Reservation.  Under normal
   circumstances, this is the only way it will be informed of this
   association.  It should now forward the E2E Resv to its previous hop,
   following normal RSVP processing rules [RSVP].

2.9.  Removal of E2E Reservation

   E2E reservations are removed in the usual way via PathTear, ResvTear,
   timeout, or as the result of an error condition.  When they are
   removed, their FLOWSPEC information must also be removed from the
   allocated portion of the aggregate reservation.  This same bandwidth
   may be re-used for other traffic in the near future.  When E2E Path
   messages are removed, their SENDER_TSPEC information must also be
   removed from the aggregate Path.

2.10.  Removal of Aggregate Reservation

   Should an aggregate reservation go away (presumably due to a
   configuration  change, route change, or policy event), the E2E
   reservations it supports are no longer active.  They must be treated
   accordingly.

2.11.  Handling of Data On Reserved E2E Flow by Aggregating Router

   Prior to establishment that a given E2E flow is part of a given
   aggregate, the flow's data should be treated as traffic without a
   reservation by whatever policies prevail for such.  Generally, this
   will mean being given the same forwarding behavior as best effort
   traffic.  However, upon establishing that the flow belongs to a given
   aggregate, the aggregating router is responsible for marking any



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


   related traffic with the correct DSCP and forwarding it in the manner
   appropriate to traffic on that reservation.  This may imply
   forwarding it to a given IP next hop, or piping it down a given link
   layer circuit, tunnel, or MPLS label switched path.

   The aggregator is responsible for performing per-reservation policing
   on the E2E flows that it is aggregating.  The aggregator performs
   metering of traffic belonging to each reservation to assess
   compliance to the token bucket for the corresponding E2E reservation.
   Packets which are assessed in compliance are forwarded as mentioned
   above.  Packets which are assessed out of compliance must be either
   dropped, reshaped or marked to a different DSCP.  The detailed
   policing behavior is an aspect of the service mapping described in
   [RFC2998].

2.12.  Procedures for Multicast Sessions

   Because of the difficulties of aggregating multicast sessions
   described above, we focus on the aggregation of scheduling and
   classification state in the multicast case.  The main difference
   between the multicast and unicast cases is that rather than sending
   an aggregate Path message to the unicast address of a single
   deaggregating router, in the multicast case we send the "aggregate"
   Path message to the same group address as the E2E session.  This
   ensures that the aggregate Path message follows the same route as the
   E2E Path.  This difference between unicast and multicast is reflected
   in the Session objects defined below.  A consequence of this approach
   is that we continue to have reservation state per multicast session
   inside the aggregation region.

   A further challenge arises in multicast sessions with heterogeneous
   receivers.  Consider an interior router which must forward packets
   for a multicast session on two interfaces, but has only received a
   reservation request on one of those interfaces.  It receives packets
   marked with the DSCP chosen for the aggregate reservation.  When
   sending them out the interface which has no installed reservation, it
   has the following options:

   a) remark those packets to best effort before sending them out the
      interface;

   b) send the packets out the interface with the DSCP chosen for the
      aggregate reservation.

   The first approach suffers from the drawback that it requires nMF
   classification at an interior router in order to recognize the flows
   whose packets must be demoted.  The second approach requires over-
   reservation of resources on the interface on which no reservation was



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


   received.  In the absence of such over-reservation, the packets sent
   with the "wrong" DSCP would be able to degrade the service
   experienced by packets using that DSCP legitimately.

   To make MF classification acceptable in an interior router, it may be
   possible to treat the case of heterogeneous flows as an exception.
   That is, an interior router only needs to be able to recognize those
   individual microflows that have heterogeneous resource needs on the
   outbound interfaces of this router.

3.  Protocol Elements

3.1.  IP Protocol RSVP-E2E-IGNORE

   This specification requires the assignment of a protocol type RSVP-
   E2E-IGNORE, whose number is at this point 134.  This is used only on
   E2E messages which require a router alert (Path, PathTear, and
   ResvConf), and signifies that the message must be treated one way
   when destined to an interior interface, and another way when destined
   to an exterior interface.  The protocol type is swapped by the
   Aggregator from RSVP to RSVP-E2E-IGNORE in E2E Path, PathTear, and
   ResvConf messages when they enter the Aggregation Region.  The
   protocol type is swapped back by the Deaggregator from RSVP-E2E-
   IGNORE to RSVP in such E2E messages when they exit the Aggregation
   Region.

3.2.  Path Error Code

   A PathErr code NEW-AGGREGATE-NEEDED is required.  This value does not
   signify that a fatal error has occurred, but that an action is
   required of the aggregating router to avoid an error condition in the
   near future.

3.3.  SESSION Object

   The SESSION object contains two values: the IP Address of the
   aggregate session destination, and the DSCP that it will use on the
   E2E data the reservation contains.  For unicast sessions, the session
   destination address is the address of the deaggregating router.  For
   multicast sessions, the session destination is the multicast address
   of the E2E session (or sessions) being aggregated.  The inclusion of
   the DSCP in the session allows for multiple sessions toward the same
   address to be distinguished by their DSCP and queued separately.  It
   also provides the means for aggregating scheduling and classification
   state.  In the case where a session uses a pair of PHBs (e.g., AF11
   and AF12), the DSCP used should represent the numerically smallest
   PHB (e.g., AF11).  This follows the same naming convention described
   in [BRIM].



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


   Session types are defined for IPv4 and IPv6 addresses.

   o  IP4 SESSION object: Class = SESSION,
      C-Type = RSVP-AGGREGATE-IP4

        +-------------+-------------+-------------+-------------+
        |              IPv4 Session Address (4 bytes)           |
        +-------------+-------------+-------------+-------------+
        | /////////// |    Flags    |  /////////  |     DSCP    |
        +-------------+-------------+-------------+-------------+

   o  IP6 SESSION object: Class = SESSION,
      C-Type = RSVP-AGGREGATE-IP6

        +-------------+-------------+-------------+-------------+
        |                                                       |
        +                                                       +
        |                                                       |
        +              IPv6 Session Address (16 bytes)          +
        |                                                       |
        +                                                       +
        |                                                       |
        +-------------+-------------+-------------+-------------+
        | /////////// |    Flags    |  /////////  |     DSCP    |
        +-------------+-------------+-------------+-------------+

3.4.  SENDER_TEMPLATE Object

   The SENDER_TEMPLATE object identifies the aggregating router for the
   aggregate reservation.

   o  IP4 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE,
      C-Type = RSVP-AGGREGATE-IP4

        +-------------+-------------+-------------+-------------+
        |                IPv4 Aggregator Address (4 bytes)      |
        +-------------+-------------+-------------+-------------+














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


   o  IP6 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE,
      C-Type = RSVP-AGGREGATE-IP6

        +-------------+-------------+-------------+-------------+
        |                                                       |
        +                                                       +
        |                                                       |
        +           IPv6 Aggregator Address (16 bytes)          +
        |                                                       |
        +                                                       +
        |                                                       |
        +-------------+-------------+-------------+-------------+

3.5.  FILTER_SPEC Object

   The FILTER_SPEC object identifies the aggregating router for the
   aggregate reservation, and is syntactically identical to the
   SENDER_TEMPLATE object.

4.  Policies and Algorithms For Predictive Management Of Blocks Of
    Bandwidth

   The exact policies used in determining how much bandwidth should be
   allocated to an aggregate reservation at any given time are beyond
   the scope of this document, and may be proprietary to the service
   provider in question.  However, here we explore some of the issues
   and suggest approaches.

   In short, the ideal condition is that the aggregate reservation
   always has enough resources to allocate to any E2E reservation that
   requires its support, and never takes too much.  Simply stated, but
   more difficult to achieve.  Factors that come into account include
   significant times in the diurnal cycle: one may find that a large
   number of people start placing calls at 8:00 AM, even though the hour
   from 7:00 to 8:00 is dead calm.  They also include recent history: if
   more people have been  placing calls recently than have been
   finishing them, a prediction of the necessary bandwidth a few moments
   hence may call for more bandwidth than is currently allocated.
   Likewise, at the end of a busy period, we may find that the trend
   calls for declining reservation amounts.

   We recommend a policy something along this line.  At any given time,
   one should expect th