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.

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

   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
   aggregated reservation and the entire reservation is not preempted.
   This has the advantage that only some of the microflows making up the
   aggregate are affected.  Without this extension, all individual flows
   are affected and the deaggregator will have to attempt the
   reservation request with a reduced bandwidth.

   RSVP tunnels utilizing IPsec [8] also require an indication that the
   reservation must be reduced to a certain amount (or less).  RSVP
   aggregation with IPsec tunnels is being defined in [11], which should
   be able to take advantage of the mechanism created here in this
   specification.

   Note that when this document refers to a router interface being
   "full" or "at capacity", this does not imply that all of the
   bandwidth has been used, but rather that all of the bandwidth
   available for reservation(s) via RSVP under the applicable policy has
   been used.  Policies for real-time traffic routinely reserve capacity
   for routing and inelastic applications, and may distinguish between
   voice, video, and other real-time applications.

   Explicit Congestion Notification (ECN) [10] is an indication that the
   transmitting endpoint must reduce its transmission.  It does not
   provide sufficient indication to tell the endpoint by how much the
   reduction should be.  Hence the application may have to attempt
   multiple times before it is able to drop its bandwidth utilization
   below the available limit.  Therefore, while we consider ECN to be
   very useful for elastic applications, it is not sufficient for the
   purpose of inelastic application where an indication of bandwidth
   availability is useful for codec selection.

   Section 2 discusses the individual reservation flow problem, while
   Section 3 discusses the aggregate reservation flow problem space.
   Section 4 lists the requirements for this extension.  Section 5
   details the protocol changes necessary in RSVP to create a
   reservation reduction indication.  And finally, the appendix provides
   a walk-through example of how this extension modifies RSVP
   functionality in an aggregate scenario.

   This document updates RFC 2205 [1], as this mechanism affects the
   behaviors of the ResvErr and ResvTear indications defined in that
   document.

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [4].

2.  Individual Reservation Reduction Scenario

   Figure 1 is a network topology that is used to describe the benefit
   of bandwidth reduction in an individual reservation.

               +------------+            +------------+
               |     |Int 1 |            |Int 7 |     |
   Flow 1===>  |     +----- |            |------+     | Flow 1===>
               | R1  |Int 2 |===========>|Int 8 | R2  |
               |     |      |:::::::::::>|      |     |
   Flow 2:::>  |     +----- |            |------+     | Flow 2:::>
               |     |Int 3 |            |Int 9 |     |
               +------------+            +------------+

                   Figure 1.  Simple Reservation Flows

         Legend/Rules:

         - Flow 1 priority = 300
         - Flow 2 priority = 100
         - Both flows are shown in the same direction (left to
           right).  Corresponding flows in the reverse direction are
           not shown for diagram simplicity

   RSVP is a reservation establishment protocol in one direction only.
   This split-path philosophy is because the routed path from one device
   to the other in one direction might not be the routed path for
   communicating between the same two endpoints in the reverse
   direction.  End-systems must request 2 one-way reservations if that
   is what is needed for a particular application (like voice calls).
   Please refer to [1] for the details on how this functions.  This
   example only describes the reservation scenario in one direction for
   simplicity’s sake.

   Figure 1 depicts 2 routers (R1 and R2) initially with only one flow
   (Flow 1).  The flows are forwarded from R1 to R2 via Int 2.  For this
   example, let us say that Flow 1 and Flow 2 each require 80 units of
   bandwidth (such as for the codec G.711 with no silence suppression).

   Let us also say that the RSVP bandwidth limit for Int 2 of R1 is 100
   units.

   As described in [3], a priority indication is established for each
   flow.  In fact, there are two priority indications:

      1) one to establish the reservation, and

      2) one to defend the reservation.

   In this example, Flow 1 and Flow 2 have an ’establishing’ and a
   ’defending’ priority of 300 and 100, respectively.  Flow 2 will have
   a higher establishing priority than Flow 1 has for its defending
   priority.  This means that when Flow 2 is signaled, and if no
   bandwidth is available at the interface, Flow 1 will have to
   relinquish bandwidth in favor of the higher-priority request of Flow
   2.  The priorities assigned to a reservation are always end-to-end,
   and not altered by any routers in transit.

   Without the benefit of this specification, Flow 1 will be preempted.
   This specification makes it possible for the ResvErr message to
   indicate that 20 units are still available for a reservation to
   remain up (the interface’s 100 units maximum minus Flow 2’s 80
   units).  The reservation initiating node (router or end-system) for
   Flow 1 has the opportunity to renegotiate (via call signaling) for
   acceptable parameters within the existing and available bandwidth for
   the flow (for example, it may decide to change to using a codec such
   as G.729)

   The problems avoided with the partial failure of the flow are:

   - Reduced packet loss, which results as Flow 1 attempts to
     reestablish the reservation for a lower bandwidth.

   - Inefficiency caused by multiple attempts until Flow 1 is able to
     request bandwidth equal to or lower than what is available.  If
     Flow 1 is established with much less than what is available then it
     leads to inefficient use of available bandwidth.

