Transport Area Working Group                                 James Polk
Internet Draft                                           Subha Dhesikan
Expiration: July 24th, 2005                               Cisco Systems
File: draft-ietf-tsvwg-rsvp-bw-reduction-02.txt      January 24th, 2005




            A Resource Reservation Protocol Extension for the
              Reduction of Bandwidth of a Reservation Flow



Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 24th, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).  All Rights Reserved.


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.




Polk & Dhesikan         Expires July 24th, 2006                [Page 1]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006

   Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1  Conventions  . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Individual Reservation Reduction Scenario . . . . . . . . . .  4
   3.  RSVP Aggregation Overview . . . . . . . . . . . . . . . . . .  5
       3.1 RSVP Aggregation Reduction Scenario . . . . . . . . . . .  7
   4.  Requirements for Reservation Reduction  . . . . . . . . . . .  8
   5.  RSVP Bandwidth Reduction Solution . . . . . . . . . . . . . .  9
       5.1  Partial Preemption Error Code  . . . . . . . . . . . . .  9
       5.2  Error Flow Descriptor  . . . . . . . . . . . . . . . . . 10
       5.3  Individual Reservation Flow Reduction  . . . . . . . . . 10
       5.4  Aggregation Reduction of Individual Flows  . . . . . . . 10
       5.5  RSVP Flow Reduction involving IPSec Tunnels  . . . . . . 11
       5.6  Reduction of Multiple Flows At Once  . . . . . . . . . . 11
   6.  Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations   . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 13
   Appendix. Walking Through the Solution  . . . . . . . . . . . . . 13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . 16
       10.1 Normative References . . . . . . . . . . . . . . . . . . 16
       10.2 Informational References . . . . . . . . . . . . . . . . 17
       Author Information  . . . . . . . . . . . . . . . . . . . . . 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.


Polk & Dhesikan         Expires July 24th, 2006                [Page 2]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006


   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 will discuss the individual reservation flow problem
   while Section 3 will discuss 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, there is an appendix
   with a walk-through example of how this extension modifies RSVP
   functionality in an aggregate scenario.

   This document is intended to be classified as an 'update' to RFC
   2205 [1], as this mechanism affects the behaviors of the ResvErr and
   ResvTear indications defined in that document.






Polk & Dhesikan         Expires July 24th, 2006                [Page 3]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006

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

        Figure 1. 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 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
   interface 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 interface 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


