rfc3175.txt

RFC 的详细文档！

   RSVP directly handles route changes, in that reservations follow the
   routes that their data follow.  This follows from the property that
   Path messages contain the same IP source and destination address as
   the data flow for which a reservation is to be established.  However,
   since we are now making aggregate reservations by sending a Path
   message from an aggregating to a deaggregating router, the reserved
   (E2E) data packets no longer carry the same IP addresses as the
   relevant (aggregate) Path message.  The issue becomes one of making
   sure that data packets for reserved flows follow the same path as the
   Path message that established Path state for the aggregate
   reservation.  Several approaches are viable.

   First, the data may be tunneled from aggregator to deaggregator,
   using technologies such as IP-in-IP tunnels, GRE tunnels, MPLS
   label-switched paths, and so on.  These each have particular
   advantages, especially MPLS, which allows traffic engineering.  They
   each also have some cost in link overhead and configuration
   complexity.






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


   If data is not tunneled, then we are depending on a characteristic of
   IP best metric routing , which is that if the route from A to Z
   includes the path from H to L, and the best metric route was chosen
   all along the way, then the best metric route was chosen from H to L.
   Therefore, an aggregate path message which crosses a given aggregator
   and deaggregator will of necessity use the best path between them.

   If this is a single path, the problem is solved.  If it is a multi-
   path route, and the paths are of equal cost, then we are forced to
   determine, perhaps by measurement, what proportion of the traffic for
   a given E2E reservation is passing along each of the paths, and
   assure ourselves of sufficient bandwidth for the present use.  A
   simple, though wasteful, way of doing this is to reserve the total
   capacity of the aggregate route down each path.

   For this reason, we believe it is advantageous to use one of the
   above-mentioned tunneling mechanisms in cases where multiple equal-
   cost paths may exist.

1.4.7.  Inter-domain Routes

   The case of inter-domain routes differs somewhat from the intra-
   domain case just described.  Specifically, best-path considerations
   do not apply, as routing is by a combination of routing policy and
   shortest AS path rather than simple best metric.

   In the case of inter-domain routes, data traffic belonging to
   different E2E sessions (but the same aggregate session) may not enter
   an aggregation region via the same aggregator interface, and/or may
   not leave via the same deaggregator interface.  It is possible that
   we could identify this occurrence in some central system which sees
   the reservation information for both of the apparent sessions, but it
   is not clear that we could determine a priori how much traffic went
   one way or the other apart from measurement.

   We simply note that this problem can occur and needs to be allowed
   for in the implementation.  We recommend that each such E2E
   reservation be summed into its appropriate aggregate reservation,
   even though this involves over-reservation.

1.4.8.  Reservations for Multicast Sessions

   Aggregating reservations for multicast sessions is significantly more
   complex than for unicast sessions.  The first challenge is to
   construct a multicast tree for distribution of the aggregate Path
   messages which follows the same path as will be followed by the data
   packets for which the aggregate reservation is to be made.  This is
   complicated by the fact that the path taken by a data packet may



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


   depend on many factors such as its source address, the choice of
   shared trees or source-specific trees, and the location of a
   rendezvous point for the tree.

   Once the problem of distributing aggregate Path messages is solved,
   there are considerable problems in determining the correct amount of
   resources to reserve at each link along the multicast tree.  Because
   of the amount of heterogeneity that may exist in an aggregate
   multicast reservation, it appears that it would be necessary to
   retain information about individual E2E reservations within the
   aggregation region to allocate resources correctly.  Thus, we may end
   up with a complex set of procedures for forming aggregate
   reservations that do not actually reduce the amount of stored state
   significantly for multicast sessions.

   As noted above, there are several aspects to RSVP state, and our
   approach for unicast aggregates all forms of state:  classification,
   scheduling, and reservation state.  One possible approach to
   multicast is to focus only on aggregation of classification and
   scheduling state, which are arguably the most important because of
   their impact on the forwarding path.  That approach is the one
   described in the current draft.

1.4.9.  Multi-level Aggregation

   Ideally, an aggregation scheme should be able to accommodate
   recursive aggregation, with aggregate reservations being themselves
   aggregated.  Multi-level aggregation can be accomplished using the
   procedures described here and a simple extension to the protocol
   number swapping process.

   We can consider E2E RSVP reservations to be at aggregation level 0.
   When we aggregate these reservations, we produce reservations at
   aggregation level 1.  In general, level n reservations may be
   aggregated to form reservations at level n+1.

   When an aggregating router receives an E2E Path, it swaps the
   protocol number from RSVP to RSVP-E2E-IGNORE.  In addition, it should
   write the aggregation level (1, in this case) in the 2 byte field
   that is present (and currently unused) in the router alert option.
   In general, a router which aggregates reservations at level n to
   create reservations at level n+1 will write the number n+1 in the
   router alert field.  A router which deaggregates level n+1
   reservations will examine all messages with IP protocol number RSVP-
   E2E-IGNORE but will process the message and swap the protocol number
   back to RSVP only in the case where the router alert field carries
   the number n+1.  For any other value, the message is forwarded
   unchanged.  Interior routers ignore all messages with IP protocol



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


   number RSVP-E2E-IGNORE.  Note that only a few bits of the 2 byte
   field in the option would be needed, given the likely number of
   levels of aggregation.

   For IPv6, certain values of the router alert "value" field are
   reserved.  This specification requires IANA assignment of a small
   number of consecutive values for the purpose of recording the
   aggregation level.