3.  RSVP Aggregation Overview

   The following network overview is to help visualize the concerns that
   this specification addresses in RSVP aggregates.  Figure 2 consists
   of 10 routers (the boxes) and 11 flows (1, 2, 3, 4, 5, 9, A, B, C, D,
   and E).  Initially, there will be 5 flows per aggregate (Flow 9 will
   be introduced to cause the problem we are addressing in this
   document), with 2 aggregates (X and Y); Flows 1 through 5 in
   aggregate X and Flows A through E in aggregate Y.  These 2 aggregates
   will cross one router interface utilizing all available capacity (in
   this example).

   RSVP aggregation (per [2]) is no different from an individual
   reservation with respect to being unidirectional.

           Aggregator of X                             Deaggregator of X
                |                                          |
                V                                          V
             +------+   +------+            +------+   +------+
    Flow 1-->|      |   |      |            |      |   |      |-->Flow 1
    Flow 2-->|      |   |      |            |      |   |      |-->Flow 2
    Flow 3-->|      |==>|      |            |      |==>|      |-->Flow 3
    Flow 4-->|      | ^ |      |            |      | ^ |      |-->Flow 4
    Flow 5-->|      | | |      |            |      | | |      |-->Flow 5
    Flow 9   |  R1  | | |  R2  |            |  R3  | | |  R4  |   Flow 9
             +------+ | +------+            +------+ | +------+
                      |   ||                  ||     |
            Aggregate X-->||    Aggregate X   ||<--Aggregate X
                          ||        |         ||
               +--------------+     |      +--------------+
               |       |Int 7 |     |      |Int 1 |       |
               |       +----- |     V      |------+       |
               |   R10 |Int 8 |===========>|Int 2 | R11   |
               |       |      |:::::::::::>|      |       |
               |       +----- |     ^      |------+       |
               |       |Int 9 |     |      |Int 3 |       |
               +--------------+     |      +--------------+
                          ..        |        ..
           Aggregate Y--->..    Aggregate Y  ..<---Aggregate Y
                     |    ..                 ..     |
            +------+ | +------+            +------+ | +------+
   Flow A-->|      | | |      |            |      | | |      |-->Flow A
   Flow B-->|      | V |      |            |      | V |      |-->Flow B
   Flow C-->|      |::>|      |            |      |::>|      |-->Flow C
   Flow D-->|      |   |      |            |      |   |      |-->Flow D
   Flow E-->|  R5  |   |  R6  |            |  R7  |   |  R8  |-->Flow E
            +------+   +------+            +------+   +------+
               ^                                         ^
               |                                         |
       Aggregator of Y                              Deaggregator of Y

                 Figure 2.  Generic RSVP Aggregate Topology

         Legend/Rules:

         - Aggregate X priority = 100
         - Aggregate Y priority = 200
         - All boxes are routers
         - Both aggregates are shown in the same direction (left to
           right).  Corresponding aggregates in the reverse direction
           are not shown for diagram simplicity.

      The path for aggregate X is:

         R1 => R2 => R10 => R11 => R3 => R4

      where aggregate X starts in R1, and deaggregates in R4.

      Flows 1, 2, 3, 4, 5, and 9 communicate through aggregate A.

      The path for aggregate Y is:

         R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8

      where aggregate Y starts in R5, and deaggregates in R8.

      Flows A, B, C, D, and E communicate through aggregate B.

   Both aggregates share one leg or physical link: between R10 and R11,
   thus they share one outbound interface: Int 8 of R10, where
   contention of resources may exist.  That link has an RSVP capacity of
   800 kbps.  RSVP signaling (messages) is outside the 800 kbps in this
   example, as is any session signaling protocol like SIP.

