rfc3175.txt

RFC 的详细文档！

Network Working Group                                           F. Baker
Request for Comments: 3175                                  C. Iturralde
Category: Standards Track                                 F. Le Faucheur
                                                                B. Davie
                                                           Cisco Systems
                                                          September 2001


           Aggregation of RSVP for IPv4 and IPv6 Reservations

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document describes the use of a single RSVP (Resource
   ReSerVation Protocol) reservation to aggregate other RSVP
   reservations across a transit routing region, in a manner
   conceptually similar to the use of Virtual Paths in an ATM
   (Asynchronous Transfer Mode) network.  It proposes a way to
   dynamically create the aggregate reservation, classify the traffic
   for which the aggregate reservation applies, determine how much
   bandwidth is needed to achieve the requirement, and recover the
   bandwidth when the sub-reservations are no longer required.  It also
   contains recommendations concerning algorithms and policies for
   predictive reservations.

1.  Introduction

   A key problem in the design of RSVP version 1 [RSVP] is, as noted in
   its applicability statement, that it lacks facilities for aggregation
   of individual reserved sessions into a common class.  The use of such
   aggregation is recommended in [CSZ], and required for scalability.

   The problem of aggregation may be addressed in a variety of ways.
   For example, it may sometimes be sufficient simply to mark reserved
   traffic with a suitable DSCP (e.g., EF), thus enabling aggregation of
   scheduling and classification state.  It may also be desirable to
   install one or more aggregate reservations from ingress to egress of



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


   an "aggregation region" (defined below) where each aggregate
   reservation carries similarly marked packets from a large number of
   flows.  This is to provide high levels of assurance that the end-to-
   end requirements of reserved flows will be met, while at the same
   time enabling reservation state to be aggregated.

   Throughout, we will talk about "Aggregator" and "Deaggregator",
   referring to the routers at the ingress and egress edges of an
   aggregation region.  Exactly how a router determines whether it
   should perform the role of aggregator or deaggregator is described
   below.

   We will refer to the individual reserved sessions (the sessions we
   are attempting to aggregate) as "end-to-end" reservations ("E2E" for
   short), and to their respective Path/Resv messages as E2E Path/Resv
   messages.  We refer to the the larger reservation (that which
   represents many E2E reservations) as an "aggregate" reservation, and
   its respective Path/Resv messages as "aggregate Path/Resv messages".

1.1.  Problem Statement: Aggregation Of E2E Reservations

   The problem of many small reservations has been extensively
   discussed, and may be summarized in the observation that each
   reservation requires a non-trivial amount of message exchange,
   computation, and memory resources in each router along the way.  It
   would be nice to reduce this to a more manageable level where the
   load is heaviest and aggregation is possible.

   Aggregation, however, brings its own challenges.  In particular, it
   reduces the level of isolation between individual flows, implying
   that one flow may suffer delay from the bursts of another.
   Synchronization of bursts from different flows may occur.  However,
   there is evidence [CSZ] to suggest that aggregation of flows has no
   negative effect on the mean delay of the flows, and actually leads to
   a reduction of delay in the "tail" of the delay distribution (e.g.,
   99% percentile delay) for the flows.  These benefits of aggregation
   to some extent offset the loss of strict isolation.

1.2.  Proposed Solution

   The solution we propose involves the aggregation of several E2E
   reservations that cross an "aggregation region" and share common
   ingress and egress routers into one larger reservation from ingress
   to egress.  We define an "aggregation region" as a contiguous set of
   systems capable of performing RSVP aggregation (as defined following)
   along any possible route through this contiguous set.





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


   Communication interfaces fall into two categories with respect to an
   aggregation region; they are "exterior" to an aggregation region, or
   they are "interior" to it.  Routers that have at least one interface
   in the region fall into one of three categories with respect to a
   given RSVP session; they aggregate, they deaggregate, or they are
   between an aggregator and a deaggregator.

   Aggregation depends on being able to hide E2E RSVP messages from
   RSVP-capable routers inside the aggregation region.  To achieve this
   end, the IP Protocol Number in the E2E reservation's Path, PathTear,
   and ResvConf messages is changed from RSVP (46) to RSVP-E2E-IGNORE
   (134) upon entering the aggregation region, and restored to RSVP at
   the deaggregator point.  These messages are ignored (no state is
   stored and the message is forwarded as a normal IP datagram) by each
   router within the aggregation region whenever they are forwarded to
   an interior interface.  Since the deaggregating router perceives the
   previous RSVP hop on such messages to be the aggregating router, Resv
   and other messages do not require this modification; they are unicast
   from RSVP hop to RSVP hop anyway.

   The token buckets (SENDER_TSPECs and FLOWSPECS) of E2E reservations
   are summed into the corresponding information elements in aggregate
   Path and Resv messages.  Aggregate Path messages are sent from the
   aggregator to the deaggregator(s) using RSVP's normal IP Protocol
   Number.  Aggregate Resv messages are sent back from the deaggregator
   to the aggregator, thus establishing an aggregate reservation on
   behalf of the set of E2E flows that use this aggregator and
   deaggregator.

   Such establishment of a smaller number of aggregate reservations on
   behalf of a larger number of E2E reservations yields the
   corresponding reduction in the amount of state to be stored and
   amount of signalling messages exchanged in the aggregation region.

   By using Differentiated Services mechanisms for classification and
   scheduling of traffic supported by aggregate reservations (rather
   than performing per aggregate reservation classification and
   scheduling), the amount of classification and scheduling state in the
   aggregation region is even further reduced.  It is not only
   independent of the number of E2E reservations, it is also independent
   of the number of aggregate reservations in the aggregation region.
   One or more Diff-Serv DSCPs are used to identify traffic covered by
   aggregate reservations and one or more Diff-Serv PHBs are used to
   offer the required forwarding treatment to this traffic.  There may
   be more than one aggregate reservation between the same pair of
   routers, each representing different classes of traffic and each
   using a different DSCP and a different PHB.




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


