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
|
|
---|---|---|---|
Authors | Subha Dhesikan , James Polk | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4495 (Proposed Standard) | |
Action Holders |
(None)
|
||
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 will cause packets to be discarded during aggregate reservation reestablishment. This document describes a method where only the minimum required bandwidth is taken away from the lower-priorityShow full document text