3.1.  RSVP Aggregation Reduction Scenario

   Figure 2 shows an established aggregated reservation (aggregate X)
   between the routers R1 and R4.  This aggregated reservation consists
   of 5 microflows (Flows 1, 2, 3, 4, and 5).  For the sake of this
   discussion, let us assume that each flow represents a voice call and
   requires 80 kb (such as for the codec G.711 with no silence
   suppression).  Aggregate X request is for 400 kbps (80 kbps * 5
   flows).  The priority of the aggregate is derived from the individual
   microflows that it is made up of.  In the simple case, all flows of a
   single priority are bundled as a single aggregate (another priority
   level would be in another aggregate, even if traversing the same path
   through the network).  There may be other ways in which the priority
   of the aggregate is derived, but for this discussion it is sufficient
   to note that each aggregate contains a priority (both hold and
   defending priority).  The means of deriving the priority is out of
   scope for this discussion.

   Aggregate Y, in Figure 2, consists of Flows A, B, C, D, and E and
   requires 400 kbps (80 kbps * 5 flows), and starts at R5 and ends R8.
   This means there are two aggregates occupying all 800 kbps of the
   RSVP capacity.

   When Flow 9 is added into aggregate X, this will occupy 80 kbps more
   than Int 8 on R10 has available (880k offered load vs. 800k capacity)
   [1] and [2] create a behavior in RSVP to deny the entire aggregate Y

   and all its individual flows because aggregate X has a higher
   priority.  This situation is where this document focuses its
   requirements and calls for a solution.  There should be some means to
   signal to all affected routers of aggregate Y that only 80 kbps is
   needed to accommodate another (higher priority) aggregate.  A
   solution that accomplishes this reduction instead of a failure could:

      - reduce significant packet loss of all flows within aggregate Y

   During the re-reservation request period of time no packets will
   traverse the aggregate until it is reestablished.

      - reduces the chances that the reestablishment of the aggregate
        will reserve an inefficient amount of bandwidth, causing the
        likely preemption of more individual flows at the aggregator
        than would be necessary had the aggregator had more information
        (that RSVP does not provide at this time)

   During reestablishment of the aggregation in Figure 2 (without any
   modification to RSVP), R8 would guess at how much bandwidth to ask
   for in the new RESV message.  It could request too much bandwidth,
   and have to wait for the error that not that much bandwidth was
   available; it could request too little bandwidth and have that
   aggregation accepted, but this would mean that more individual flows
   would need to be preempted outside the aggregate than were necessary,
   leading to inefficiencies in the opposite direction.

4.  Requirements for Reservation Reduction

   The following are the requirements to reduce the bandwidth of a
   reservation.  This applies to both individual and aggregate
   reservations:

   Req#1 - MUST have the ability to differentiate one reservation from
           another.  In the case of aggregates, it MUST distinguish one
           aggregate from other flows.

   Req#2 - MUST have the ability to indicate within an RSVP error
           message (generated at the router with the congested
           interface) that a specific reservation (individual or
           aggregate) is to be reduced in bandwidth.

   Req#3 - MUST have the ability to indicate within the same error
           message the new maximum amount of bandwidth that is available
           to be utilized within the existing reservation, but no more.

   Req#4 - MUST NOT produce a case in which retransmitted reduction
           indications further reduce the bandwidth of a reservation.
           Any additional reduction in bandwidth for a specified
           reservation MUST be signaled in a new message.

   RSVP messages are unreliable and can get lost.  This specification
   should not compound any error in the network.  If a reduction message
   were lost, another one needs to be sent.  If the receiver ends up
   receiving two copies to reduce the bandwidth of a reservation by some
   amount, it is likely the router will reduce the bandwidth by twice
   the amount that was actually called for.  This will be in error.

5.  RSVP Bandwidth Reduction Solution

   When a reservation is partially failed, a ResvErr (Reservation Error)
   message is generated just as it is done currently with preemptions.
   The ERROR_SPEC object and the PREEMPTION_PRI object are included as
   well.  Very few additions/changes are needed to the ResvErr message
   to support partial preemptions.  A new error subcode is required and
   is defined in Section 5.1.  The ERROR_SPEC object contained in the
   ResvErr message indicates the flowspec that is reserved.  The
   bandwidth indication in this flowspec SHOULD be less than the
   original reservation request.  This is defined in Section 5.2.

   A comment about RESV messages that do not use reliable transport:
   This document RECOMMENDS that ResvErr messages be made reliable by
   implementing mechanisms in [6].

   The current behavior in RSVP requires a ResvTear message to be
   transmitted upstream when the ResvErr message is transmitted
   downstream (per [1]).  This ResvTear message terminates the
   reservation in all routers upstream of the router where the failure
   occurred.  This document requires that the ResvTear is only generated
   when the reservation is to be completely removed.  In cases where the
   reservation is only to be reduced, routers compliant with this
   specification require that the ResvTear message MUST NOT be sent.

   The appendix has been written to walk through the overall solution to
   the problems presented in Sections 2 and 3.  There is mention of this
   ResvTear transmission behavior in the appendix.

5.1.  Partial Preemption Error Code

   The ResvErr message generated due to preemption includes the
   ERROR_SPEC object as well as the PREEMPTION_PRI object.  The format
   of ERROR_SPEC objects is defined in [1].  The error code listed in
   the ERROR_SPEC object for preemption [5] currently is as follows:

         Errcode = 2 (Policy Control Failure) and
         ErrSubCode = 5 (ERR_PREEMPT)

   The following error code is suggested in the ERROR_SPEC object for
   partial preemption:

      Errcode = 2 (Policy Control Failure) and
      ErrSubCode = 102 (ERR_PARTIAL_PREEMPT)