1.3.  Definitions

   We define an "aggregation region" as a set of RSVP-capable routers
   for which E2E RSVP messages arriving on an exterior interface of one
   router in the set would traverse one or more interior interfaces (of
   this and possibly of other routers in the set) before finally
   traversing an exterior interface.

   Such an E2E RSVP message is said to have crossed the aggregation
   region.

   We define the "aggregating" router for this E2E flow as the first
   router that processes the E2E Path message as it enters the
   aggregation region (i.e., the one which forwards the message from an
   exterior interface to an interior interface).

   We define the "deaggregating" router for this E2E flow as the last
   router to process the E2E Path as it leaves the aggregation region
   (i.e., the one which forwards the message from an interior interface
   to an exterior interface).

   We define an "interior" router for this E2E flow as any router in the
   aggregation region which receives this message on an interior
   interface and forwards it to another interior interface.  Interior
   routers perform neither aggregation nor deaggregation for this flow.

   Note that by these definitions a single router with a mix of interior
   and exterior interfaces may have the capability to act as an
   aggregator on some E2E flows, a deaggregator on other E2E flows, and
   an interior router on yet other flows.

1.4.  Detailed Aspects of Proposed Solution

   A number of issues jump to mind in considering this model.

1.4.1.  Traffic Classification Within The Aggregation Region

   One of the reasons that RSVP Version 1 did not identify a way to
   aggregate sessions was that there was not a clear way to classify the
   aggregate.  With the development of the Differentiated Services
   architecture, this is at least partially resolved; traffic of a
   particular class can be marked with a given DSCP and so classified.
   We presume this model.

   We presume that on each link en route, a queue, WDM color, or similar
   management component is set aside for all aggregated traffic of the
   same class, and that sufficient bandwidth is made available to carry




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


   the traffic that has been assigned to it.  This bandwidth may be
   adjusted based on the total amount of aggregated reservation traffic
   assigned to the same class.

   There are numerous options for exactly which Diff-serv PHBs might be
   used for different classes of traffic as it crosses the aggregation
   region.  This is the "service mapping" problem described in
   [RFC2998], and is applicable to situations broader than those
   described in this document.  Arguments can be made for using either
   EF or one or more AF PHBs for aggregated traffic.  For example, since
   controlled load requires non-TSpec-conformant (policed) traffic to be
   forwarded as best effort traffic rather than dropped, it may be
   appropriate to use an AF class for controlled load, using the higher
   drop preference for non-conformant packets.

   In conventional (unaggregated) RSVP operation, a session is
   identified by a destination address and optionally a protocol port.
   Since data belonging to an aggregated reservation is identified by a
   DSCP, the session is defined by the destination address and DSCP.
   For those cases where two DSCPs are used (for conformant and non-
   conformant packets, as noted above), the session is identified by the
   DSCP of conformant packets.  In general we will talk about mapping
   aggregated traffic onto a DSCP (even if a second DSCP may be used for
   non-conformant traffic).

   Whichever PHB or PHBs are used to carry aggregated reservations, care
   needs to be take in an environment where provisioned Diff-Serv and
   aggregated RSVP are used in the same network, to ensure that the
   total admitted load for a single PHB does not exceed the link
   capacity allocated to that PHB.  One solution to this is to reserve
   one PHB (or more) strictly for the aggregated reservation traffic
   (e.g., AF1 Class) while using other PHBs for provisioned Diff-Serv
   (e.g., AF2, AF3 and AF4 Classes).

   Inside the aggregation region, some RSVP reservation state is
   maintained per aggregate reservation, while classification and
   scheduling state (e.g., DSCPs used for classifying traffic) is
   maintained on a per aggregate reservation class basis (rather than