Aggregating RSVP-based QoS Requests
draft-guerin-aggreg-rsvp-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Dr. Roch Guerin , Shai Herzog , Steven L. Blake | ||
| Last updated | 1997-11-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This document describes issues and approaches related to aggregation of QoS requests, when RSVP [BZB+97] is the protocol used to convey such requests. Aggregation is an important component to provide scalable QoS solutions, especially in the core of the backbone where the sheer number of flows mandates some form of aggregation. However, aggregation needs to be provided without impacting the ability to provide end-to-end QoS guarantees to individual flows. In this document, we review some of the main goals of aggregation and describe possible solutions, that do not preclude support for end-to-end QoS guarantees. Those solutions are targeted at unicast flows as we expect them to represent a large fraction of the flows requesting reservation, and hence to be the main contributors to potential scalability problems with RSVP.
Authors
Dr. Roch Guerin
Shai Herzog
Steven L. Blake
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)