1.4.10.  Reliability Issues

   There are a variety of issues that arise in the context of
   aggregation that would benefit from some form of explicit
   acknowledgment mechanism for RSVP messages.  For example, it is
   possible to configure a set of routers such that an E2E Path of
   protocol type RSVP-E2E-IGNORE would be effectively "black-holed", if
   it never reached a router which was appropriately configured to act
   as a deaggregator.  It could then travel all the way to its
   destination where it would probably be ignored due to its non-
   standard protocol number.  This situation is not easy to detect.  The
   aggregator can be sure this problem has not occurred if an aggregate
   PathErr message is received from the deaggregator (as described in
   detail below).  It can also be sure there is no problem if an E2E
   Resv is received.  However, the fact that neither of these events has
   happened may only mean that no receiver wishes to reserve resources
   for this session, or that an RSVP message loss occurred, or it may
   mean that the Path was black-holed.  However, if a neighbor-to-
   neighbor acknowledgment mechanism existed, the aggregator would
   expect to receive an acknowledgment of the E2E Path from the
   deaggregator, and would interpret the lack of a response as an
   indication that a problem of configuration existed.  It could then
   refrain from aggregating this particular session.  We note that such
   a reliability mechanism has been proposed for RSVP in [RFC291] and
   propose that it be used here.

1.4.11.  Message Integrity and Node Authentication

   [RSVP] defines a hop-by-hop authentication and integrity check.  The
   present specification allows use of this check on Aggregate RSVP
   messages and also preserves this check on E2E RSVP messages for E2E
   RSVP messages.

   Outside the Aggregation Region, any E2E RSVP message may contain an
   INTEGRITY object using a keyed cryptographic digest technique which
   assumes that RSVP neighbors share a secret.  Because E2E RSVP
   messages are not processed by routers in the Aggregation Region, the
   Aggregator and Deaggregator appear as logical RSVP neighbors of each
   other.  The Deaggregator is the Aggregator's Next Hop for E2E RSVP



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


   messages while the Aggregator is the Deaggregator's Previous Hop.
   Consequently, INTEGRITY objects which may appear in E2E RSVP messages
   traversing the Aggregation Region are exchanged directly between the
   Aggregator and Deaggregator in a manner which is entirely transparent
   to the Interior routers.  Thus, hop-by-hop integrity checking for E2E
   messages over the Aggregation Region requires that the Aggregator and
   Deaggregator share a secret.  Techniques for establishing that secret
   are described in [INTEGRITY].

   Inside the Aggregation Region, any Aggregate RSVP message may contain
   an INTEGRITY object which assumes that the corresponding RSVP
   neighbors inside the Aggregation Region (e.g., Aggregator and
   Interior Router, two Interior Routers, Interior Router and
   Deaggregator) share a secret.

1.4.12.  Aggregated reservations without E2E reservations

   Up to this point we have assumed that the aggregate reservation is
   established as a result of the establishment of E2E reservations from
   outside the aggregation region.  It should be clear that alternative
   triggers are possible.  As discussed in [RFC2998], an aggregate RSVP
   reservation can be used to manage bandwidth in a diff-serv cloud even
   if RSVP is not used end-to-end.

   The simplest example of an alternative configuration is the static
   configuration of an aggregated reservation for a certain amount for
   traffic from an ingress (aggregator) router to an egress (de-
   aggregator) router.  This would have to be configured in at least the
   system originating the aggregate PATH message (the aggregator).  The
   deaggregator could detect that the PATH message is directed to it,
   and could be configured to "turn around" such messages, i.e., it
   responds with a RESV back to the aggregator.  Alternatively,
   configuration of the aggregate reservation could be performed at both
   the aggregator and the deaggregator.  As before, an aggregate
   reservation is associated with a DSCP for the traffic that will use
   the reserved capacity.

   In the absence of E2E microflow reservations, the aggregator can use
   a variety of policies to set the DSCP of packets passing into the
   aggregation region, thus determining whether they gain access to the
   resources reserved by the aggregate reservation.  These policies are
   a matter of local configuration, as usual for a device at the edge of
   a diffserv cloud.








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


   Note that the "aggregator" could even be a device such as a PSTN
   gateway which makes an aggregate reservation for the set of calls to
   another PSTN gateway (the deaggregator) across an intervening diff-
   serv region.  In this case the reservation may be established in
   response to call signalling.

   From the perspective of RSVP signalling and the handling of data
   packets in the aggregation region, these cases are equivalent to the
   case of aggregating E2E RSVP reservations.  The only difference is
   that E2E RSVP signalling does not take place and cannot therefore be
   used as a trigger, so some additional knowledge is required in
   setting up the aggregate reservation.

2.  Elements of Procedure