One document matched: draft-polk-rsvp-aggregate-reduction-00.txt
Internet Engineering Task Force James Polk
Internet Draft Subha Dhesikan
Expiration: Jan 12th, 2005 Cisco Systems
File: draft-polk-rsvp-aggregate-reduction-00.txt
RSVP Extension for Bandwidth Reduction of an Aggregate
July 12th, 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 (RSVP) that allows an aggregated reservation to be
partially preempted. Currently, when a higher priority reservation
request arrives and sufficient bandwidth is unavailable to meet
that request, a lower priority aggregated reservation may be
preempted in whole, whether or not the entire bandwidth is
required. This document describes a method where the lower priority
aggregated reservation is preempted only to the extent to which its
bandwidth is required for the higher priority request. This allows
the aggregator to fail only a portion of the individual sessions
that is aggregated and allow the rest of the sessions to continue
unaffected.
Polk & Dhesikan [Page 1]
Internet Draft RSVP Aggregate Reduction July 12th, 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 3
2. RSVP Aggregation Overview . . . . . . . . . . . . . . . . . . 3
3. RSVP Aggregation Reduction Scenario . . . . . . . . . . . . . 5
4. Aggregate Reservation Reduction Requirements . . . . . . . . 6
5. Aggregate Bandwidth Reduction Solution . . . . . . . . . . . 7
5.1 Partial Preemption Error Code . . . . . . . . . . . . . 8
5.2 Error Flow Descriptor . . . . . . . . . . . . . . . . . 9
6. Currently Known Open Issues . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
Appendix. Walking Through the Solution . . . . . . . . . . . . . 11
10 References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1 Normative References . . . . . . . . . . . . . . . . . . 13
10.2 Informational References . . . . . . . . . . . . . . . . 14
11. Author Information . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
This document proposes an extension to the Resource Reservation
Protocol (RSVP) [1] that allows an aggregated reservation to be
partially preempted. RSVP aggregation [2] provides a mechanism to
combine many individual RSVP sessions into a single aggregated
session. The benefit of aggregation is that it greatly reduces the
number of messages that is exchanged between the routers and the
state that is maintained, leading to a savings in the CPU and memory
resources. Thus, RSVP aggregation greatly helps in the scaling of an
RSVP solution.
With RSVP aggregation, a situation can arise in which two aggregate
flows with differing priority levels will traverse the same router
interface. This should be a common occurrence in larger networks
even using RSVP aggregation because each flow (whether an aggregate
or not) follows IP routing paths determined by the routing protocol
(BGP, OSPF, etc). However, if that router interface reaches
bandwidth capacity and is then asked either through a new RESV
reservation set-up message, or the expansion of an existing
aggregate, to set-up a new or greater bandwidth reservation, the
router has to make a choice: deny the new request (because all
available resources are at full utilization) or preempt an existing
lower priority reservation to make room for the new or expanded
reservation.
When the flows are individual, this has little adverse affect other
than on the denied or preempted flows. 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 denied, this event will cause
Polk & Dhesikan [Page 2]
Internet Draft RSVP Aggregate Reduction July 12th, 2004
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 will usually be close to the amount that was just
increased in another flow at that interface. 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 re-attempt the reservation request
with a reduced bandwidth. Not knowing by how much bandwidth an
aggregate was preempted for compounds the problem as the
deaggregator does not know how much bandwidth to ask for to receive
the maximum available. In addition, there is a risk that some other
(new or expanding) reservation is granted the remaining bandwidth
during this reestablishment time period.
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 than 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 for elastic applications, and may
distinguish between voice, video, and other real time applications.
Section 2 will describe the extensions with the necessary diagrams.
Section 3 will address the protocol changes necessary to RSVP to
allow this to become possible.
This document is intended to be classified as an 'update' to RFC
3181 [3] if published as an RFC.
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. RSVP Aggregation Overview
The following network topology is to help visualize the concerns
this document addresses. Figure 1 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 is a reservation establishment protocol in one direction only.
It is up to the endsystems to 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. RSVP
Polk & Dhesikan [Page 3]
Internet Draft RSVP Aggregate Reduction July 12th, 2004
aggregation [per 2] is no different (operating in one direction).
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.
RSVP in [3] established a priority indication for each flow. In
fact, there are two priority indications: one to establish the
reservation, and one to defend the reservation in case preemption is
possible. Aggregate A will have a higher establishing priority
than aggregate B has for its defending priority. This means that if
aggregate A wants more bandwidth and none is available at an
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
Figure 1. Generic RSVP Aggregate Topology
Polk & Dhesikan [Page 4]
Internet Draft RSVP Aggregate Reduction July 12th, 2004
interface, aggregate B will have to relinquish bandwidth in favor of
this higher priority aggregate (A). The priorities assigned to a
reservation are always end-to-end, and not altered by any routers in
transit.
Figure 1 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. RSVP Aggregation Reduction Scenario
Figure 1 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
Polk & Dhesikan [Page 5]
Internet Draft RSVP Aggregate Reduction July 12th, 2004
hold and defending priority). The means of deriving the priority is
out of scope for this discussion.
Aggregate B, in Figure 1, 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 1. (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 Aggregate Reservation Reduction
The following are the requirements to reduce the bandwidth of an
aggregate reservation:
Req#1 - MUST have the ability to differentiate one aggregate from
other flows.
It might be the case that there is only one aggregate at an
interface that is now forced (by some means) to make the choice
to preemption the entire aggregate or reduce its bandwidth.
Polk & Dhesikan [Page 6]
Internet Draft RSVP Aggregate Reduction July 12th, 2004
Req#2 - MUST have the ability to indicate within an RSVP error
message (generated at the router with the congested
interface) that a specific aggregate is to be reduced in
bandwidth, which is less than it currently has reserved.
The indication should be to the maximum bandwidth still able to
be utilized instead of what has been reduced, because of the
unreliable nature of RSVP messaging. 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 call for. This is not
appropriate.
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.
A note to the reader (or WG): it is probable that whatever
indication of bandwidth reduction is chosen will apply for
individual reservation reduction as well as to aggregates. An
example of this would be an established reservation for a voice
call with a codec that uses (say) 80kbps, when a congested interface
indicates 80kbps is no longer available, but anything less than
40kbps is available. The endpoints could signal (using a protocol
such as SIP in [8] and [9]) to maintain the call, but at a lower
bandwidth codec (such as G.729). This could prevent a policy that
states something like:
"calls shall use RSVP, or no call occurs" (thus preventing
communication that could exist with a lower bandwidth codec)
or a more realistic policy in which a reservation is required for
establishment, but once the reservation is preempted, the call is
to relying on Differentiated Services or a scavenger class of
traffic (not knowing a codec requiring less bandwidth could be
used and the endpoints could adjust the reservation to the lower
available bandwidth).
Comments to this document could shift the authors' direction of this
document to include this larger scenario, if it isn't true by
default already.
5. RSVP Bandwidth Aggregation Reduction Solution
When an aggregated reservation is partially preempted, 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
Polk & Dhesikan [Page 7]
Internet Draft RSVP Aggregate Reduction July 12th, 2004
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 RFC 6.
There is an issue with the current operational behavior of RSVP
[per 1] to transmit an ResvTear message upstream when the ResvErr
message is transmitted downstream. This ResvTear message terminates
the reservation to all routers upstream of the router where the
preemption occurred. This document is written to prevent the
tearing down of a reservation, even part of a reservation. Thus,
the router that normally would generate a ResvTear message MUST NOT
do so.
An appendix has been written to walk through the overall solution to
the problems presented in section 3. There is a suggestion within
the appendix at addressing this ResvTear transmission issue. The
authors will look for comments on how best address this.
5.1 Partial Preemption Error Code
The ResvErr message that is caused 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.
Polk & Dhesikan [Page 8]
Internet Draft RSVP Aggregate Reduction July 12th, 2004
5.2 Error Flow Descriptor
The error flow descriptor is defined in [1] & [7]. In the case of
partial preemption, 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.
6. Currently Known Open Issue
This section lists the known open issues to date.
#1 - This general type of error to a preempted aggregate may be able
to be applied to a new aggregate request as well. Should this
document take on the task of addressing the case in which a new
aggregate asks for X amount of bandwidth, but X-n amount is all
that is available through the path?
This will require a new policy error code (TBD) but with the same
error flow descriptor with the currently available bandwidth.
Additional behaviors of RSVP will be necessary as well.
#2 - Whether individual reservation flows should be addressed in
this effort as well. The scenario is given below requirement
#3 in section 4 of this document. It has to do with a
preempted individual flow should have an error indicating to
the endpoint that if it would accept less bandwidth, a
reestablishment could probably occur between endsystems. This
could provide a preferential handling of resources to those
systems that are already engaged in reservations by informing
them of the available resources between two endsystems.
#3 - Have not addressed the ResvTear transmission specified in [1].
This is called out in section 5, and in the appendix. The
appendix offers a suggestion, but the authors are looking for
feedback before proceeding with this issue.
#4 - (perhaps related to issue #3) Admittedly have not addressed
what happens if this error message is generated (and sent) and
the flow doesn't reduce itself in a timely fashion (implying
the message was lost or it was received and not adhered to).
Comments and guidance on these open issues is requested, as each
would require extension of this document into a wider problem space.
7. Security Considerations
This document does not lessen the overall security of RSVP or of
reservation flows through an aggregate.
Polk & Dhesikan [Page 9]
Internet Draft RSVP Aggregate Reduction July 12th, 2004
8. 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 preemption 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 for helpful comments.
Polk & Dhesikan [Page 10]
Internet Draft RSVP Aggregate Reduction July 12th, 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 1 from section 2 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 1. Generic RSVP Aggregate Topology
Looking at Figure 1., aggregate A (with five 80kbps flows)
traverses:
Rtr1 ==> Rtr2 ==> Rtr10 ==> Rtr11 ==> Rtr3 ==> Rtr4
Polk & Dhesikan [Page 11]
Internet Draft RSVP Aggregate Reduction July 12th, 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 message reservation
[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
handle 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 Rtr8 is the deaggregator of aggregate B. The deaggregator
controls all the parameters of a reservation. This will be the
node that reduces the individual flows into it (perhaps picking
on Flow D for individual preemption by generating a ResvErr
towards that endpoint).
Polk & Dhesikan [Page 12]
Internet Draft RSVP Aggregate Reduction July 12th, 2004
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). The ResvTear message
terminates an individual flow or aggregate flow. This document
calls for that message to not be sent immediately.
The authors have not solved (yet) whether the ResvTear should be
sent out at all and if so, how much of a delay there needs to be
before this message is sent. Suggestions are asked for in this
regard, but it is possible the next bullets can solve this issue:
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 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. In this case, the voice signaling protocol (SIP)
will generate a termination of the flow at layer 7 to stop the flow
of packets into Rtr5.
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 [Page 13]
Internet Draft RSVP Aggregate Reduction July 12th, 2004
[7] J. Wroclawski, "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997
10.2 Informational References
[8] 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.
[9] G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", RFC
3312 Preconditions, October 2002
11. 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.
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
Polk & Dhesikan [Page 14]
Internet Draft RSVP Aggregate Reduction July 12th, 2004
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:
Jan 12th, 2005
Polk & Dhesikan [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-22 23:26:36 |