A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow
RFC 4495

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

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-priority