One document matched: draft-polk-tsvwg-rsvp-bw-reduction-00.txt
Internet Engineering Task Force James Polk
Internet Draft Subha Dhesikan
Expiration: April 18th, 2005 Cisco Systems
File: draft-polk-tsvwg-rsvp-bw-reduction-00.txt
A Resource Reservation Extension for the Reduction of
Bandwidth of a Reservation Flow
October 18th, 2004
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
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.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document proposes an extension to the Resource Reservation
Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to a
reservation. This mechanism can be used to affect individual
reservations, aggregate reservations or other forms of RSVP tunnels.
Polk & Dhesikan [Page 1]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Changes From Previous Version . . . . . . . . . . . . . 4
2. Individual Reservation Reduction Scenario . . . . . . . . . . 4
3. RSVP Aggregation Overview . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . 10
5.2 Error Flow Descriptor . . . . . . . . . . . . . . . . . 10
5.3 Individual Reservation Flow Reduction . . . . . . . . . . 10
5.4 Aggregation Reduction of Individual Flows . . . . . . . . 11
5.5 RSVP Flow Reduction involving IPsec Tunnels . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
Appendix. Walking Through the Solution . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1 Normative References . . . . . . . . . . . . . . . . . . 15
9.2 Informational References . . . . . . . . . . . . . . . . 16
10. Author Information . . . . . . . . . . . . . . . . . . . . . 16
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.
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 can allow endpoints to negotiate a new
(lower) bandwidth that falls at or below the specified bandwidth
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.
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 then
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
Polk & Dhesikan [Page 2]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
flows, this has greater consequences. While [2] clearly does not
terminate all the individual flows if an aggregate is denied, this
event will cause packets to be discarded. 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 requires an indication that
the reservation must be reduced to a certain amount (or less).
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 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
3181 [3] if published as an RFC.
The previous version of this document had a different filename, as
that effort only focused on solving reservation reduction of an
aggregate. That filename was:
draft-polk-tsvwg-rsvp-aggregate-reduction-00
This note will be removed in the next version of the effort.
Polk & Dhesikan [Page 3]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
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].
1.2 Changes from the previous version to this version
This is a listing of the changes that have taken place to this
Internet Draft since the previous version:
o Changed the filename to remove "aggregation" as the focus of the
draft to open up this solution to a wider applicability
o Reduced text in the introductory section to be more succinct
o Added the use-case for this mechanism with individual reservations
o Added the use-case for this mechanism with reservations of IPsec
data flows
o Opened up the text in the document body for this wider
applicability
o Mentioned why ECN is inappropriate for reducing bandwidth
allocations of RSVP reservations.
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===>
| Rtr1 |Int 2 |===========>|Int 8 | Rtr2 |
| | |:::::::::::>| | |
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
Polk & Dhesikan [Page 4]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
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, (Rtr1 and Rtr2) initially with only one
flow (Flow 1). The flows are forwarded from Rtr1 to Rtr2 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 Rtr1 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 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
Polk & Dhesikan [Page 5]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
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 (A & B); (1 through 5) in aggregate
A and (A through E) in aggregate B. 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 A Deaggregator of A
| |
V V
+------+ +------+ +------+ +------+
Flow 1-->| | | | | | | |--> Flow 1
Flow 2-->| | | | | | | |--> Flow 2
Flow 3-->| |==>| | | |==>| |--> Flow 3
Flow 4-->| | ^ | | | | ^ | |--> Flow 4
Flow 5-->| | | | | | | | | |--> Flow 5
Flow 9 | Rtr1 | | | Rtr2 | | Rtr3 | | | Rtr4 | Flow 9
+------+ | +------+ +------+ | +------+
| || || |
Aggregate A-->|| Aggregate A ||<--Aggregate A
|| | ||
+--------------+ | +--------------+
| |Int 7 | | |Int 1 | |
| +----- | V |------+ |
| Rtr10 |Int 8 |===========>|Int 2 | Rtr11 |
| | |:::::::::::>| | |
| +----- | ^ |------+ |
| |Int 9 | | |Int 3 | |
+--------------+ | +--------------+
.. | ..
Aggregate B--->.. Aggregate B ..<---Aggregate B
| .. .. |
+------+ | +------+ +------+ | +------+
Flow A-->| | | | | | | | | |--> Flow A
Flow B-->| | V | | | | V | |--> Flow B
Flow C-->| |::>| | | |::>| |--> Flow C
Flow D-->| | | | | | | |--> Flow D
Flow E-->| Rtr5 | | Rtr6 | | Rtr7 | | Rtr8 |--> Flow E
+------+ +------+ +------+ +------+
^ ^
| |
Aggregator of B Deaggregator of B
Polk & Dhesikan [Page 6]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
Figure 2. Generic RSVP Aggregate Topology
Figure 2 legend/rules:
- Aggregate A priority = 100
- Aggregate B 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 A is:
Rtr1 => Rtr2 => Rtr10 => Rtr11 => Rtr3 => Rtr4
where aggregate A starts in Rtr1, and deaggregates in Rtr4.
Flows 1, 2, 3, 4, 5 and 9 communicate through aggregate A
The path for aggregate B is:
Rtr5 ::> Rtr6 ::> Rtr10 ::> Rtr11 ::> Rtr7 ::> Rtr8
where aggregate B starts in Rtr5, and deaggregates in Rtr8.
Flows A, B, C, D and E communicate through aggregate B
Both aggregates share one leg or physical link: between Rtr10 and
Rtr11, thus they share one outbound interface: Int8 of Rtr10, 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 A)
between the routers rtr1 and rtr4. 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 A 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.
Polk & Dhesikan [Page 7]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
Aggregate B, in Figure 2, consists of flows A, B, C, D and E and
requires 400kbps (80kbps * 5 flows), and starts at rtr5 and ends
rtr8. This means there are two aggregates occupying all 800kbps of
the RSVP capacity.
When Flow 9 is added into aggregate A, this will occupy 80kbps more
than Int8 on rtr10 has available (880k offered vs. 800k capacity)
[1] and [2] create a behavior in RSVP to deny the entire aggregate B
and all its individual flows because aggregate A 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 B that only 80kbps 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 B
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), rtr8 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.
Polk & Dhesikan [Page 8]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
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
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.
Polk & Dhesikan [Page 9]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
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
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.
Polk & Dhesikan [Page 10]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
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
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.
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
Polk & Dhesikan [Page 11]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
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.
6. 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 issue 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.
7. IANA Considerations
IANA is to assign the following from RFC [XXXX] (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.
8. Acknowledgements
The authors would like to thank Fred Baker for contributing text and
guidance in this effort and to Roger Levesque for helpful comments.
Polk & Dhesikan [Page 12]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
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).
Aggregator of A Deaggregator of A
| |
V V
+------+ +------+ +------+ +------+
Flow 1-->| | | | | | | |--> Flow 1
Flow 2-->| | | | | | | |--> Flow 2
Flow 3-->| |==>| | | |==>| |--> Flow 3
Flow 4-->| | ^ | | | | ^ | |--> Flow 4
Flow 5-->| | | | | | | | | |--> Flow 5
Flow 9-->| Rtr1 | | | Rtr2 | | Rtr3 | | | Rtr4 |--> Flow 9
+------+ | +------+ +------+ | +------+
| || || |
Aggregate A--->|| Aggregate A ||<--Aggregate A
|| | ||
+--------------+ | +--------------+
| |Int 7 | | |Int 1 | |
| +----- | V |------+ |
| Rtr10 |Int 8 |===========>|Int 2 | Rtr11 |
| | |:::::::::::>| | |
| +----- | ^ |------+ |
| |Int 9 | | |Int 3 | |
+--------------+ | +--------------+
.. | ..
Aggregate B--->.. Aggregate B ..<---Aggregate B
| .. .. |
+------+ | +------+ +------+ | +------+
Flow A-->| | | | | | | | | |--> Flow A
Flow B-->| | V | | | | V | |--> Flow B
Flow C-->| |::>| | | |::>| |--> Flow C
Flow D-->| | | | | | | |--> Flow D
Flow E-->| Rtr5 | | Rtr6 | | Rtr7 | | Rtr8 |--> Flow E
+------+ +------+ +------+ +------+
^ ^
| |
Aggregator of B Deaggregator of B
Duplicate of Figure 2. Generic RSVP Aggregate Topology
Looking at Figure 2., aggregate A (with five 80kbps flows)
traverses:
Rtr1 ==> Rtr2 ==> Rtr10 ==> Rtr11 ==> Rtr3 ==> Rtr4
Polk & Dhesikan [Page 13]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
And aggregate B (with five 80kbps flows) traverses:
Rtr5 ::> Rtr6 ::> Rtr10 ::> Rtr11 ::> Rtr7 ::> Rtr8
Both aggregates are 400kbps. This totals 800kbps at Interface-7 in
Rtr10, which is the maximum bandwidth RSVP has access to at this
interface. Signaling messages still traverse the interface without
problem. Aggregate A is at a higher relative priority than
aggregate B. 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 A, Rtr1 will
initiate the PATH message towards the destination endpoint of
the flow. This hop-by-hop message will take it through Rtr2,
Rtr10, Rtr11, Rtr3 and Rtr4 which is the aggregate A path (that
was built per [2] from the aggregate's initial set up) to the
endpoint node.
o In response, Rtr4 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 RTR 10 can only
accommodate 800kbps, and aggregates A and B have each already
established 400kbps flows comprised of five 80kbps individual
flows. Therefore, Rtr10 (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 B to be preempted just to
accommodate aggregate A's request for an additional 80kbps.
o This document defines how aggregate B is not completely
preempted, but reduced in bandwidth by 80kbps. This is
contained in the ResvErr message that Rtr10 generates
(downstream) towards Rtr11, Rtr7 and Rtr8. 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 Rtr5). 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.
Polk & Dhesikan [Page 14]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
o Rtr8 is the deaggregator of aggregate B. 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 Rtr10) 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 Rtr8. 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 Rtr8 preempts whichever individual flow (or 'bandwidth' at
the aggregate ingress), it transmits a new RESV message for that
aggregate (B), 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 Rtr10 towards Rtr6 and Rtr5.
Rtr5 will not know through this RESV message which individual flow
was preempted. If in this example, Rtr8 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.
9. References
9.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
Polk & Dhesikan [Page 15]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
[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
[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
9.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
10. 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
documents can be found in BCP 78 and BCP 79.
Polk & Dhesikan [Page 16]
Internet Draft RSVP Bandwidth Reduction Oct 13th, 2004
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 (2004). 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:
April 13th, 2005
Polk & Dhesikan [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 01:10:52 |