Polk & Dhesikan         Expires July 24th, 2006                [Page 4]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006


      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 re-negotiate (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 is resulted as flow 1 attempts to
     re-establish 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 5 flows per aggregate
   (flow 9 will be introduced to cause the problem we are addressing in
   this document),with 2 aggregates (X & Y); (1 through 5) in aggregate
   X and (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.








Polk & Dhesikan         Expires July 24th, 2006                [Page 5]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006

         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

    Figure 2 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.


Polk & Dhesikan         Expires July 24th, 2006                [Page 6]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006


      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: Int8 of R10, where
   contention of resources may exist.  That link has an RSVP capacity
   of 800kbps.  RSVP signaling (messages) is outside this 800kbps 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 (flow 1, 2, 3, 4, 5). For the sake of this
   discussion, let us assume that each flow represents a voice call and
   requires 80kb (such as for the codec G.711 with no silence
   suppression). Aggregate X request is for 400kbps (80kbps * 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 400kbps (80kbps * 5 flows), and starts at R5 and ends
   R8.  This means there are two aggregates occupying all 800kbps of
   the RSVP capacity.

   When Flow 9 is added into aggregate X, this will occupy 80kbps more
   than Int8 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 80kbps is
   needed to accommodate another (higher priority) aggregate.  A
   solution that accomplishes this reduction instead of a failure
   could:



Polk & Dhesikan         Expires July 24th, 2006                [Page 7]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006

      - 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 meant 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 than was actually called for.  This


Polk & Dhesikan         Expires July 24th, 2006                [Page 8]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006

   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 policy
   object are included as well.  Very few additions/changes are needed
   to the ResvErr message to support partial preemptions. A new error
   sub code is required and is defined in section 5.1.  The error
   flowspec contained in the ResvErr message indicates the flowspec
   that is reserved and this flowspec may not match or be less than the
   original reservation request.  This is defined in section 5.2.

   A comment about RESV message not using a reliable transport.  This
   document recommends that ResvErr message 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 requires that the ResvTear message MUST NOT be
   sent.

   An 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 within 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 Priority Policy 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 = X (ERR_PARTIAL_PREEMPT)

      Where 'X' is the number assigned by IANA for this error code


Polk & Dhesikan         Expires July 24th, 2006                [Page 9]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006


   There is also an error code in the preemption-pri policy object.
   This error code takes a value of 1 to indicate that the admitted
   flow was preempted [3].  The same error value of 1 may be used for
   the partial preemption case as well.


5.2 Error Flow Descriptor

   The error flow descriptor is defined in [1] & [7].  In the case of
   partial failure, the flowspec contained in the error flow
   descriptor indicates the highest average and peak rates that the
   preempting system can accept in the next RESV message.  The
   deaggregator must reduce its reservation to a number less than or
   equal to that, whether by changing codecs, by dropping reservations,
   or some other mechanism.


5.3 Individual Reservation Flow Reduction

   When a router requires part of the bandwidth that has been allocated
   to a reservation be used for another flow, the router engages in the
   partial-reduction of bandwidth as described in this document. The
   router sends a ResvErr downstream to indicate the partial error with
   the error code and sub code as described in section 5.1. The
   flowspec contained in the ResvErr message will be used to indicate
   the bandwidth that is currently allocated.

   The requesting endpoint that receives the ResvErr can then negotiate
   with the transmitting endpoint to lower the bandwidth requirement
   (by selecting another lower bandwidth codec, for example). After the
   negotiations, both endpoints will issue the RSVP PATH and RESV
   message with the new, lowered bandwidth.


5.4 Aggregation Reduction of Individual Flows

   When a partial-failure occurs in a aggregation scenario, the
   deaggregator receives the ResvErr message with the reduction
   indication from a router in the path of the aggregate. It then
   decides whether one or more individual flows from the aggregate are
   to be affected by this ResvErr message.  The following choices are
   possible:

   o If that (deaggregator) router determines one or more individual
     flow(s) are to partially failed, then it sends a ResvErr message
     with a reduced bandwidth indication to those individual flow(s).
     This is as per the descriptions in the previous section (5.3).

   o If that (deaggregator) router determines one individual flow is to
     be preempted to satisfy the aggregate ResvErr, it determines which
     flow is affected.  That router transmits a new ResvErr message


Polk & Dhesikan         Expires July 24th, 2006               [Page 10]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006

     downstream per [3].  That same router transmits a ResvTear message
     upstream.  This ResvTear message of an individual flow does not
     tear down the aggregate.  Only the individual flow is affected.

   o If that (deaggregator) router determines multiple individual flows
     are to be preempted to satisfy the aggregate ResvErr, it chooses
     which flows are affected.  That router transmits a new ResvErr
     message downstream as per [3] to each individual flow.  The router
     also transmits ResvTear messages upstream for the same individual
     flows.  These ResvTear messages of an individual flow do not tear
     down the aggregate.  Only the individual flows are affected.

   In all cases, the Deaggregator lowers the bandwidth requested in the
   Aggregate Resv message to reflect the change.

   Which particular flow or series of flows within an aggregate are
   picked by the deaggregator for bandwidth reduction or preemption is
   outside the scope of this document.


5.5 RSVP Flow Reduction involving IPSec Tunnels

   RFC 2207 (per [8]) specifies how RSVP reservations function in IPSec
   data flows.  The nodes initiating the IPSec flow can be an end-
   system like a computer, or it can router between two end-systems, or
   it can be an in-line bulk encryption device immediately adjacent to
   a router interface, [11] directly addresses this later scenario.

   The methods of identification of an IPSec with reservation flow are
   different than non-encrypted flows, but how the reduction mechanism
   specified within this document functions is not.

   An IPSec with reservation flow is, for all intents and purposes,
   considered an individual flow with regard to how to reduce the
   bandwidth of the flow.  Obviously an IPSec with reservation flow can
   be a series of individual flows or disjointed best effort packets
   between two systems.  But to this specification, this tunnel is an
   individual RSVP reservation.

   Anywhere within this specification that mentions an individual
   reservation flow, the same rules of bandwidth reduction and
   preemption MUST apply.

5.6 Reduction of Multiple Flows at Once

   As a cautionary note, bandwidth SHOULD NOT be reduced across
   multiple reservations at the same time, in reaction to the same
   reduction event.  A router not knowing the impact of reservation
   bandwidth reduction on more than one flow may cause more wide spread
   ill effects than is necessary.

   This says nothing to a policy where preemption should or should not


Polk & Dhesikan         Expires July 24th, 2006               [Page 11]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006

   occur across multiple flows.


6. Backwards Compatibility

   Backwards compatibility with this extension will result in RSVP
   operating as it does without this extension, and no worse.  The two
   routers involved in this extension are the router that had the
   congested interface and the furthest downstream router that
   determines what to do with the reduction indication.

   In the case of the router that experiences congestion or otherwise
   needs to reduce the bandwidth of an existing reservation:

   - If that router supports this extension:

     #1 - it generates the ResvErr message with the error code
          indicating the reduction in bandwidth

     #2 - it does not generate the ResvTear message

   - If that router does not support this extension, it generates both
     ResvErr and ResvTear messages according to [1].

   In the case of the router at the extreme downstream of a reservation
   that receives the ResvErr message with the reduction indication

   - If that router does support this extension:

     #1 - it processes this error message and applies whatever local
          policy it is configured to do to determine how to reduce the
          bandwidth of this designated flow

   - If the router does not support this extension:

     #1 - it processes the ResvErr message according to [1] and all
          extensions it is able to understand, but not this extension
          from this document.

   Thus, this extension does not cause ill effects within RSVP if one
   or more routers support this extension, and one or more routers do
   not support this extension.


7.  Security Considerations

   This document does not lessen the overall security of RSVP or of
   reservation flows through an aggregate.

   If this specification is implemented poorly - which is never
   intended, but is a consideration - the following issues may arise:



Polk & Dhesikan         Expires July 24th, 2006               [Page 12]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006

   1) If the ResvTear messages are transmitted initially (at the same
      time as the ResvErr messages indicating a reduction in bandwidth
      is necessary), all upstream routers will tear down the entire
      reservation.  This will free up the total amount of bandwidth of
      this reservation inadvertently.  This may cause the re-
      establishment of an otherwise good reservation to fail.  This has
      the most severe affects on an aggregate that has many individual
      flows that would have remained operational.

   2) Just as RSVP has the vulnerability of premature termination of
      valid reservations by rouge flows without authentication
      [12 & 13], this mechanism will have the same vulnerability.
      Usage of RSVP authentication mechanisms is encouraged.


8.  IANA Considerations

   IANA is to assign the following from RFC [XXXX] (i.e. this
   document):

   The following error code is to be defined in the Error_spec object
   for partial reservation failure under "Errcode = 2 (Policy Control
   Failure)":

      ErrSubCode = X (ERR_PARTIAL_PREEMPT)

      Where 'X' is assigned by IANA for this error code

   The behavior of this ErrSubCode is defined in this document.


9.  Acknowledgements

   The authors would like to thank Fred Baker for contributing text and
   guidance in this effort and to Roger Levesque and Francois Le
   Faucheur for helpful comments.


Appendix 1. Walking Through the Solution

   Here is a concise explanation of roughly how RSVP behaves with the
   solution to the problems presented in sections 2 & 3 of this
   document.  There is no normative text in this appendix.

   Here is a duplicate of Figure 2 from section 3 of the document body
   (to bring it closer to the detailed description of the solution).








Polk & Dhesikan         Expires July 24th, 2006               [Page 13]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006

      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

         Duplicate of Figure 2. Generic RSVP Aggregate Topology


   Looking at Figure 2., aggregate X (with five 80kbps flows)
   traverses:

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

   And aggregate Y (with five 80kbps flows) traverses:

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

   Both aggregates are 400kbps.  This totals 800kbps at Interface-7 in
   R10, which is the maximum bandwidth RSVP has access to at this
   interface.  Signaling messages still traverse the interface without
   problem.  Aggregate X is at a higher relative priority than


Polk & Dhesikan         Expires July 24th, 2006               [Page 14]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006

   aggregate Y.  Local policy in this example is for higher relative
   priority flows to preempt lower priority flows during times of
   congestion.  The following points describe the flow when aggregate A
   is increased to include flow 9.

   o   When flow 9 (at 80kbps) is added to aggregate X, R1 will
       initiate the PATH message towards the destination endpoint of
       the flow. This hop-by-hop message will take it through R2,
       R10, R11, R3 and R4 which is the aggregate X path (that
       was built per [2] from the aggregate's initial set up) to the
       endpoint node.

   o   In response, R4 will generate the RESV (reservation) message
       [defined behavior per 1].  This RESV from the deaggregator
       indicates an increase bandwidth sufficient to accommodate the
       existing 5 flows (1,2,3,4,5) and the new flow (9) [as stated in
       2].

   o   As mentioned before, in this example, Int8 in R 10 can only
       accommodate 800kbps, and aggregates X and Y have each already
       established 400kbps flows comprised of five 80kbps individual
       flows. Therefore, R10 (the interface that detects a congestion
       event in this example) must make a decision about this new
       congestion generating condition in regard to the RESV message
       received at Int8.

   o   Local Policy in this scenario is to preempt lower priority
       reservations to place higher priority reservations.  This would
       normally cause all of aggregate Y to be preempted just to
       accommodate aggregate X's request for an additional 80kbps.

   o   This document defines how aggregate Y is not completely
       preempted, but reduced in bandwidth by 80kbps.  This is
       contained in the ResvErr message that R10 generates
       (downstream) towards R11, R7 and R8.  See section 5 for
       the details of the error message.

   o   Normal operation of RSVP is to have the router that generates a
       ResvErr message downstream to also generate a ResvTear message
       upstream (in the opposite direction towards R5).  The ResvTear
       message terminates an individual flow or aggregate flow.  This
       document calls for that message to not be sent on any partial
       failure of reservation.

   o   R8 is the deaggregator of aggregate Y.  The deaggregator
       controls all the parameters of an aggregate reservation.  This
       will be the node that reduces the necessary bandwidth of the
       aggregate as a response to the reception of an ResvErr message
       (from R10) indicating such an action is called for.  In this
       example, bandwidth reduction is accomplished by preempting an
       individual flow within the aggregate (perhaps picking on Flow D
       for individual preemption by generating a ResvErr downstream on


Polk & Dhesikan         Expires July 24th, 2006               [Page 15]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006

       that individual flow).

   o   At the same time, a ResvTear message is transmitted upstream on
       that individual flow (Flow D) by R8.  This will not affect the
       aggregate directly, but is an indication to the routers (and the
       source end-system) which individual flow is to be preempted.

   o   Once R8 preempts whichever individual flow (or 'bandwidth' at
       the aggregate ingress), it transmits a new RESV message for that
       aggregate (Y), not for a new aggregate.  This RESV from the
       deaggregator indicates an decrease in bandwidth sufficient to
       accommodate the remaining 4 flows (A,B,C,E), which is now
       320kbps (in this example).

   o   This RESV message travels the entire path of the reservation,
       resetting all routers to this new aggregate bandwidth value.
       This should be what is necessary to prevent a ResvTear message
       from being generated by R10 towards R6 and R5.

   R5 will not know through this RESV message which individual flow
   was preempted.  If in this example, R8 was given more bandwidth to
   keep, it might have transmitted a bandwidth reduction ResvErr
   indication towards the end-system of Flow D.  In that case, a voice
   signaling protocol (such as SIP) could have attempted a
   renegotiation of that individual flow to a reduced bandwidth (say,
   but changing the voice codec from G.711 to G. 729).  This could have
   saved Flow D from preemption.


10. References

10.1  Normative References

 [1] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
     "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
     Specification", RFC 2205, September 1997

 [2] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of
     RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001

 [3] S. Herzog, "Signaled Preemption Priority Policy Element", RFC
     3181, October 2001

 [4] Bradner S., "Key words for use in RFCs to Indicate Requirement
     Levels", RFC 2119, March 1997

 [5] S. Herzog, "RSVP Extensions for Policy Control", RFC 2750,
     January 2000

 [6] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini,
     "RSVP Refresh Overhead Reduction Extensions" RFC 2961, April 2001



Polk & Dhesikan         Expires July 24th, 2006               [Page 16]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006

 [7] J. Wroclawski, "The Use of RSVP with IETF Integrated Services",
     RFC 2210, September 1997

 [8] L. Berger, T. O'Malley, "RSVP Extensions for IPSEC Data Flows",
     RFC 2207, September 1997

10.2  Informational References

 [9] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,
     J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
     Session Initiation Protocol", RFC 3261, May 2002.

 [10] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit
      Congestion Notification (ECN) to IP", RFC 3168, September 2001

 [11] F. Le Faucheur, B. Davie, P. Bose, C. Christou, " Aggregate
      reservations for IPSec Tunnel", draft-lefaucheur-rsvp-ipsec-01,
      July 2005, "work in progress"

 [12] F. Baker, B. Lindell, M. Talwar, "RSVP Cryptographic
      Authentication", RFC 2747, January 2000

 [13] R. Braden, L. Zhang, "RSVP Cryptographic Authentication --
      Updated Message Type Value", RFC 3097, April 2001


  Author Information

   James M. Polk
   Cisco Systems
   2200 East President George Bush Turnpike
   Richardson, Texas 75082 USA

   Email: jmpolk@cisco.com

   Subha Dhesikan
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA 95134 USA

 Email: sdhesika@cisco.com


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC


Polk & Dhesikan         Expires July 24th, 2006               [Page 17]


Internet Draft         RSVP Bandwidth Reduction          Jan 24th, 2006

   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.


   The Expiration date for this Internet Draft is:

   July 24th, 2006











Polk & Dhesikan         Expires July 24th, 2006               [Page 18]