RFC 3175: Aggregation of RSVP for IPv4 and IPv6 Reservations
In plain English — editorial summary, not part of the RFC
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. [STANDARDS-TRACK]
Document record
- Document ID
- RFC3175
- Published
- September 2001
- Authors
- F. Baker; C. Iturralde; F. Le Faucheur; B. Davie
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- tsv
- Pages
- 36
- Also known as
- —
- Updated by:
- RFC 5350
Topics
Referenced by
One later RFC formally updates or obsoletes part of this document.
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 2380RSVP over ATM Implementation RequirementsCurrent
August 1998
- RFC 3097RSVP Cryptographic Authentication -- Updated Message Type ValueCurrent
April 2001
- RFC 2997Specification of the Null Service TypeCurrent
November 2000
- RFC 2996Format of the RSVP DCLASS ObjectCurrent
November 2000
- RFC 2961RSVP Refresh Overhead Reduction ExtensionsUpdated
April 2001
- RFC 2814SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networksCurrent
May 2000
- RFC 2747RSVP Cryptographic AuthenticationUpdated
January 2000
- RFC 2746RSVP Operation Over IP TunnelsCurrent
January 2000
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?