GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4495

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

Polk & Dhesikan Standards Track [Page 3] RFC 4495 RSVP Bandwidth Reduction May 2006

 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:
  1. Flow 1 priority = 300
  2. Flow 2 priority = 100
  3. 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).

Polk & Dhesikan Standards Track [Page 4] RFC 4495 RSVP Bandwidth Reduction May 2006

 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:
  1. Reduced packet loss, which results as Flow 1 attempts to

reestablish the reservation for a lower bandwidth.

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

Polk & Dhesikan Standards Track [Page 5] RFC 4495 RSVP Bandwidth Reduction May 2006

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.

Polk & Dhesikan Standards Track [Page 6] RFC 4495 RSVP Bandwidth Reduction May 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
       Legend/Rules:
  1. Aggregate X priority = 100
  2. Aggregate Y priority = 200
  3. All boxes are routers
  4. Both aggregates are shown in the same direction (left to

right). Corresponding aggregates in the reverse direction

         are not shown for diagram simplicity.

Polk & Dhesikan Standards Track [Page 7] RFC 4495 RSVP Bandwidth Reduction May 2006

    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

Polk & Dhesikan Standards Track [Page 8] RFC 4495 RSVP Bandwidth Reduction May 2006

 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:
  1. 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.
  1. 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.

Polk & Dhesikan Standards Track [Page 9] RFC 4495 RSVP Bandwidth Reduction May 2006

 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.

Polk & Dhesikan Standards Track [Page 10] RFC 4495 RSVP Bandwidth Reduction May 2006

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)
 There is also an error code in the PREEMPTION-PRI 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] and [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, 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 subcode 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.

Polk & Dhesikan Standards Track [Page 11] RFC 4495 RSVP Bandwidth Reduction May 2006

5.4. Aggregation Reduction of Individual Flows

 When a partial failure occurs in an 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 that 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 that 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 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 that 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.

Polk & Dhesikan Standards Track [Page 12] RFC 4495 RSVP Bandwidth Reduction May 2006

 The methods of identification of an IPsec with reservation flow are
 different from 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 widespread ill effects
 than is necessary.
 This says nothing to a policy where preemption should or should not
 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:
  1. 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.
  1. If that router does not support this extension, it generates both

ResvErr and ResvTear messages according to [1].

Polk & Dhesikan Standards Track [Page 13] RFC 4495 RSVP Bandwidth Reduction May 2006

 In the case of the router at the extreme downstream of a reservation
 that receives the ResvErr message with the reduction indication:
  1. 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.
  1. 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:
 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 rogue flows without authentication [12, 13],
    this mechanism will have the same vulnerability.  Usage of RSVP
    authentication mechanisms is encouraged.

Polk & Dhesikan Standards Track [Page 14] RFC 4495 RSVP Bandwidth Reduction May 2006

8. IANA Considerations

 The IANA has assigned the following from RFC 4495 (i.e., this
 document):
 The following error code has been defined in the ERROR_SPEC object
 for partial reservation failure under "Errcode = 2 (Policy Control
 Failure)":
    ErrSubCode = 102 (ERR_PARTIAL_PREEMPT)
 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.

10. References

10.1. Normative References

 [1]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
      Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
      Functional Specification", RFC 2205, September 1997.
 [2]  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
      "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
      September 2001.
 [3]  Herzog, S., "Signaled Preemption Priority Policy Element", RFC
      3181, October 2001.
 [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [5]  Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
      January 2000.
 [6]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S.
      Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
      2961, April 2001.
 [7]  Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
      RFC 2210, September 1997.

Polk & Dhesikan Standards Track [Page 15] RFC 4495 RSVP Bandwidth Reduction May 2006

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

10.2. Informative References

 [9]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
      Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
      Session Initiation Protocol", RFC 3261, June 2002.
 [10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
      Explicit Congestion Notification (ECN) to IP", RFC 3168,
      September 2001.
 [11] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M.
      Davenport, "Generic Aggregate RSVP Reservations", Work in
      Progress, October 2005.
 [12] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
      Authentication", RFC 2747, January 2000.
 [13] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication --
      Updated Message Type Value", RFC 3097, April 2001.

Polk & Dhesikan Standards Track [Page 16] RFC 4495 RSVP Bandwidth Reduction May 2006

Appendix A. Walking through the Solution

 Here is a concise explanation of roughly how RSVP behaves with the
 solution to the problems presented in Sections 2 and 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).
      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

Polk & Dhesikan Standards Track [Page 17] RFC 4495 RSVP Bandwidth Reduction May 2006

 Looking at Figure 2, aggregate X (with five 80 kbps flows) traverses:
       R1 ==> R2 ==> R10 ==> R11 ==> R3 ==> R4
 And aggregate Y (with five 80 kbps flows) traverses:
       R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
 Both aggregates are 400 kbps.  This totals 800 kbps at Int 7 in R10,
 which is the maximum bandwidth that RSVP has access to at this
 interface.  Signaling messages still traverse the interface without
 problem.  Aggregate X is at a higher relative priority than 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 80 kbps) 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 setup) 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, and 5) and the new flow (9), as
    stated in [2].
 o  As mentioned before, in this example, Int 8 in R10 can only
    accommodate 800 kbps, and aggregates X and Y have each already
    established 400 kbps flows comprised of five 80 kbps 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 Int 8.
 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 80 kbps.
 o  This document defines how aggregate Y is not completely preempted,
    but reduced in bandwidth by 80 kbps.  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.

Polk & Dhesikan Standards Track [Page 18] RFC 4495 RSVP Bandwidth Reduction May 2006

 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, i.e., towards R5).  The
    ResvTear message terminates an individual flow or aggregate flow.
    This document calls for that message not to 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 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 a decrease in bandwidth sufficient to
    accommodate the remaining 4 flows (A, B, C, and E), which is now
    320 kbps (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.

Polk & Dhesikan Standards Track [Page 19] RFC 4495 RSVP Bandwidth Reduction May 2006

Authors' Addresses

 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

Polk & Dhesikan Standards Track [Page 20] RFC 4495 RSVP Bandwidth Reduction May 2006

Full 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.
 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.

Intellectual Property

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

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Polk & Dhesikan Standards Track [Page 21]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4495.txt · Last modified: 2006/05/03 21:47 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki