RFC 3175 (rfc3175) - Page 2 of 36

Aggregation of RSVP for IPv4 and IPv6 Reservations

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