Aggregation of RSVP for IPv4 and IPv6 Reservations
RFC 3175

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

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.