A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow
RFC 4495
| Document | Type |
RFC - Proposed Standard
(May 2006; No errata)
Updates RFC 2205
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4495 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Allison Mankin | ||
| Send notices to | jon@unreason.com, jon.peterson@neustar.biz, mankin@psg.com | ||
Network Working Group J. Polk
Request for Comments: 4495 S. Dhesikan
Updates: 2205 Cisco Systems
Category: Standards Track May 2006
A Resource Reservation Protocol (RSVP) Extension for the
Reduction of Bandwidth of a Reservation Flow
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 (2006).
Abstract
This document proposes an extension to the Resource Reservation
Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an
existing reservation. This mechanism can be used to affect
individual reservations, aggregate reservations, or other forms of
RSVP tunnels. This specification is an extension of RFC 2205.
Polk & Dhesikan Standards Track [Page 1]
RFC 4495 RSVP Bandwidth Reduction May 2006
Table of Contents
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................4
2. Individual Reservation Reduction Scenario .......................4
3. RSVP Aggregation Overview .......................................6
3.1. RSVP Aggregation Reduction Scenario ........................8
4. Requirements for Reservation Reduction ..........................9
5. RSVP Bandwidth Reduction Solution ..............................10
5.1. Partial Preemption Error Code .............................11
5.2. Error Flow Descriptor .....................................11
5.3. Individual Reservation Flow Reduction .....................11
5.4. Aggregation Reduction of Individual Flows .................12
5.5. RSVP Flow Reduction Involving IPsec Tunnels ...............12
5.6. Reduction of Multiple Flows at Once .......................13
6. Backwards Compatibility ........................................13
7. Security Considerations ........................................14
8. IANA Considerations ............................................15
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................16
Appendix A. Walking through the Solution ..........................17
1. Introduction
This document proposes an extension to the Resource Reservation
Protocol (RSVP) [1] to allow an existing reservation to be reduced in
allocated bandwidth in lieu of tearing that reservation down when
some of that reservation's bandwidth is needed for other purposes.
Several examples exist in which this mechanism may be utilized.
The bandwidth allotted to an individual reservation may be reduced
due to a variety of reasons such as preemption, etc. In such cases,
when the entire bandwidth allocated to a reservation is not required,
the reservation need not be torn down. The solution described in
this document allows endpoints to negotiate a new (lower) bandwidth
that falls at or below the specified new bandwidth maximum allocated
by the network. Using a voice session as an example, this indication
in RSVP could lead endpoints, using another protocol such as Session
Initiation Protocol (SIP) [9], to signal for a lower-bandwidth codec
and retain the reservation.
With RSVP aggregation [2], two aggregate flows with differing
priority levels may traverse the same router interface. If that
router interface reaches bandwidth capacity and is then asked to
establish a new reservation or increase an existing reservation, the
Polk & Dhesikan Standards Track [Page 2]
RFC 4495 RSVP Bandwidth Reduction May 2006
router has to make a choice: deny the new request (because all
resources have been utilized) or preempt an existing lower-priority
reservation to make room for the new or expanded reservation.
If the flow being preempted is an aggregate of many individual flows,
this has greater consequences. While [2] clearly does not terminate
all the individual flows if an aggregate is torn down, this event
Show full document text