Aggregation of RSVP for IPv4 and IPv6 Reservations
RFC 3175
| Document | Type |
RFC - Proposed Standard
(September 2001; No errata)
Updated by RFC 5350
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 3175 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
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
Show full document text