RFC 4495
A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow
RFC 4495: A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow 🎀
Okay bestie, this one dropped in May 2006 and it's written by J. Polk and S. Dhesikan, both from Cisco Systems 💅. It's a Standards Track document in the Network Working Group, so it's a real Internet standard, not just vibes. It updates RFC 2205 (the title block says Updates: 2205) and the header doesn't list anything it obsoletes 🫶.
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
So the big idea is an extension to the Resource Reservation Protocol (RSVPv1) that lets a reservation shrink its guaranteed bandwidth instead of getting fully wiped 🦋. This works for individual reservations, aggregate reservations, or other kinds of RSVP tunnels. It's an extension of RFC 2205, so it builds right on top of that one ✨.
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 ..........................171. Introduction ✨
Okay so this doc extends RSVP [1] so an existing reservation can get smaller in allocated bandwidth instead of being torn down 🙈. The reason is that some of that bandwidth is needed for other stuff. There are a few examples where this mechanism is useful.
The bandwidth for one reservation can get reduced for lots of reasons, like preemption, etc. 💅 If the reservation doesn't need all of its bandwidth anymore, then it doesn't need to be torn down. The solution here lets endpoints negotiate a new, lower bandwidth that's at or below the new maximum the network allocated. Think of a voice call: this signal in RSVP could tell the endpoints, which might be using another protocol like Session Initiation Protocol (SIP) [9], to switch to a lower-bandwidth codec and keep the reservation alive 🎧.
With RSVP aggregation [2], two aggregate flows with different priority levels can run through the same router interface 👑. If that interface hits capacity and gets asked to set up a new reservation or grow an existing one, the router has a choice to make. It can deny the new request because everything's already used up, or it can preempt an existing lower-priority reservation to make room 😭.
If the flow getting preempted is an aggregate of lots of individual flows, that's a bigger deal 💀. [2] clearly doesn't terminate all the individual flows when an aggregate gets torn down, but this event will still cause packets to be discarded while the aggregate reservation gets re-established. This document describes a method where only the minimum required bandwidth is taken away from the lower-priority aggregated reservation, and the whole reservation doesn't get preempted 🌈. The upside is that only some of the microflows in the aggregate are affected. Without this extension, all individual flows are affected, and the deaggregator will have to try the reservation request again with a reduced bandwidth.
RSVP tunnels that use IPsec [8] also need a way to indicate that the reservation has to be reduced to a certain amount, or less 🔐. RSVP aggregation with IPsec tunnels is being defined in [11], and it should be able to take advantage of the mechanism created in this specification 🧚.
Quick note: when this document says a router interface is "full" or "at capacity," that doesn't mean all of its bandwidth is used up. It means all of the bandwidth available for reservations via RSVP under the applicable policy is used up 🍓. Policies for real-time traffic routinely reserve capacity for routing and inelastic applications, and they may tell voice, video, and other real-time apps apart 💜.
Explicit Congestion Notification (ECN) [10] is an indication that the transmitting endpoint must reduce its transmission 🙅♀️. The thing is, it doesn't tell the endpoint how much to reduce by. So the application might have to try multiple times before its bandwidth usage drops below the available limit 😩. ECN is super useful for elastic applications, but it's not enough for inelastic applications, where knowing the bandwidth availability helps with codec selection 🎀.
Section 2 talks about the individual reservation flow problem, and Section 3 covers the aggregate reservation flow problem space ✨. Section 4 lists the requirements for this extension, and Section 5 details the protocol changes RSVP needs to create a reservation reduction indication 🔥. Last but not least, the appendix walks through how this extension changes RSVP behavior in an aggregate scenario 🦋.
This document updates RFC 2205 [1], since 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 shows 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 FlowsLegend and rules, bestie:
- 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.
Here's the tea ☕. RSVP only sets up reservations in one direction. This split-path thing is because the routed path from one device to another in one direction might not be the same path used for talking back the other way 🛣️. So end-systems have to request 2 one-way reservations if that's what a particular app needs, like voice calls 📞. Check out [1] for the full details on how this works. This example only covers the reservation in one direction, just to keep it simple 🌸.
Figure 1 starts with 2 routers (R1 and R2) and only one flow (Flow 1) 🧚. The flows go from R1 to R2 through Int 2. For this example, let's say Flow 1 and Flow 2 each need 80 units of bandwidth (like for the G.711 codec with no silence suppression) 🎶.
Also, let's say the RSVP bandwidth limit for Int 2 of R1 is 100 units 💅.
As [3] describes, each flow gets a priority indication. There are actually two priority indications 👀:
- one to establish the reservation, and
- 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. So Flow 2's establishing priority is higher than Flow 1's defending priority 👑. That means when Flow 2 gets signaled and there's no bandwidth left on the interface, Flow 1 has to give up bandwidth for Flow 2's higher-priority request 😤. Priorities on a reservation are always end-to-end, and no router in transit changes them 🔒.
Without this specification, Flow 1 gets preempted 💀. But with it, the ResvErr message can say that 20 units are still available for a reservation to stay up (the interface's 100-unit maximum minus Flow 2's 80 units) 🙌. The reservation-initiating node (router or end-system) for Flow 1 gets the chance to renegotiate, via call signaling, for acceptable parameters that fit within the existing, available bandwidth for the flow. For example, it could switch to a codec like G.729 🎧.
The problems that get avoided with the partial failure of the flow are:
- Reduced packet loss, which happens as Flow 1 tries to re-establish the reservation at a lower bandwidth 📉.
- Inefficiency caused by multiple attempts until Flow 1 can request bandwidth equal to or lower than what's available 🙃. If Flow 1 is established with much less than what's available, then it leads to inefficient use of the available bandwidth 🫠.
Part 1 is done, bestie, so more is coming 💜🌈✨
3. RSVP Aggregation Overview ✨
okay so this section is the big-picture moment 🦋 Figure 2 is basically the map of everything this spec is about. It has 10 routers (the boxes) and 11 flows (1, 2, 3, 4, 5, 9, A, B, C, D, and E). At the start there are 5 flows per aggregate. Flow 9 shows up later and causes the problem this document fixes. There are 2 aggregates, X and Y. Flows 1 through 5 are in aggregate X, and Flows A through E are in aggregate Y. Both aggregates cross one router interface and use up all the available capacity in this example 💅
RSVP aggregation (per [2]) is no different from an individual reservation when it comes to being unidirectional 🫶
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 YFigure 2. Generic RSVP Aggregate Topology
Legend/Rules:
- Aggregate X priority = 100
- Aggregate Y priority = 200
- All boxes are routers
- Both aggregates are shown in the same direction (left to right). Corresponding aggregates in the reverse direction are not shown for diagram simplicity.
The path for aggregate X is R1 => R2 => R10 => R11 => R3 => R4, where aggregate X starts in R1 and deaggregates in R4. 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, so they share one outbound interface: Int 8 of R10. That's where resource contention may exist 👀 That link has an RSVP capacity of 800 kbps. RSVP signaling (messages) is outside the 800 kbps in this example, and so 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 is made of 5 microflows (Flows 1, 2, 3, 4, and 5). For the sake of this discussion, let's say each flow is a voice call and needs 80 kb (for example, the codec G.711 with no silence suppression). The aggregate X request is for 400 kbps (80 kbps * 5 flows). The aggregate's priority comes from the individual microflows inside it. In the simple case, all flows of a single priority get bundled into one aggregate. Another priority level would be in another aggregate, even if it traverses the same path through the network. There may be other ways the priority of the aggregate is derived, but for this discussion it's enough to know that each aggregate has a priority (both hold and defending priority). How the priority gets derived is out of scope here 💖
Aggregate Y in Figure 2 is made of Flows A, B, C, D, and E. It needs 400 kbps (80 kbps * 5 flows), and it starts at R5 and ends at R8. That means two aggregates are occupying all 800 kbps of the RSVP capacity. Yikes, it's packed 😭
When Flow 9 is added into aggregate X, it occupies 80 kbps more than Int 8 on R10 has available (880k offered load vs. 800k capacity). [1] and [2] create a behavior in RSVP that denies the entire aggregate Y and all its individual flows, because aggregate X has a higher priority. This situation is what this document focuses its requirements on, and it 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:
- reduce significant packet loss of all flows within aggregate Y
During the re-reservation request period, no packets will traverse the aggregate until it is reestablished. Ugh, the silence is so rough 🥀
- 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 have to guess 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. Or it could request too little bandwidth and have that aggregation accepted, but then more individual flows would need to be preempted outside the aggregate than were necessary, which leads to inefficiencies in the opposite direction 🙈
4. Requirements for Reservation Reduction
The following are the requirements to reduce the bandwidth of a reservation. This applies to both individual and aggregate reservations 🎀
- Req#1 - MUST have the ability to differentiate one reservation from another. In the case of aggregates, it MUST distinguish one aggregate from other flows.
- Req#2 - MUST have the ability to indicate within an RSVP error message (generated at the router with the congested interface) that a specific reservation (individual or aggregate) is to be reduced in bandwidth.
- Req#3 - MUST have the ability to indicate within the same error message the new maximum amount of bandwidth that is available to be utilized within the existing reservation, but no more.
- Req#4 - MUST NOT produce a case in which retransmitted reduction indications further reduce the bandwidth of a reservation. Any additional reduction in bandwidth for a specified reservation MUST be signaled in a new message.
RSVP messages are unreliable and can get lost. This specification should not compound any error in the network. If a reduction message is 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, the router will likely reduce the bandwidth by twice the amount that was actually called for. That's an error 🚫
5. RSVP Bandwidth Reduction Solution
When a reservation is partially failed, a ResvErr (Reservation Error) message is generated, just like it is done currently with preemptions. The ERROR_SPEC object and the PREEMPTION_PRI object are included as well. Very few additions or 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 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 walks through the overall solution to the problems presented in Sections 2 and 3. It mentions this ResvTear transmission behavior too 📖
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:
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 ✨
okay so bestie, here's the vibe 💅 when a router needs some of the bandwidth that was given to a reservation so another flow can use it, it does a partial reduction 🦋 the way this document describes. it sends a ResvErr downstream to say "hey, partial error" 🚨 using the error code and subcode from section 5.1. and the flowspec sitting inside that ResvErr is what tells everyone how much bandwidth is currently allocated 🎀
then the requesting endpoint that gets the ResvErr can negotiate with the transmitting endpoint to lower the bandwidth requirement. like, switching to a lower bandwidth codec is a classic move 🎶 once they've talked it out, both endpoints issue the RSVP PATH and RESV messages with the new, lowered bandwidth 🌸 literally a glow-up for the reservation 💖
5.4. Aggregation Reduction of Individual Flows 🦋
okay this one is giving multi-layer drama 🎭 when a partial failure happens in an aggregation scenario, the deaggregator gets the ResvErr message with the reduction indication from a router somewhere on the aggregate's path. then it decides whether one or more individual flows from the aggregate are going to be affected by that ResvErr. these are the possible choices 👑
- ✨ If that (deaggregator) router decides one or more individual flow(s) are to partially fail, it sends a ResvErr message with a reduced bandwidth indication to those individual flow(s). it works the same way as the previous section (5.3) 💅
- 🌈 If that (deaggregator) router decides one individual flow is to be preempted to satisfy the aggregate ResvErr, it figures out which flow is affected. that router sends a new ResvErr message downstream per [3]. that same router also sends a ResvTear message upstream. this ResvTear for an individual flow does not tear down the aggregate. only that one individual flow is affected 🫶
- 💜 If that (deaggregator) router decides multiple individual flows are to be preempted to satisfy the aggregate ResvErr, it picks which flows are affected. that router sends a new ResvErr message downstream as per [3] to each individual flow. it also sends ResvTear messages upstream for those same individual flows. these ResvTears do not tear down the aggregate either. only the individual flows get affected 😭
in every single case, the deaggregator lowers the bandwidth requested in the Aggregate Resv message to reflect the change 📉
which particular flow or series of flows inside an aggregate gets picked for bandwidth reduction or preemption is outside the scope of this document 🙈 not our problem today, bestie 🧚
5.5. RSVP Flow Reduction Involving IPsec Tunnels 🔐
RFC 2207 (per [8]) is the one that spells out how RSVP reservations work in IPsec data flows 💜 the initiating node for an IPsec flow can be an end-system like a computer 💻, or a router sitting between two end-systems 🛜, or an in-line bulk encryption device sitting right next to a router interface. [11] covers that last scenario directly 🦋
the way you identify an IPsec flow with a reservation is different from non-encrypted flows, but how the reduction mechanism in this document works is exactly the same ✨
an IPsec flow with a reservation is, for all intents and purposes, treated as an individual flow when it comes to reducing its bandwidth 💅 obviously, it can be a bunch of individual flows or disjointed best-effort packets between two systems. but for this spec, the whole tunnel counts as one individual RSVP reservation 🎀
anywhere in this specification that mentions an individual reservation flow, the same bandwidth reduction and preemption rules MUST apply 🔥
5.6. Reduction of Multiple Flows at Once 🍓
quick cautionary note, bestie ⚠️ bandwidth SHOULD NOT be reduced across multiple reservations at the same time in reaction to the same reduction event. why? because a router that doesn't know how a reservation bandwidth reduction affects more than one flow might cause way more widespread ill effects than necessary 💀
this says nothing about a policy for whether preemption should or shouldn't happen across multiple flows 🌸
6. Backwards Compatibility 🫶
backwards compatibility with this extension means RSVP operates just like it does without the extension, and no worse 💖 the two routers involved are the router that had the congested interface and the furthest downstream router that decides what to do with the reduction indication 👑
for the router that's experiencing congestion or otherwise needs to reduce an existing reservation's bandwidth:
- 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]. 🦋
for the router at the extreme downstream end 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's configured with to decide 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. 🧚
so, thus, this extension doesn't cause ill effects within RSVP whether one or more routers support it and one or more routers don't 🌈 literally no drama 💅
7. Security Considerations 🔐
this document does not lessen the overall security of RSVP or of reservation flows through an aggregate 🫶
if this specification gets implemented poorly (which is never intended, but it's still something to think about 🥺), the following issues may pop up:
- if the ResvTear messages get sent right away (at the same time as the ResvErr messages saying a bandwidth reduction is needed), all upstream routers will tear down the entire reservation 😱 that accidentally frees up the total bandwidth of this reservation. this could make re-establishing an otherwise good reservation fail 💀 this hits hardest on an aggregate with lots of individual flows that would have stayed operational 😭
- just as RSVP is vulnerable to premature termination of valid reservations by rogue flows without authentication [12, 13], this mechanism has the same vulnerability 🚨 using 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 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 🧚
okay bestie, this appendix is a chill walkthrough of how RSVP behaves with the fix for the problems from Sections 2 and 3. there is no normative text in here, so it's just the story 💅
here's a copy of Figure 2 from Section 3 so you can see the picture while you read (it's giving clarity 🎀)
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 Topologylooking at Figure 2, aggregate X (with five 80 kbps flows) goes:
R1 ==> R2 ==> R10 ==> R11 ==> R3 ==> R4and aggregate Y (with five 80 kbps flows) goes:
R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8both aggregates are 400 kbps, so that's 800 kbps at Int 7 in R10 🔥 which is the most bandwidth RSVP can use on that interface. signaling messages still get through the interface just fine 🫶 aggregate X has higher relative priority than aggregate Y, and the local policy in this example says higher relative priority flows preempt lower-priority flows when things get congested. now let's see what happens when aggregate A gets Flow 9 added 👀
- when Flow 9 (at 80 kbps) joins aggregate X, R1 starts up the PATH message toward the destination endpoint of the flow. this hop-by-hop message goes through R2, R10, R11, R3, and R4, which is the aggregate X path (built per [2] from the aggregate's initial setup) to the endpoint node 🛤️
- R4 then makes the RESV (reservation) message in response (defined behavior per [1]). this RESV from the deaggregator asks for an increase in bandwidth enough to cover the 5 existing flows (1, 2, 3, 4, and 5) and the new flow (9), as stated in [2] 💖
- here's the drama: Int 8 in R10 can only handle 800 kbps, and aggregates X and Y have each already set up 400 kbps worth of flows (five 80 kbps individual flows each). so R10 (the interface that spots the congestion in this example) has to make a call about this new congestion situation regarding the RESV message it got at Int 8 😭
- the local policy here is to preempt lower-priority reservations so higher-priority ones can get in. normally that would mean all of aggregate Y gets preempted just so aggregate X can get its extra 80 kbps 💀
- this document defines how aggregate Y doesn't get completely preempted, and instead gets its bandwidth cut by 80 kbps 🦋 that's carried in the ResvErr message R10 sends downstream toward R11, R7, and R8. see Section 5 for the details of the error message
- normal RSVP behavior is that the router that sends a ResvErr downstream also sends a ResvTear message upstream (the opposite direction, i.e., toward R5). the ResvTear message terminates an individual flow or aggregate flow. this document says that message should NOT be sent on any partial failure of reservation 🙅♀️
the key thing: this document calls for the ResvTear NOT to be sent on a partial failure, so the aggregate doesn't get nuked just because it got trimmed. that's the whole point 💜
- R8 is the deaggregator of aggregate Y, and the deaggregator controls all the parameters of an aggregate reservation 👑 so R8 is the node that cuts the aggregate's bandwidth when it gets a ResvErr from R10 saying that's needed. in this example, the bandwidth reduction happens by preempting one individual flow inside the aggregate (maybe picking on Flow D for individual preemption, by sending a ResvErr downstream on that individual flow) 🥺
- at the same time, R8 sends a ResvTear upstream on that individual flow (Flow D). this doesn't touch the aggregate directly, but it's a heads-up to the routers (and the source end-system) about which individual flow is getting preempted 📣
- once R8 preempts that individual flow (or the 'bandwidth' at the aggregate ingress), it sends a new RESV message for that aggregate (Y), not for a brand new aggregate. this RESV from the deaggregator asks for a bandwidth decrease enough to cover the 4 remaining flows (A, B, C, and E), which is now 320 kbps (in this example) ✨
- this RESV message goes the whole reservation path and resets all the routers to this new aggregate bandwidth value 🧹 it should be exactly what's needed to keep R10 from sending a ResvTear toward R6 and R5. that's the goal, bestie 🎀
R5 won't find out from this RESV message which individual flow got preempted 🙈 but if R8 had been given more bandwidth to keep in this example, it might have sent a bandwidth reduction ResvErr toward the end-system of Flow D. then a voice signaling protocol (like SIP) could try to renegotiate that individual flow down to less bandwidth (say, by switching the voice codec from G.711 to G. 729). that could have saved Flow D from getting preempted 🥹🫶
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.comFull 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). 🌈
📦 where this page comes from
- ietf: rfc4495 2006-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms