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.
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.
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:
- If that router supports this extension:
#1 - it generates the ResvErr message with the error code
indicating the reduction in bandwidth.
#2 - it does not generate the ResvTear message.
- If that router does not support this extension, it generates both
ResvErr and ResvTear messages according to [1].
In the case of the router at the extreme downstream of a reservation
that receives the ResvErr message with the reduction indication:
- If that router does support this extension:
#1 - it processes this error message and applies whatever local
policy it is configured to do to determine how to reduce the
bandwidth of this designated flow.
- If the router does not support this extension:
#1 - it processes the ResvErr message according to [1] and all
extensions it is able to understand, but not this extension
from this document.
Thus, this extension does not cause ill effects within RSVP if one or
more routers support this extension, and one or more routers do not
support this extension.
7. Security Considerations
This document does not lessen the overall security of RSVP or of
reservation flows through an aggregate.
If this specification is implemented poorly - which is never
intended, but is a consideration - the following issues may arise:
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.
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.
[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.
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
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.
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.
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
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).