RFC 5945
Resource Reservation Protocol (RSVP) Proxy Approaches
RFC 5945: Resource Reservation Protocol (RSVP) Proxy Approaches 🎀
- Number: RFC 5945 ✨
- Authors: F. Le Faucheur (Cisco), J. Manner (Aalto University), D. Wing (Cisco), A. Guillou (SFR) 👑
- Category: Informational, so it's published for info and isn't a Standards Track spec 🧚
- ISSN: 2070-1721
- Date: October 2010 🌸
- Obsoletes / Updates: nothing listed in the title block, so it doesn't replace or update any other RFCs 🫶
Abstract ✨
okay so RSVP (the Resource Reservation Protocol) lets you make end-to-end reservations across an IP network so certain flows get the quality of service they need 💖 The thing is, RSVP assumes that both the data sender and the receiver are taking part in RSVP signaling. But there are situations where you still need a reservation and the receiver, the sender, or both are not RSVP-capable 😭
This document presents RSVP proxy behaviors. These let RSVP routers start or stop RSVP signaling on behalf of a receiver or sender that can't do RSVP itself. The result is that reservations can be set up on a critical subset of the end-to-end path 🦋 It also walks through conceptual approaches for deploying RSVP proxies, and talks about how reservations can be synced with application requirements even when the sender, the receiver, or both aren't in RSVP 💅
It also points out where extensions to RSVP (or to other protocols) might be needed to deploy a given RSVP proxy approach. Those extensions are outside the scope of this document though, so they aren't covered here 🙈 Last but not least, it describes practical use cases for RSVP proxies 🌈
Status of This Memo ✨
ngl this part is the paperwork, but it matters 💅 This document is not an Internet Standards Track specification. It's published for informational purposes 🎀
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 🧚
For info about the current status of this document, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc5945 🔥
Copyright Notice 🌈
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. ⭐
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 💜 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🍓
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😬 Without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🦋
Table of Contents 💖
1. Introduction ....................................................3
2. RSVP Proxy Behaviors ............................................6
2.1. RSVP Receiver Proxy ........................................6
2.2. RSVP Sender Proxy ..........................................7
3. Terminology .....................................................7
4. RSVP Proxy Approaches ...........................................9
4.1. Path-Triggered Receiver Proxy ..............................9
4.1.1. Mechanisms for Maximizing the Reservation Span .....11
4.2. Path-Triggered Sender Proxy for Reverse Direction .........15
4.3. Inspection-Triggered Proxy ................................18
4.4. STUN-Triggered Proxy ......................................21
4.5. Application_Entity-Controlled Proxy .......................23
4.5.1. Application_Entity-Controlled Sender Proxy
Using "RSVP over GRE" ..............................26
4.5.2. Application_Entity-Controlled Proxy via Co-Location 28
4.6. Policy_Server-Controlled Proxy ............................29
4.7. RSVP-Signaling-Triggered Proxy ............................32
4.8. Reachability Considerations ...............................33
5. Security Considerations ........................................34
6. Acknowledgments ................................................36
7. References .....................................................36
7.1. Normative References ......................................36
7.2. Informative References ....................................37
Appendix A. Use Cases for RSVP Proxies ...........................40
A.1. RSVP-Based VoD Admission Control in Broadband
Aggregation Networks ......................................40
A.2. RSVP-Based Voice/Video Connection Admission Control
(CAC) in Enterprise WAN ...................................43
A.3. RSVP Proxies for Mobile Access Networks ...................44
A.4. RSVP Proxies for Reservations in the Presence of IPsec
Gateways ..................................................461. Introduction ✨
okay so bestie, picture this 🎀 guaranteed Quality of Service (QoS) for apps with super tight needs, like voice calls or video, can be achieved by reserving resources at every single node on the end-to-end path 💅. The main IETF protocol for this is the Resource Reservation Protocol (RSVP), as specified in [RFC2205]. RSVP doesn't require every intermediate node to support it, BUT it does assume that both the sender and the receiver are RSVP-capable 🦋. There are environments where it would be useful to reserve resources for a flow on at least a subset of the flow path, even when the sender or the receiver (or both!) isn't RSVP-capable. For example, from the sender to the network edge, or from edge to edge, or from the network edge to the receiver 🌸.
Since the data sender or receiver might be totally unaware of RSVP, there are two types of RSVP proxies 🧚. When the sender isn't using RSVP, an entity in the network has to operate on its behalf. It generates RSVP Path messages and eventually receives, processes, and sinks Resv messages. We call this entity the RSVP Sender Proxy 💜. When the receiver isn't using RSVP, an entity in the network has to receive Path messages sent by a data sender (or by an RSVP Sender Proxy), sink those, and return Resv messages on behalf of the data receiver(s). We call this one the RSVP Receiver Proxy 🫶. The RSVP proxies need to be on the data path in order to establish the RSVP reservation. Note, though, that some of the approaches in this document let the RSVP proxies be controlled or triggered by an off-path entity 👑.
The flow sender and receiver generally have at least some (if not full) awareness of the application producing or consuming that flow. So they're in a natural position to synchronize the establishment, maintenance, and teardown of the RSVP reservation with the application requirements ✨. They're also in a natural position to figure out the characteristics of the reservation (bandwidth, QoS service, etc.) that best match what the app needs 🍓. For example, before finishing the setup of a multimedia session, the endpoints may decide to establish RSVP reservations for the corresponding flows. And when that multimedia session gets torn down, the endpoints may decide to tear down the matching RSVP reservations too 💖. For instance, [RFC3312] talks about how RSVP reservations can be very tightly synchronized by endpoints that use the Session Initiation Protocol (SIP) ([RFC3261]) for session control. Main character sync energy 😭.
When RSVP reservation establishment, maintenance, and teardown are handled by RSVP proxies on behalf of an RSVP sender or receiver, the big challenge for the RSVP proxy is figuring out when the RSVP reservations need to be established, maintained, and torn down. It also has to figure out the characteristics (bandwidth, QoS, etc.) of the required reservations that match the application requirements 🙈. We call this problem the synchronization of RSVP reservations with application-level requirements. It's a whole thing, bestie.
The IETF Next Steps in Signaling (NSIS) working group has specified a new QoS signaling protocol: the QoS NSIS Signaling Layer Protocol (NSLP) ([RFC5974]). This protocol also has the notion of proxy operation, and it terminates QoS signaling on nodes that aren't the actual data senders or receivers (see Section 4.8, "Proxy Mode", of [RFC5974]. This is the same concept as the proxy operation for RSVP discussed in this document. One difference, though, is that the NSIS framework doesn't consider multicast resource reservations, which RSVP does provide today 🌈.
Section 2 introduces the notion of RSVP Sender Proxy and RSVP Receiver Proxy. Section 3 defines useful terminology. Section 4 then presents several fundamental RSVP proxy approaches, and talks about how they achieve the necessary synchronization of RSVP reservations with application-level requirements 🎀. Appendix A includes more detailed use cases for the proxies in various real-life deployment environments 🦋.
It's really important to keep in mind that the strongly recommended RSVP deployment model is still end-to-end, as assumed in [RFC2205], with RSVP support on the sender and the receiver 🔥. The end-to-end model allows the most effective synchronization between the reservation and application requirements. Also, compared to the end-to-end RSVP model, using RSVP proxies adds extra operational burden and/or imposes some topological constraints 💀. The extra operational burden comes in particular from the additional configuration needed to activate the RSVP proxies and to help them identify which senders/receivers need proxy behavior and which don't. That way an RSVP proxy doesn't set up reservations on behalf of devices that can do it themselves, which would then be blocked (without any notification!) by the RSVP proxy 🙅♀️. The extra topological constraints come in particular from two things. First, you need one RSVP Receiver Proxy on the path from any sender to every non-RSVP-capable device, so a non-RSVP-capable device is always taken care of by an RSVP proxy. Second, you want only one such Receiver Proxy on the path from any sender to every non-RSVP-capable device. That way an RSVP Receiver Proxy doesn't short-circuit another RSVP Receiver Proxy that's closer to the non-RSVP-capable device, which would shrink the span of the RSVP reservation and the benefits that come with it 😩. In the case of the Path-Triggered Receiver Proxy approach, the operational burden and topological constraints can be significantly eased using the mechanisms discussed in Section 4.1.1 🧠.
It's also worth noting that RSVP operations on end-systems are way simpler than on a router, so RSVP implementations on end-systems are super lightweight (especially considering modern end-systems' capabilities, including mobile and portable devices) 📱. For example, end-system RSVP implementations are reported to only consume low tens of kilobytes of code space 🍓. So this document should not be seen as an encouragement to ditch the end-to-end RSVP model. Its only purpose is to allow RSVP deployment in special environments where RSVP just can't be used on some senders and/or some receivers, for reasons specific to that environment 🫶.
2. RSVP Proxy Behaviors 💅
This section talks about the two types of proxies: the RSVP Sender Proxy, operating on behalf of data senders, and the RSVP Receiver Proxy, operating for data receivers 🌸. The concepts in this document aren't meant to deprecate the traditional [RFC2205] RSVP end-to-end model. End-to-end RSVP reservations are still expected to be used whenever possible 💖. However, RSVP proxies are intended to facilitate RSVP deployment where end-to-end RSVP signaling isn't possible 🦋.
2.1. RSVP Receiver Proxy
With conventional end-to-end RSVP operations, RSVP reservations are controlled by the receivers of data 👑. After a data sender has sent an RSVP Path message towards the intended recipient(s), each recipient that needs a reservation generates a Resv message. But if a data receiver isn't running the RSVP protocol, the last-hop RSVP router will still send the Path message to the data receiver. The data receiver will then silently drop this message as an IP packet with an unknown protocol number 💀.
So in order for reservations to be made in this kind of scenario, one of the RSVP routers on the data path determines that the data receiver won't be participating in the resource reservation signaling. That router then performs RSVP Receiver Proxy functionality on behalf of the data receiver 🧚. This is illustrated in Figure 1. Various mechanisms by which the RSVP proxy router can gain the required information are discussed later in the document ✨.
|****| *** *** |**********| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R |
|****| *** *** | Receiver | |----|
| Proxy |
|**********|
===================RSVP==============>
***********************************************************>
|****| RSVP-capable |----| non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
***> unidirectional media flow
==> segment of flow path protected by RSVP reservation
Figure 1: RSVP Receiver Proxy2.2. RSVP Sender Proxy
With conventional end-to-end RSVP operations, if a data sender isn't running the RSVP protocol, a resource reservation can't be set up. A data receiver alone can't reserve resources without Path messages being received first 😭. So even if the data receiver is running RSVP, it still needs some node on the data path to send a Path message towards the data receiver 🙈.
In that case, an RSVP node on the data path determines that it should generate Path messages so the receiver can set up the resource reservation 💖. This node is referred to as the RSVP Sender Proxy and is illustrated in Figure 2. This case has extra challenges compared to the Receiver Proxy case, since the RSVP Sender Proxy has to be able to generate all the information in the Path message (such as the SENDER_TSPEC object) without the benefit of having previously received any RSVP message 😩. An RSVP Receiver Proxy, by contrast, only needs to formulate an appropriate Resv message in response to an incoming Path message 🫶. Mechanisms to operate an RSVP Sender Proxy are discussed later in this document 🎀.
|----| |**********| *** *** |****|
| S |---------| RSVP |---------*r*----------*r*----------| R |
|----| | Sender | *** *** |****|
| Proxy |
|**********|
================RSVP==================>
***********************************************************>
|----| non-RSVP-capable |****| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |****| *** router
***> unidirectional media flow
==> segment of flow path protected by RSVP reservation
Figure 2: RSVP Sender Proxy3. Terminology ✨
okay so bestie, this section is basically the glossary for the whole doc 🎀 we're gonna define the key words first so everything after makes sense 💅
- On-Path 🛣️: a router that sits on the data path of the actual flow of application data. It doesn't matter where it sits relative to the application-level signaling path, just whether the media actually goes through it 🦋
- Off-Path 🙈: not On-Path. Literally the opposite, no cap 💀
- RSVP-capable (or RSVP-aware) 💖: supporting the RSVP protocol as per [RFC2205] 👑
- RSVP Receiver Proxy 🧚: an RSVP-capable router that does the RSVP operations on behalf of a receiver. Those are the ones a receiver would normally do itself if end-to-end RSVP signaling were in play. Lowkey the important bit: RSVP is used upstream of the RSVP Receiver Proxy, but it is not used downstream of it 😭
- RSVP Sender Proxy 🌸: an RSVP-capable router that does the RSVP operations on behalf of a sender, the ones a sender would normally do with end-to-end RSVP. Same deal in reverse: RSVP is used downstream of the RSVP Sender Proxy, but it is not used upstream of it ✨
- Regular RSVP Router 🍓: an RSVP-capable router that is not acting as an RSVP Receiver Proxy or an RSVP Sender Proxy. Just a normal, hardworking router 🌈
- Application-level signaling 💜: signaling between entities running above the IP layer that know about the QoS requirements for the actual media flows. SIP ([RFC3261]) and the Real Time Streaming Protocol (RTSP) ([RFC2326]) are examples. The Session Description Protocol (SDP) ([RFC4566]) is an example of a protocol the application-level signaling protocol can use, and some of the RSVP reservation parameters (addresses, ports, and bandwidth) might be derived from it 🎀 RSVP is clearly not an application-level signaling protocol, so don't mix those up 🙅♀️
The roles of the RSVP Receiver Proxy, RSVP Sender Proxy, and regular RSVP router are all relative to a given unidirectional flow 🦋 So one router can be the RSVP Receiver Proxy for one flow, the RSVP Sender Proxy for another, and a regular RSVP router for yet another. Multitasking queen 👑
Some application-level signaling protocols can negotiate QoS reservations for a media stream. For example, with [RFC3312], resource reservation requirements get signaled explicitly during session setup using SIP and SDP 💅 And [RFC5432] defines a way to negotiate which resource reservation mechanism gets used for a particular media stream 🫶
Here's the tea: these negotiation mechanisms work great when both ends support RSVP (and then RSVP proxies aren't used at all). When neither end supports RSVP (and RSVP proxies are used at both ends), these mechanisms just won't get invoked 💀 The tricky case is when one end supports RSVP and the other doesn't, but is helped by an RSVP proxy. In that case, the application-level signaling entity handling the non-RSVP-capable end might use the negotiation mechanisms so that the non-RSVP-capable end (helped by an RSVP proxy) looks like an RSVP-capable device to the remote end 🧚 This makes sure the RSVP-capable end doesn't get discouraged from using RSVP just because the other end isn't RSVP-capable 🥹 With SIP, the application-level entity can do this by using the "segmented" status type of [RFC3312] and/or by using a SIP [RFC3261] Back-to-Back User Agent (B2BUA) 🔥
4. RSVP Proxy Approaches ✨
okay so this section is all about the main RSVP proxy approaches 🎀 let's get into it 💅
4.1. Path-Triggered Receiver Proxy 🦋
In this approach, the sender is assumed to be RSVP-capable and to fully handle the synchronization between application requirements and RSVP reservations 👑 The RSVP Receiver Proxy uses the RSVP Path messages the sender generates as the cue to set up the RSVP reservation on behalf of the receiver 🧚 So the proxy is basically a little helper making reservations for the receiver, but under the sender's control. Honestly iconic 😭 This flips the usual RSVP model, where receivers are the ones in charge of reservations. The flip is super helpful in the scenario we care about here, where the receiver isn't RSVP-capable 💖 It even lets the RSVP Receiver Proxy stay application-unaware, because it borrows the application and RSVP awareness of the sender 🫶
With the Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be configured to treat receipt of a regular RSVP Path message as the trigger for RSVP Receiver Proxy behavior 🌸
When it gets an RSVP Path message, the RSVP Receiver Proxy:
- sets up the RSVP Path state the normal RSVP way 🎀
- figures out the downstream interface facing the receiver 🛣️
- sinks the Path message 🙈
- acts as if a Resv message (more on its details below) came in on the downstream interface 🦋 That includes doing admission control on the downstream interface, setting up a Resv state (if admission control succeeds), forwarding the Resv message upstream, sending periodic refreshes of the Resv message, and tearing the reservation down if the Path state gets torn down 💅
To build the Resv message, the RSVP Receiver Proxy can use info from the Path message 🧠 For example, it may compose a FLOWSPEC object for the Resv message that mirrors the SENDER_TSPEC object in the received Path message. That's what an RSVP-capable receiver would typically do too 👑
Here's how the Path-Triggered Receiver Proxy works when the reservation succeeds, shown in Figure 3 🦋
|****| *** *** |**********| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R |
|****| *** *** | Receiver | |----|
| Proxy |
|**********|
---Path---> ----Path----> ---Path---->
<--Resv---> <---Resv----- <--Resv----
==================RSVP===============>
**********************************************************>
|****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
***> media flow
==> segment of flow path protected by RSVP reservation
Figure 3: Path-Triggered RSVP Receiver ProxyIf the reservation setup gets rejected (say, an admission control failure on a regular RSVP router between the RSVP-capable sender and the RSVP Receiver Proxy), a ResvErr message is generated the usual RSVP way and travels downstream toward the RSVP Receiver Proxy 🥺 That makes sure the proxy knows about the failure, but conventional RSVP procedures don't cover telling the sender about it 😬 Here's the admission control failure version, shown in Figure 4 🫣
|****| *** *** |**********| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R |
|****| *** *** | Receiver | |----|
| Proxy |
|**********|
---Path---> ----Path----> ---Path---->
<---Resv----- <--Resv------
---ResvErr---> --ResvErr--->
===================RSVP===============>
**********************************************************>
|****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
***> media flow
==> segment of flow path protected by RSVP reservation
Figure 4: Path-Triggered RSVP Receiver Proxy with FailureSince, as we just covered, the sender is the one handling synchronization between the application and the RSVP reservation in this setup, the sender does need to be told about reservation failures 🚨 [RFC5946] specifies RSVP extensions that allow that sender notification when a reservation fails with a Path-Triggered RSVP Receiver Proxy 🫶
4.1.1. Mechanisms for Maximizing the Reservation Span 🌈
If a Path-Triggered RSVP Receiver Proxy (for a given flow) behaves strictly as described above, it terminates the Path message and generates a Resv message toward the sender 🛑 If the receiver really isn't RSVP-capable and there's no other RSVP Receiver Proxy downstream on the flow path, this gets the best achievable result: an RSVP reservation as far downstream as the RSVP Receiver Proxy 💖
But if the eventual receiver was actually RSVP-capable, it would be locked out of RSVP signaling, since it never gets a Path message 😭 So the RSVP reservation would only span part of the path it could have spanned. Multiple Receiver Proxies on the path have a similar problem: the first one can block the Path message from reaching the second one, which stops the reservation from reaching down to the second proxy 🙈
It's really desirable that, when there are Path-Triggered RSVP Receiver Proxies and a mix of RSVP-capable and non-RSVP-capable receivers, the RSVP reservation spans as much of the flow path as it can 🦋 This can be done dynamically (no tedious manual config needed 🙌) using the mechanisms described in Sections 4.1.1.1 and 4.1.1.2 ✨
4.1.1.1. Dynamic Discovery of Downstream RSVP Functionality 🔍✨
okay so when a Receiver Proxy sends a proxy Resv upstream, it may be set up to do dynamic discovery of downstream RSVP stuff 🦋 bestie, here's the trick: it forwards the Path message downstream instead of ending it. That way an RSVP-capable receiver (or a downstream Receiver Proxy) can answer with an upstream Resv. The second that Resv shows up, the Receiver Proxy switches its state from a proxied reservation to a regular midpoint RSVP behavior 💅. From that point on, everything goes exactly like the router had been a regular RSVP router from the start of reservation setup (instead of a Receiver Proxy for that flow). Iconic transformation 👑
The Receiver Proxy behavior for dynamic discovery of downstream RSVP functionality is shown in Figure 5 and also discussed in Section 4.1 of [RFC5946]. 🧚
|****| *** |**********| |----|
| S |---------*r*---------| RSVP |---| R1 |
|****| *** | Receiver | |----|
| Proxy |
| |
| | |****|
| |------------| R2 |
|**********| |****|
---Path---> --Path--->
(R1) (R1) \-------Path-->
/ (R1)
<--Resv--- <---Resv---
================RSVP===>
**************************************>
---Path---> --Path--->
(R2) (R2) \-------------Path---->
/ (R2)
<--Resv--- <---Resv---
<----Resv---
================RSVP===========================>
***********************************************>
|****| RSVP-capable |----| non-RSVP-capable |****| RSVP-capable
| S | Sender | R | Receiver | R | Receiver
|****| |----| |****|
***
*r* regular RSVP
*** router
(R1) = Path message contains a Session object whose destination is R1
***> media flow
==> segment of flow path protected by RSVP reservation
Figure 5: Dynamic Discovery of Downstream RSVP FunctionalityThis dynamic discovery vibe is seriously helpful 🌈 New (or upgraded) RSVP endpoints automatically and seamlessly get to use end-to-end reservations, and the Receiver Proxy can still proxy RSVP for the non-RSVP-capable endpoints too. Not a single conflict 🙈 It also finds the longest possible RSVP-supporting segment when there are multiple Receiver Proxies along the path. Bonus: it adjusts to any topology or routing change, and it handles the case where a receiver was RSVP-capable and then stopped being one for some reason (like a software downgrade) 💖 And the best part? No new RSVP protocol extensions are needed, and the Receiver Proxy doesn't need config changes as RSVP-capable endpoints come and go ✨
ngl, there are a couple of drawbacks though, so let's be real about them 😭
- If admission control fails on the segment between the Receiver Proxy and the RSVP-capable receiver, the receiver gets a
ResvErrand can take application-level signaling steps to end the call. BUT the Receiver Proxy has already sent aResvupstream for this flow, so the sender sees a "false" reservation that isn't truly end-to-end 💀 The real admission control status sorts itself out in a short while, but the sender has to roll back any permanent action (like billing) that might have happened after getting that phantomResv. Also, if the second receiver is a Receiver Proxy that isn't taking part in application signaling, it turns the receivedResvErrinto aPathErrthat the sender gets instead 🫶 - If there's no RSVP-capable receiver (or other Receiver Proxy) downstream of the Receiver Proxy, the
Pathmessages the Receiver Proxy sends every RSVP refresh interval (e.g., 30 seconds by default) never get a response. These messages use a small amount of bandwidth, and they'd also install some RSVP state on RSVP-capable midpoint nodes downstream of the first Receiver Proxy. This is seen as a very minor sub-optimality 🌸 We also note that those resources would get used anyway if the receiver were RSVP-capable. Still, if it's deemed necessary, the Receiver Proxy can tear down any unanswered downstream Path state and stop sendingPathmessages for the flow (or only send them at a much lower frequency), as further discussed in [RFC5946] 🍓
4.1.1.2. Selective Receiver Proxy and Sender Control of Receiver Proxy 🎀
A Receiver Proxy can be super selective about which sessions it terminates, based on local policy decisions 👑 For example, an edge router acting as a Receiver Proxy might only proxy for Path messages that are actually going to leave the domain, and not for ones that just transit through and stay inside it. Another example: the Receiver Proxy can be configured to only proxy for flows addressed to a given destination address or destination address ranges (where the end devices are known to not be RSVP-capable) 🧚
The decision to proxy a Resv for a Path can also be based on info the sender signals in the Path message 🦋 For example, the sender can identify the type of application or flow in the Application Identity policy element ([RFC2872]) in the Path, and the Receiver Proxy can be set up to proxy for only certain types of flows. Or, if the sender knows (for example, through application signaling) that the receiver is RSVP-capable, the sender can put an indication in a policy element telling any Receiver Proxy that it ought not to terminate the Path. And the reverse works too: if the receiver is known not to support RSVP, the sender could include an indication telling Receiver Proxies that they ought to generate a proxy Resv message 💅 The Receiver Proxy Control policy element specified in Section 4.2 of [RFC5946] can be used for that purpose 🌈
4.2. Path-Triggered Sender Proxy for Reverse Direction ✨
okay so in this approach, one endpoint is RSVP-capable and handles all the syncing between what the app needs and the RSVP reservations 💅. That endpoint is the sender for one flow direction (we call it the "forward" direction) and the receiver for the flow in the other direction (the "reverse" direction) 🦋.
With the Path-Triggered Sender Proxy for Reverse Direction approach, the RSVP proxy uses the RSVP signaling the receiver generates for the reverse direction as its cue to start RSVP signaling for the reverse-direction reservation 🎀. To be more precise, the RSVP proxy can treat the creation of a Path state by the receiver as the cue to create a Path state toward the receiver. It can do the same for maintenance and teardown: when the receiver maintains or tears down its Path state, the proxy maintains or tears down its own Path state toward the receiver. So the RSVP proxy is basically acting as a Sender Proxy for the reverse direction, and the receiver is the one in charge of it 👑. Note that this assumes a degree of symmetry between the two directions of the flow, for example in terms of bandwidth. That's totally the norm for IP telephony right now, so it's giving realistic 📞.
The signaling flow for the Path-Triggered Sender Proxy for Reverse Direction is shown in Figure 6 🧚.
Path messages generated by the receiver need to transit the RSVP Sender Proxy that sits on the path from the sender to the receiver 🛣️. In some topologies this always happens naturally, for example when the sender lives on a stub network hanging off the RSVP Sender Proxy, or when there's no asymmetric routing. In that case, if an RSVP Sender Proxy is on the path from receiver to sender, it's also on the path from sender to receiver 🙌. In some topologies, especially ones with asymmetric routing, this might not happen on its own. Making sure it does happen in those topologies is outside the scope of this document 🙈.
|****| *** *** |**********| |----|
| R |---------*r*----------*r*---------| RSVP |----------| S |
|****| *** *** | Sender | |----|
| Proxy |
|**********|
---Path---> ----Path----> ---Path---->
<--Path---> <---Path----- <--Path----
---Resv---> ----Resv----> ---Resv---->
<================RSVP==================
<**********************************************************
|****| RSVP-capable |----| Non-RSVP-capable ***
| R | Receiver for | S | Sender for *r* regular RSVP
|****| reverse direction |----| reverse direction *** router
***> media flow
==> segment of flow path protected by RSVP reservation
in reverse direction
Figure 6: Path-Triggered Sender Proxy for Reverse DirectionOf course, the RSVP proxy can also (and typically will) act as the Path-Triggered Receiver Proxy for the forward direction, as defined in Section 4.1 🌈. This setup is most useful when both directions need RSVP reservations for a symmetric flow 💜. That's shown in Figure 7 ⭐.
|****| *** *** |----------| |----|
|S/R |---------*r*----------*r*---------| RSVP |----------|S/R |
|****| *** *** | Receiver | |----|
| & Sender |
| Proxy |
|----------|
---Path---> ----Path----> ---Path---->
<--Resv---> <---Resv----- <--Resv----
<--Path---> <---Path----- <--Path----
---Resv---> ----Resv----> ---Resv---->
================RSVP==================>
<================RSVP==================
**********************************************************>
<**********************************************************
|****| RSVP-capable |----| Non-RSVP-capable ***
|S/R | Sender and |S/R | Sender and *r* regular RSVP
|****| Receiver |----| Receiver *** router
***> media flow
==> segment of flow path protected by RSVP reservation
in forward and in reverse direction
Figure 7: Path Triggered Receiver and Sender ProxyWith the Path-Triggered Sender Proxy for Reverse Direction approach, the RSVP router can be configured to treat receipt of a regular RSVP Path message as the trigger for Sender Proxy for Reverse Direction behavior 🔥.
When the RSVP Sender Receiver Proxy gets the RSVP Path message for the forward direction, it does two things:
- It sinks the Path message 🫶.
- It behaves as if a Path message for the reverse direction (more on the details below) had arrived at the Sender Proxy. That includes setting up the matching Path state, forwarding the Path message downstream, sending periodic refreshes of that Path message, and tearing down the reverse-direction Path when the forward-direction Path state gets torn down 🔁.
To build the Path message for the reverse direction, the RSVP Sender Proxy can use information from the Path message it received for the forward direction 🧠. For example, the RSVP Sender Proxy may mirror the SENDER_TSPEC object from the received Path message 🪞.
We observe that this approach does not require any extensions to the existing RSVP protocol 🎉.
In the case where reservations are required in both directions (as in Figure 7), the RSVP-capable device just behaves as a regular RSVP sender and RSVP receiver 🤝. It doesn't need to know an RSVP proxy is being used, and the Path message it sends for the forward reservation also acts as the trigger for setting up the reverse reservation ✨. However, when a reservation is only required in the reverse direction (as in Figure 6), the RSVP-capable device has to generate Path messages to trigger the reverse-direction reservation, even if no reservation is required in the forward direction 😭. That doesn't violate [RFC2205]. Still, it may not be the default behavior of an RSVP-capable device, so it may need a specific behavioral change to make the Path-Triggered Sender Proxy for Reverse Direction work 🛠️.
4.3. Inspection-Triggered Proxy ✨
okay so in this approach, we're assuming the RSVP proxy sits right on the data path of "packets of interest" 👀. It can inspect those packets on the fly as they zoom through, infer info from them to figure out which RSVP reservations need to exist, when, and with what characteristics (it might also lean on some configured info 💅).
One example of "packets of interest" is application-level signaling. A proxy that can read SIP signaling for a multimedia session, or RTSP signaling for video streaming, can learn when a session is up or when a video is about to stream 🎀. It can also grab the addresses and ports of senders and receivers and figure out the bandwidth of the corresponding flows. It can even tell when the reservation isn't needed anymore and tear it down 🧚. So this proxy basically has everything it needs to line RSVP reservations up with app requirements 🫶. Figure 8 shows the whole setup:
|-------------|
| Application |
| Signaling |
| Entity |
|-------------|
/ \
/ \
/ \
</////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\>
|----| |********| *** |********| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----|
|********| |********|
=======RSVP=======>
********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
</\> application-level signaling
***> media flow
==> segment of flow path protected by RSVP reservation
Figure 8: Inspection-Triggered RSVP ProxyAnother example of "packets of interest" is transport control messages (like the Real-time Transport Control Protocol (RTCP) [RFC3550]) traveling alongside the application flow itself, meaning the media packets. A proxy that can detect packets from a particular flow can try to establish a reservation for that flow 🦋. The characteristics of that reservation can be derived from configuration, flow measurement, or a combination of both. But ngl, those methods usually come with operational drawbacks: configuration costs ops effort and can hinder new applications from getting introduced, and measurement is reactive, so an accurate reservation may lag behind actual traffic 💀.
If a reservation fails, the Inspection-Triggered RSVP Proxy has no direct mechanism to notify the application, since it isn't actively participating in application signaling itself. So the app isn't really in a position to take action, like ending the session (for example) 😭. To soften this, the proxy may mark the Differentiated Services codepoint (DSCP) ([RFC2474]) of flows that had an RSVP reservation successfully proxied differently from flows without one. In some situations, the proxy might even be able to modify the "packets of interest" (like application signaling messages) to pass along a hint to apps that the corresponding flows can't be guaranteed by RSVP reservations 💌.
With this approach, the RSVP proxy is effectively required to build app awareness by inspecting traffic, and then it's kinda limited in what it can do when a reservation fails 🙈. Depending on which "packets of interest" trigger the reservation, there's a risk the proxy ends up reserving for a media flow that never actually starts. The good news is this can be handled by timing out and tearing down an unnecessary reservation when no matching media flow shows up. That same flow-observation-and-timeout trick can also clean up reservations that were rightfully set up for a flow but aren't needed anymore because the flow stopped 🧹.
The Inspection-Triggered approach is also subject to the general limitations of data inspection. That means it can be impeded by encryption or tunneling, or depend on topology constraints, like relying on the fact that both the packets of interest and the corresponding flow packets always transit through the same RSVP proxy 🌸.
Nonetheless, this may be a useful approach in specific environments ✨. Also, this approach doesn't require any change to the RSVP protocol 🙌.
With the Inspection-Triggered RSVP Proxy approach, the RSVP router may be configurable to use and interpret some specific packets of interest as the trigger for RSVP Receiver Proxy behavior 🧚.
When operating off signaling traffic, the Inspection-Triggered RSVP Proxy may be able to detect from the signaling that the endpoint is capable of establishing an RSVP reservation (for example, in the case of SIP, by inspecting the precondition in [RFC3312]/[RFC4032]). In that case, it wouldn't behave as a proxy for that endpoint 👑. Also, the Inspection-Triggered RSVP Proxy may inspect RSVP signaling, and if it sees RSVP signaling for the flow of interest, it can disable its Sender Proxy behavior for that flow (or for that sender) 💅. Optionally, through RSVP signaling inspection, the Sender Proxy might also gradually "learn" (possibly with some timeout) which senders are RSVP-capable and which aren't 🧠. These mechanisms can facilitate a gradual and dynamic migration from the proxy model toward the end-to-end RSVP model as more and more endpoints become RSVP-capable 🌈💖.
4.4. STUN-Triggered Proxy ✨
okay bestie, this approach is giving "let STUN do the talking" 🎀. The RSVP proxy gets app awareness from the Session Traversal Utilities for NAT ([RFC5389]) signaling, so its reservations can line up with what the application actually needs 💅. The STUN signaling goes endpoint to endpoint (check out Figure 9 below) 🦋. Here, a STUN message is what triggers the RSVP proxy.
|----| |********| *** |********| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----|
|********| |********|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>
=======RSVP=======>
********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
^^^> STUN message flow (over same UDP ports as media flow)
==> segment of flow path protected by RSVP reservation
***> RTP media flow
Figure 9: STUN-Triggered ProxyFor unicast flows, [RFC5245] is a widely adopted approach for Network Address Translator (NAT) traversal 🌸. For our purposes of triggering RSVP proxy behavior, we rely on the Interactive Connectivity Establishment (ICE) protocol's connectivity check, which is based on the exchange of STUN Binding Request messages between hosts to verify connectivity (see Section 2.2 of [RFC5245]) 🫶. The STUN message could also include (yet to be specified) STUN attributes to indicate things like the bandwidth and the application requesting the flow, which would let the RSVP proxy agent create an appropriately sized reservation for each flow 🧚. Including those new STUN attributes in the ICE connectivity check messages would make the RSVP proxy easier to operate 🔥. To make sure RSVP reservations only get set up when they're needed, the RSVP proxy has to tell apart, among all the STUN messages, the ones that (with high likelihood) reflect an actual upcoming media flow 😭. This can be done by identifying the STUN messages associated with an ICE connectivity check, and that can be achieved through (some combination of) these checks:
- If, as discussed above, new STUN attributes (for example, ones conveying the flow bandwidth) are indeed defined in the future to facilitate STUN-triggered reservations, then the presence of those attributes would reveal that the STUN message is part of an ICE connectivity check.
- The presence of the
PRIORITY,USE-CANDIDATE,ICE-CONTROLLED, orICE-CONTROLLINGattributes reveals that the STUN message is part of an ICE connectivity check. - The RSVP proxy may wait for a STUN message containing the
USE-CANDIDATEattribute, which indicates the selected ICE "path", and trigger a reservation only for the selected "path". This lets the proxy reserve only for the "path" that's actually selected, and therefore for the media flow that will actually get established (for example, when ICE is used for IPv4/v6 path selection) 👑. - The RSVP proxy configuration could contain some information that helps it decide when to perform an RSVP proxy reservation and when not to. For example, the RSVP proxy configuration could contain the IP addresses of the STUN servers, so STUN messages to and from those addresses are known to not be part of an ICE connectivity check. As another example, the RSVP proxy configuration could contain information identifying the set of Differentiated Services codepoint (
DSCP) values that the media flows requiring reservation use, so that STUN messages not using one of thoseDSCPvalues are known to not be part of an ICE connectivity check.
Despite these checks, there's always a potential risk that the RSVP proxy ends up establishing a reservation for a media flow that never actually starts 💀. That's limited to situations where the end-systems are interested enough in establishing connectivity for a flow but never transmit. This can also be mitigated by timing out and tearing down an unnecessary reservation by the RSVP proxy when no corresponding media flow is observed ⭐.
The RSVP proxy agent can inform endpoints of an RSVP reservation failure implicitly, by dropping the ICE connectivity check message, or explicitly, by sending ICMP messages back to the endpoint 🍓. This allows reasonably effective synchronization between the RSVP reservations handled by the RSVP proxies and the application running on non-RSVP-capable endpoints 💖. It also has the benefit of operating through NATs ✨.
For multicast flows (or certain kinds of unicast flows that don't or can't use ICE), a STUN Indication message [RFC5389] could be used to carry the (yet to be defined) STUN attributes mentioned earlier to indicate the flow bandwidth, which gives a benefit similar to the ICE connectivity check 🌈. STUN Indication messages are not acknowledged by the receiver, and they have the same scalability as the underlying multicast flow 🙈.
The corresponding extensions to ICE and STUN for such a STUN-Triggered RSVP Proxy approach are beyond the scope of this document 🧚. They may be defined in the future in a separate document. Since the STUN-Triggered RSVP Proxy approach uses STUN in a way (i.e., to trigger reservations) that goes beyond its initial intended purpose, the potential security implications need to be considered by the operator 🚨.
Heads up, security friends: STUN was not originally designed to trigger reservations. Using it that way is beyond its initial intended purpose, so the operator needs to think hard about the security implications before deploying this approach. 🔒💀
ICE connectivity checks are not always used for all flows 🦋. When the STUN-Triggered RSVP Proxy approach is used, it can establish RSVP reservations for flows for which ICE connectivity is performed. However, the STUN-Triggered RSVP Proxy will not establish a reservation for flows for which an ICE connectivity check is not performed. Those flows either won't benefit from an RSVP reservation, or they can benefit from an RSVP reservation established through other means (end-to-end RSVP, other forms of RSVP proxy) 💅.
The STUN-Triggered approach relies on interception and inspection of STUN messages 👀. Thus, this approach may be impeded by encryption or tunneling 🔐.
4.5. Application_Entity-Controlled Proxy 💅
okay so this one is giving "let the app be in charge" 🫶 It's assumed that an entity involved in application-level signaling controls an RSVP proxy that sits in the data path of the application flows (aka "on-path") 🧚 The proxy doesn't try to work out the application's reservation needs by itself. Instead, the application-signaling entity tells it when to establish, maintain, and tear down reservations as the app flows need them ✨ So the way RSVP signaling stays in sync with app requirements is by relying on an app-level signaling entity that controls an RSVP proxy function sitting in the flow data path 👑 This approach can control an RSVP Sender Proxy, an RSVP Receiver Proxy, or both 💖
The operation of the Application_Entity-Controlled Proxy is shown in Figure 10 🎀
|---------| |---------|
/////////| App |////\\\\| App |\\\\\\\\
/ | Entity | | Entity | \
/ |---------| |---------| \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
|----| |********| *** |*********| |----|
| S |----------| |------*r*-------| |---------| R |
|----| | RSVP | *** | RSVP | |----|
| Sender | | Receiver|
| Proxy | | Proxy |
|********| |*********|
=======RSVP=======>
********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
==> segment of flow path protected by RSVP reservation
/\ Application signaling (e.g., SIP)
// RSVP proxy control interface
Figure 10: Application_Entity-Controlled ProxyQuick note on that diagram, it's a whole vibe 🌈 The app entities sit up top, the RSVP proxies sit in the path, and the solid line is the segment protected by the reservation 🦋
As an example, the Application_Entity-Controlled Proxy may be used with SIP servers ([RFC3261]) or Session Border Controllers (SBCs) (see [RFC5853] for a description of SBCs) to set up RSVP reservations for multimedia sessions 📞 In that case, the application entity may be the signaling component of the SBC 🍓
This RSVP proxy approach doesn't need any extension to the RSVP protocol 🙌 It does rely on an RSVP proxy control interface that lets an application signaling entity control the RSVP proxy, though. That interface is beyond the scope of this document, so we're not going deep on it here 🙈 Candidate protocols for realizing such an interface include the IETF Network Configuration (NETCONF) Protocol ([RFC4741], [RFC5277]), the Web Services protocol ([W3C]), the QoS Policy Information Model (QPIM) ([RFC3644]), and Diameter ([RFC3588]) 💜 The interface can rely on soft states or hard states. Obviously, when hard states are used, the RSVP proxy entities need to convert them appropriately into the corresponding RSVP soft states 🔥 As an example, [RFC5866] is intended to allow control of an RSVP proxy via Diameter 💅
In general, the application entity isn't expected to keep track of which RSVP Receiver Proxy is on the path to which destination 🤷♀️ But in the particular cases where it does so reliably, the application entity could control the RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP reservations are used between them, instead of one reservation per flow ✨ For example, these aggregate reservations could be of the RSVP-AGGREGATE type, as specified in [RFC3175], or of the GENERIC-AGGREGATE type, as specified in [RFC4860] 🌸 Aggregate reservations like these could let a single reservation cover multiple (possibly all) application flows that go through the same RSVP Sender Proxy and the same RSVP Receiver Proxy 🧚
For situations where only the RSVP Sender Proxy has to be controlled through this interface, the interface may be realized through the simple use of RSVP itself, over a Generic Routing Encapsulation (GRE) tunnel from the application entity to the RSVP Sender Proxy 🎀 This particular case is discussed further in Section 4.5.1. Another interesting case is when the application signaling entity lives on the same device as the RSVP proxy. In that case, the interface may be trivially realized as an internal API 🫶 An example environment based on this case is illustrated in Section 4.5.2.
The application entity controlling the RSVP proxy (for example, a SIP Call Agent) would often know a bunch of endpoint capabilities, and it has to know which endpoint can be best "served" by which RSVP proxy anyway 👑 So it's reasonable to assume that such an application knows whether a given endpoint is RSVP-capable or not 💖 The application may also consider the QoS preconditions and QoS mechanisms signaled by an endpoint per [RFC3312]/[RFC4032] and [RFC5432] ✨ The information about endpoint RSVP capability can then be used by the application to decide whether or not to trigger proxy behavior for a given endpoint 🦋 This can make it way easier to migrate gradually and dynamically from the proxy model toward the end-to-end RSVP model as more and more endpoints become RSVP-capable 🌈
In some environments, the application entities (for example, SIP back-to-back user agents) that need to control the RSVP proxies would already be deployed, whether or not anyone uses the Application_Entity-Controlled Proxy approach. In that case, activating the RSVP proxy approach should not cause significant disruption in the application signaling path 🙏 In some environments, additional application entities may need to be deployed to control the RSVP proxies. In that case, the network operator needs to consider the associated risks of disruption to the application signaling path ⚠️
4.5.1. Application_Entity-Controlled Sender Proxy Using "RSVP over GRE" 🎀
okay this is basically a special case of the general Application_Entity-Controlled Proxy 🧚 It applies when only RSVP Sender Proxies need to be controlled by the application, and RSVP is effectively used as the control protocol between the application-signaling entity and the RSVP Sender Proxy 💅
In this approach, the RSVP messages (for example, the RSVP Path message) are effectively generated by the application entity and logically "tunneled" to the RSVP Sender Proxy via GRE tunneling 🫶 The point of this is to make sure the RSVP messages follow the exact same path as the flow they protect (as RSVP operations require) on the segment of the end-to-end path that is going to be subject to RSVP reservations 🛣️
Figure 11 illustrates such an environment 🦋
|-------------|
////////////| Application |\\\\\\\\\
/ | Entity | \
/ |-------------| \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
|----| |********| *** |****|
| S |-----------| RSVP |-----------*r*-----------------| R |
|----| | Sender | *** |****|
| Proxy |
|********|
=========RSVP====================>
*****************************************************>
|----| non-RSVP-capable |----| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
==> segment of flow path protected by RSVP reservation
/\ Application-level signaling
/=/ GRE-tunneled RSVP (Path messages)
Figure 11: Application_Entity-Controlled Sender Proxy via
"RSVP over GRE"With the Application_Entity-Controlled Sender Proxy using "RSVP over GRE", the application entity:
- generates a Path message on behalf of the sender, corresponding to the reservation the application needs, and maintains the corresponding Path state. The Path message built by the application entity is exactly the same as the one the actual sender would build (if it were RSVP-capable), with one single exception: the application entity puts its own IP address in as the RSVP previous hop. In particular, it is recommended that the source address of the Path message built by the application entity be set to the IP address of the sender (not of the application entity) 🧠 This helps make sure that, in the presence of non-RSVP routers and of load-balancing in the network where the load-balancing algorithm takes the source IP address into account, the Path message generated by the application entity follows the exact same path as the actual stream sourced by the sender 🔥
- encapsulates the Path message into a GRE tunnel whose destination address is the RSVP Sender Proxy, that is, an RSVP router sitting on the data path for the flow (and upstream of the segment that requires QoS guarantees via RSVP reservation) 🎁
- processes the corresponding received RSVP messages (including Resv messages) as per regular RSVP 💅
- synchronizes the RSVP reservation state with application-level requirements and signaling 🫶
Note that since the application entity encodes its own IP address as the previous RSVP hop inside the [RFC2205] RSVP_HOP object of the Path message, the RSVP router terminating the GRE tunnel naturally sends all the RSVP messages traveling upstream hop-by-hop (such as Resv messages) to the application entity 🙌 It doesn't need to encapsulate those in a reverse-direction GRE tunnel back toward the application entity ✨
4.5.2. Application_Entity-Controlled Proxy via Co-Location ✨
okay so this one is basically a special case of the Application_Entity-Controlled Proxy, but with a twist: the application entity lives right next to the RSVP proxy 🏠 for example, Session Border Controllers (SBCs) with on-board SIP agents could run the RSVP proxy functions and use this to do session admission control over the SBC-to-SBC segment with RSVP signaling. iconic, honestly 💅
Figure 12 shows how the co-located version works 🦋
|---------| |---------|
////////| App |////////\\\\\\\| App |\\\\\\\\\
/ | Entity | | Entity | \
/ | | | | \
|----| |*********| *** |*********| |----|
| S |--------| RSVP |------*r*------| RSVP |---------| R |
|----| | Sender | *** | Receiver| |----|
| Proxy | | Proxy |
|*********| |*********|
=======RSVP======>
*******************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
==> segment of flow path protected by RSVP reservation
/\ Application-level signaling
Figure 12: Application_Entity-Controlled Proxy via Co-Locationthis approach does not require any protocol extensions, so no new signaling to learn, bestie 🎀 also, when a bunch of sessions are set up on paths that share the same RSVP Sender Proxy and the same RSVP Receiver Proxy, the proxies can choose to set up aggregate RSVP reservations (as defined in ([RFC3175] or [RFC4860]) for the whole group of sessions, instead of one reservation per session. very efficient, very chic 🌸
4.6. Policy_Server-Controlled Proxy
in this approach, a policy server sits in the control plane of the network and controls an RSVP proxy that lives in the data path of the application flows (the "on-path" one) 🛰️ the policy server gets triggered by some entity that's part of the application-level signaling. the RSVP proxy doesn't try to figure out what the application needs for reservations on its own. instead, the policy server tells it to set up, keep up, and tear down reservations as the application flows need them. and the entity doing application-level signaling doesn't have to understand RSVP or the network topology either 🙈 it just asks the policy server to set up (or tear down) a reservation. so the big idea is that application-level stuff gets synced with RSVP through an application entity that talks to a policy server, which then controls an RSVP proxy sitting in the flow's data path. this approach can control an RSVP Sender Proxy, an RSVP Receiver Proxy, or both ✨
here's how the Policy_Server-Controlled proxy works, shown in Figure 13 💖
|---------|
/////////////| App |\\\\\\\\\\\\\\
/ | Entity | \
/ |---------| \
/ I \
/ I \
/ |----------| \
/ | Policy | \
/ | Server | \
/ |----------| \
/ // \\ \
/ // \\ \
/ // \\ \
|----| |********| *** |*********| |----|
| S |-----------| |------*r*-----| |----------| R |
|----| | RSVP | *** | RSVP | |----|
| Sender | | Receiver|
| Proxy | | Proxy |
|********| |*********|
=====RSVP========>
**********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
==> segment of flow path protected by RSVP reservation
/\ Application signaling (e.g., SIP)
// RSVP proxy control interface
I Interface between application entity and policy server
Figure 13: Policy_Server-Controlled Proxythis approach doesn't need any extension to the RSVP protocol 🌈 but, just like the Application_Entity-Controlled Proxy approach from Figure 10, it leans on an RSVP proxy control interface so the policy server (in this case) can control the RSVP proxy. that control interface is beyond the scope of this document, so ✋ if you want thoughts on candidate protocols for building it, peek at Section 4.5. and for when only the RSVP Sender Proxy needs to be controlled by this interface, the interface can be done with plain RSVP itself, running over a GRE tunnel from the policy server to the RSVP Sender Proxy. it's basically what Section 4.5.1 describes, except here the "RSVP over GRE" interface is used by the policy server instead of the application entity 🦋
the interface between the application entity and the policy server is also beyond the scope of this document 💅
4.7. RSVP-Signaling-Triggered Proxy
an RSVP proxy can also get triggered and controlled through extended RSVP signaling coming from the remote end, as long as that end is RSVP-capable and supports these RSVP extensions for proxy control 📡 for example, an RSVP-capable sender could send a new or extended RSVP message that explicitly asks an RSVP proxy on the path toward the receiver to act as an RSVP Receiver Proxy, and also to trigger a reverse-direction reservation, so it acts as an RSVP Sender Proxy too. the sender's message could also carry attributes (like bandwidth) for the reservations the RSVP proxy is going to signal 💜
these explicit signaling schemes come with some challenges, like:
- How can the nodes determine when a reservation request ought to be proxied and when it should not, and accordingly invoke appropriate signaling procedures?
- How does the node sending the messages explicitly triggering the proxy know where the proxy is located, e.g., determine an IP address of the proxy that should reply to the signaling?
- How is all the information needed by a Sender Proxy to generate a Path message actually communicated to the proxy?
an example of this is in [QOS-MOBILE] 🔥 the scheme is mainly aimed at reservations on the local access network, where an end host can request resource reservations for both incoming and outgoing flows, but only over the access network. this can be handy where the access network is usually the bottleneck and the core is comparatively over-provisioned, which can be the case with a bunch of radio access technologies. in this proposal, messages aimed at the proxy get flagged with one bit in all RSVP messages, and all RSVP messages sent back by the proxy are flagged too. that flag lets you tell proxied reservations apart from end-to-end ones 🫶 to trigger an RSVP Receiver Proxy, the sender of the data sends a Path message marked with that flag. the Receiver Proxy sits on the signaling and data path, gets the Path message, and replies with a Resv message. to trigger an RSVP Sender Proxy, a node uses a newly defined Path_Request message, which tells the proxy to send Path messages toward the triggering node. the node then replies with a Resv. more details are in [QOS-MOBILE] if you want the deep dive 🧚
this RSVP-Signaling-Triggered Proxy approach would need RSVP signaling extensions, which are outside the scope of this document. still, it could give you more flexibility in controlling proxy behavior (like control of reverse reservation parameters) than the Path-Triggered approaches defined in Section 4.1 and Section 4.2 can. 💅
through potential matching protocol extensions, an RSVP-Signaling-Triggered Proxy approach could make things easier to run (like cutting down or skipping some of the configuration) in hybrid environments that mix end-to-end reservations and reservations set up through RSVP proxies. for example, [QOS-MOBILE] proposed a mechanism that lets an end-system control whether a reservation can be handled by an RSVP proxy on the path or has to be set up end-to-end 🍓
4.8. Reachability Considerations
there are situations where the RSVP Receiver Proxy can reach the sender, but the receiver itself can't be reached 🙈 in those cases, the RSVP Receiver Proxy might not always realize that the receiver is unreachable, so it could agree to set up an RSVP reservation on behalf of that receiver. that means unnecessary reservations and wasted network resources, which is definitely not it 😭
this isn't considered a big practical worry, and here's why 💖 first, in lots of cases, if the receiver can't be reached from the sender, it won't be reachable for application signaling either, so application-level session setup wouldn't have been possible in the first place. second, if the receiver is unreachable from the sender but is reachable for application-level signaling (say, because session setup goes through an off-path SIP agent that uses a different logical topology to talk to the receiver), then the sender might detect that the receiver is unreachable before it tries to set up a reservation. this can happen through things like ICE's connectivity check ([RFC5245]) 🔍 and finally, even if the sender doesn't detect the unreachable receiver before triggering the RSVP reservation setup, the application will very likely notice fast. like, the human answering the call on the receiver side won't hear the human on the sender side, so they'll end the session (hang up the phone), and that triggers the RSVP reservation release. 📞✨
still, network administrators should think about all of this in light of their own environment when they deploy RSVP proxies 🌸
the mirror-image considerations apply to situations involving an RSVP Sender Proxy, where the sender can't reach the destination but the RSVP Sender Proxy can 🦋
5. Security Considerations 🔐
okay so this is the security part and it's giving "serious but make it iconic." 💅 RSVP messages are used to control resource reservations on a segment of the end-to-end path of flows, in the environments we're talking about. The general security considerations from [RFC2205] apply here too, so nothing new is being thrown out. 🫶
To keep the reservation and admission control mechanisms intact, the RSVP cryptographic authentication mechanisms defined in [RFC2747] and [RFC3097] can be used. They protect RSVP messages' integrity hop-by-hop and provide node authentication, which means they guard against corruption, spoofing of RSVP messages, and replay. ✨ [RSVP-SEC-KEY] goes into key types and key provisioning methods, and how well each one fits RSVP authentication. 🔑
[RSVP-SEC-KEY] also talks about how IPsec mechanisms ([RFC4302][RFC4303]) apply, along with their key provisioning methods, for protecting RSVP. This discussion covers RSVP in the presence of RSVP proxies as defined in this document. 🦋
A subset of RSVP messages are signaled with the IP router alert option ([RFC2113], [RFC2711]). Because of the current security concerns with that option, RSVP (and so the RSVP proxy approaches in this document) is only applicable in controlled environments. That means environments where the security risks of the IP router alert option are understood and protected against. 🚨 The security aspects, common practices, and the consequences of applications like RSVP using the IP router alert option are covered in detail in [RTR-ALERT]. 📚
A bunch of extra security considerations apply to RSVP proxies, and we'll go through them below. 🎀
Some RSVP proxy approaches have the RSVP proxy running autonomously inside an RSVP router. That's the case for the Path-Triggered Proxy approaches in Section 4.1 and Section 4.2, the Inspection-Triggered Proxy in Section 4.3, the STUN-Triggered Proxy in Section 4.4, and the RSVP-Signaling-Triggered approach in Section 4.7. 🤖 Proper reservation operation assumes the RSVP proxy can be trusted to behave correctly, controlling the RSVP reservation the way end-systems need and expect. Basic RSVP already assumes end-systems trust RSVP nodes to make reservations properly, so an autonomous proxy inside an RSVP router isn't seen as adding any significant new threat or fundamentally changing the RSVP trust model. 💖
Other approaches have the RSVP proxy operating under the control of another entity. That's the Application_Entity-Controlled Proxy in Section 4.5 and the Policy_Server-Controlled Proxy in Section 4.6. 😬 This is riskier, because the entity controlling the RSVP proxy has to be trusted for proper reservation operation, and it also brings extra authentication and confidentiality requirements. The exact mechanisms for setting up that trust, authentication, and confidentiality are out of scope for this document. They could include security mechanisms inside the protocol used as the control interface between the RSVP proxy and its controlling entity, plus security mechanisms on all the interfaces in the reservation control chain. Think the application signaling protocol between the end-systems and the application entity, and, for the Policy_Server-Controlled Proxy approach, the protocol between the application entity and the policy server. 🔐🫣
Plot twist: using an RSVP proxy to control reservations for end-systems might actually reduce security risk, at least from the network operator's point of view. 🧚 For example, the routers running the RSVP proxy functionality are less exposed to tampering than end-systems are. Section 4 of [RFC5946] goes into this further. It's also possible because an RSVP proxy lets RSVP operation stay inside one administrative domain, which easily becomes a controlled environment, even when the end-to-end flow path spans several administrative domains. 👑
6. Acknowledgments 🙏
This document built on earlier work on the RSVP proxy concept, including the work documented by Silvano Gai, Dinesh Dutt, Nitsan Elfassy, and Yoram Bernet. 🌸 It also got a lot out of discussions with Pratik Bose, Chris Christou, and Michael Davenport. 💜 Tullio Loffredo and Massimo Sassi provided the base material for Section 4.6. 🍓 Huge thanks to James Polk, Magnus Westerlund, Dan Romascanu, Ross Callon, Cullen Jennings, and Jari Arkko for their thorough review and comments. 🫶✨
7. References
7.1. Normative References
[RFC2205]Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.[RFC2210]Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.[RFC2475]Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.[RFC2747]Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.[RFC3097]Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.[RFC5245]Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.[RFC5389]Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
7.2. Informative References
[QOS-MOBILE]Manner, J., "Provision of Quality of Service in IP-based Mobile Access Networks", Doctoral dissertation, University of Helsinki, 2003, <http://ethesis.helsinki.fi>.[RFC1633]Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.[RFC2113]Katz, D., "IP Router Alert Option", RFC 2113, February 1997.[RFC2326]Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.[RFC2474]Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.[RFC2711]Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.[RFC2872]Bernet, Y. and R. Pabbati, "Application and Sub Application Identity Policy Element for Use with RSVP", RFC 2872, June 2000.[RFC2961]Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.[RFC3175]Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.[RFC3261]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.[RFC3312]Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.[RFC3550]Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.[RFC3588]Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.[RFC3644]Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. Moore, "Policy Quality of Service (QoS) Information Model", RFC 3644, November 2003.[RFC4032]Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.[RFC4301]Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.[RFC4302]Kent, S., "IP Authentication Header", RFC 4302, December 2005.[RFC4303]Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.[RFC4566]Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.[RFC4741]Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.[RFC4860]Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007.[RFC4923]Baker, F. and P. Bose, "Quality of Service (QoS) Signaling in a Nested Virtual Private Network", RFC 4923, August 2007.[RFC5277]Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.[RFC5432]Polk, J., Dhesikan, S., and G. Camarillo, "Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)", RFC 5432, March 2009.[RFC5853]Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.[RFC5866]Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, "Diameter Quality-of-Service Application", RFC 5866, May 2010.[RFC5946]Le Faucheur, F., Manner, J., Narayanan, A., Guillou, A., and H. Malik, "Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy", RFC 5946, October 2010.[RFC5974]Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.[RSVP-SEC-KEY]Behringer, M. and F. Le Faucheur, "Applicability of Keying Methods for RSVP Security", Work in Progress, June 2009.[RTR-ALERT]Le Faucheur, F., "IP Router Alert Considerations and Usage", Work in Progress, October 2009.[W3C]"World Wide Web Consortium (W3C) - Web Services Architecture", <http://www.w3.org/TR/ws-arch/>.
Appendix A. Use Cases for RSVP Proxies 🎀
A.1. RSVP-Based VoD Admission Control in Broadband Aggregation Networks 🎬
okay so broadband for residential customers is blowing up 🚀, which means next-gen aggregation networks are getting built to gather traffic from all those broadband users. That includes DSL (aka DSL), FTTH/FTTC (aka FTTx), cable, or whatever other broadband access tech is around 🌈. Now, Video on Demand (VoD) services, which might be offered to those users, are a total capacity-planning nightmare for the aggregation network, and it's giving stress 😭. First, every VoD stream needs a serious amount of dedicated, sustained bandwidth (typically 2-4 Mb/s for Standard Definition TV and 6-12 Mb/s for High Definition TV). Second, VoD codec algorithms are super sensitive to packet loss 💀. Finally, the load is basically impossible to predict. It can spike out of nowhere with a blockbuster title drop or a promo 🍿. So, ngl, carrying VoD streams across the aggregation network usually comes with a strong requirement for admission control 🔥. That admission control protects the quality of sessions that are already running by rejecting extra, excessive session attempts during unpredictable peaks, during link or node failures, or when a mix of those things happens at once 💅.
RSVP can totally be used in the aggregation network for admission control of VoD sessions ✨. The catch is that customer premises equipment like Set Top Boxes (STBs), which act as the receiver for VoD streams, often doesn't support RSVP 🙈. So the last IP hop in the aggregation network can behave as an RSVP Receiver Proxy 🧚. That way RSVP can run between the VoD pumps and the last IP hop to do accurate admission control over the resources set aside for VoD, which is usually some percentage of the bandwidth on any link 📊. Since VoD streams are unidirectional, a simple Path-Triggered RSVP Receiver Proxy (as described in Section 4.1) is all that is required in this use case 🦋.
Figure 14 shows how RSVP-based admission control of VoD sessions works in an aggregation network with RSVP support on the VoD pump (the senders) and the RSVP Receiver Proxy on the last IP hop of the aggregation network. All the customer premises equipment stays RSVP-unaware 🫶.
|-------------|
| VoD SRM |
| |
////////| |\\\\\\\\\\\\\\
/ |-------------| \
/ \
/ \
/ \
/ \
/ \
|****| *** *** *** |********| |-----| |---|
|VoD |---*r*---*r*---*r*---|RSVP |---|DSLAM|~~~~|STB|--TV
|Pump| *** *** *** |Receiver| |-----| |---|
|****| |Proxy |
|********|
<---Aggregation Net----------->
************************************************>
==============RSVP================>
SRM Session Resource Manager
*** |---|
*r* regular RSVP |STB| Set Top Box
*** router |---|
***> VoD media flow
==> segment of flow path protected by RSVP reservation
/\ VoD Application-level signaling (e.g., RTSP)
Figure 14: VoD Use Case with Receiver ProxyIn the case where the VoD pumps aren't RSVP-capable, an Application_Entity-Controlled Sender Proxy via the "RSVP over GRE" approach (as described in Section 4.5.1) can also be implemented on the VoD Controller or Session Resource Manager (SRM) devices that are usually part of VoD deployments 🛠️. Figure 15 shows RSVP-based admission control of VoD sessions in an aggregation network with that Application_Entity-Controlled Source Proxy paired with an RSVP Receiver Proxy on the last IP hop of the aggregation network. All the customer premises equipment, plus the VoD pumps, stay RSVP-unaware 🌸.
|-------------|
////| VoD SRM |\\\\\\\\\\\
/ | | \
/ | + | \
/ | RSVP Sender | \
/ |Proxy Control| \
/ |-------------| \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
|----| |******| *** *** |********| |-----| |---|
| VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV
|Pump| |Sender| *** *** |Receiver| |-----| |---|
|----| |Proxy | |Proxy |
|******| |********|
<---Aggregation Net------------->
************************************************>
=========RSVP==============>
SRM Systems Resource Manager
*** |---|
*r* regular RSVP |STB| Set Top Box
*** router |---|
***> VoD media flow
==> segment of flow path protected by RSVP reservation
/ VoD Application-level signaling (e.g., RTSP)
/=/ GRE-tunneled RSVP (Path messages)
Figure 15: VoD Use Case with Receiver Proxy
and SRM-Based Sender ProxyThe RSVP proxy entities specified in this document play a big role here 🌈. They let you deploy an RSVP-based admission control solution for VoD right away, without upgrading the huge installed base of non-RSVP-capable customer premises equipment 😤. In one of the modes described above, they also avoid upgrading non-RSVP-capable VoD pumps 🙌. So, bestie, the benefits of on-path admission control can reach VoD services over broadband aggregation networks without any network or VoD pump upgrade 👑. Those benefits include accurate bandwidth accounting regardless of topology (hub-and-spoke, ring, mesh, star, or arbitrary combinations) and dynamic adjustment to any change in topology (such as failure, routing change, additional links, etc.) ✨.
A.2. RSVP-Based Voice/Video Connection Admission Control (CAC) in Enterprise WAN 📞
More and more enterprises are moving their telephony and videoconferencing apps onto IP 💜. When they do, they still need the admission control that existing TDM-based (Time-Division Multiplexing) systems offer, so the QoS of these apps stays solid even when traffic goes through the enterprise's Wide Area Network (WAN) 🫧. A lot of the endpoints already out there, like IP phones or videoconferencing terminals, aren't RSVP-capable 😭, so RSVP proxy approaches are super useful. They let you deploy an RSVP-based admission control solution over the WAN without upgrading the existing terminals 🎀.
A common deployment architecture for these environments relies on the Application_Entity-Controlled Proxy approach defined in Section 4.5 🧠. Routers at the edges of the WAN are naturally "on-path" for all inter-campus calls (or sessions), so they behave as RSVP proxies 🚦. The RSVP proxies set up, maintain, and tear down RSVP reservations over the WAN segment for the calls (or sessions) under the control of the SIP server/proxy 💅. The SIP server/proxy keeps the RSVP reservation status in sync with the status of end-to-end calls 🔄. For example, the called IP phone will only be told to play a ring tone if the RSVP reservation over the corresponding WAN segment has been successfully established 🔔. That's some serious main character coordination 👑.
This architecture, which allows RSVP-based admission control of voice and video on the enterprise WAN, is illustrated in Figure 16 🦋.
|---------|
//////////////| SIP |\\\\\\\\\\\\
/ | Server/ | \
/ | Proxy | \
/ |---------| \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
|-----| |********| *** *** |********| |-----|
| IP |------| Media |---*r*---*r*---| Media |-------|IP |
|Phone| | Relay | *** *** | Relay | |Phone|
|-----| | + | | + | |-----|
| RSVP | | RSVP |
| Proxy | | Proxy |
|********| |********|
<--campus--> <--campus-->
network network
<---------WAN----------->
<*************> <***********************> <**************>
<=========RSVP===========>
***
*r* Regular RSVP router
***
<***> media flow
<==> segment of flow path protected by RSVP reservation
/\ SIP signaling
// control interface between the SIP server/proxy and
RSVP proxy
Figure 16: CAC on Enterprise WAN Use CaseA.3. RSVP Proxies for Mobile Access Networks 📱✨
Okay bestie, mobile access networks are going full IP now 🌐, which means that at the network layer, everything travels as packets: regular data and streamed stuff like audio or video. 💖 Popular multimedia apps would be so much happier with better-than-best-effort service, a forwarding service with strict Quality of Service (QoS) that guarantees minimum bandwidth and bounded delay. 🎀 Other stuff, like electronic commerce, network control and management, and remote-login apps, would also love differentiated treatment.
The IETF has two main models for giving packets in routers differentiated treatment. 🦋 The Integrated Services (IntServ) model [RFC1633], together with the Resource Reservation Protocol (RSVP) [RFC2205], [RFC2210], [RFC2961], gives per-flow guaranteed end-to-end transmission service. The Differentiated Services (Diffserv) framework [RFC2475] gives non-signaled flow differentiation that usually provides, but doesn't guarantee, proper transmission service.
However, these have some potential weak spots for mobile access networks 🥺. For example, RSVP needs support from both communication endpoints, and the protocol may have performance issues in mobile environments. Diffserv can only give statistical guarantees, and it isn't really built for dynamic environments.
Let's picture a scenario 👀: a fixed-network correspondent node (CN) is sending a multimedia stream to an end host behind a wireless link. If the CN doesn't support RSVP, it can't signal its traffic characteristics to the network or ask for specific forwarding services. Likewise, if the CN can't mark its traffic with a proper Differentiated Services codepoint (DSCP) to trigger service differentiation, the stream gets only best-effort service, which may mean poor visual and audio quality in the receiving app. Even if the wired network is over-provisioned, the end host would still benefit from local resource reservations, especially in wireless access networks, where the bottleneck is most probably the wireless link.
This is where RSVP proxies come in and save the day 🙌. They let you tell local network reservations apart from the end-to-end ones. The end host doesn't need to know the access network topology or which nodes will reserve local resources. The access network can do reservations for both incoming and outgoing flows based on certain criteria, e.g., filters based on application protocols. Another option is for the mobile end host to make an explicit reservation that says what it's intending to do, and then the access network finds the right local access network node(s) to respond. So RSVP proxies allow resource reservation over the segment that's most likely the bottleneck, the wireless link. And if the wireless access network uses a local mobility management mechanism, where the mobile node's IP address doesn't change during handover, RSVP reservations follow the mobile node as it moves. 🏃♀️💨
A.4. RSVP Proxies for Reservations in the Presence of IPsec Gateways 🔐
Okay, so [RFC4923] talks about how resource reservation can be supported end-to-end in a nested VPN environment. At each VPN level, VPN routers act as [RFC4301] security gateways between a plaintext domain and a ciphertext domain. To get end-to-end resource reservation, the VPN routers process RSVP signaling on the plaintext side, aggregate plaintext reservations, and keep the matching aggregate RSVP reservations on the ciphertext side. Each aggregate reservation is set up on behalf of multiple encrypted end-to-end sessions that share the same ingress and egress VPN routers. These aggregate reservations can be as specified in [RFC3175] or [RFC4860].
Section 3 of [RFC4923] covers the data flows needed inside a VPN router to get the behavior we just described. Two mechanisms are described for those data flows. Section 3.1 covers the case where the VPN router carries data across the cryptographic boundary. Section 3.2 covers the case where the VPN router uses a Network Guard.
If VPN routers don't support those mechanisms, the end-to-end approach in [RFC4923] can't be deployed 😩. An alternative for supporting resource reservations within the ciphertext core is to use the Application_Entity-Controlled Proxy approach (as defined in Section 4.5) in the following way:
- the RSVP proxies are located inside the ciphertext domain and use aggregate RSVP reservations.
- the application entity exchanges application-level signaling with the end-systems in the plaintext domain.
- the application entity controls the RSVP proxies in the ciphertext domain via an RSVP proxy control interface.
Figure 17 shows this in the case where the application is SIP-based multimedia communications 📞.
|-------| |-------|
|SIP |///////////////////\\\\\\\\\\\\\\\\\|SIP |
/|Server/| |Server/|\
/ |Proxy | |Proxy | \
/ |-------| |-------| \
/ ^ \\ // ^ \
/ ^ \\ // ^ \
/ ^ \\ // ^ \
|***| |------| |********| *** *** |********| |------| |***|
| S |---|IPsec |--| ARSVP |---*r*---*r*---| ARSVP |--|IPsec |---| R |
|***| | GW | | Sender | *** *** |Receiver| | GW | |***|
|------| | Proxy | | Proxy | |------|
|********| |********|
***PT*****> **********************CT****************> ****PT***>
=====> =====>
=====ARSVP======>
|****| RSVP-capable |****| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |****| *** router
|------|
|IPsec | IPsec security gateway
| GW |
|------|
ARSVP Aggregate RSVP
***> media flow
==> segment of flow path protected by RSVP reservation
/ \ SIP signaling
^ Network management interface between SIP server/proxy
and IPsec security gateway
// control interface between SIP server/proxy and ARSVP proxy
PT Plaintext network
CT Ciphertext network
Figure 17: RSVP Proxies for Reservations in the Presence of
IPsec GatewaysWhere the sender and receiver are RSVP-capable, they may also use RSVP signaling ✨. This gets reservations on the plaintext segments of the end-to-end path, i.e.,
- from the sender to the ingress IPsec gateway, and
- from the egress IPsec gateway to the receiver.
In this use case, the VPN routers don't support any RSVP-specific mechanism, so the end-to-end RSVP signaling is effectively hidden by the IPsec gateways on the ciphertext segment of the end-to-end path 🙈.
As with the Application_Entity-Controlled Proxy approach (defined in Section 4.5), the solution here for syncing RSVP signaling with application-level signaling is to rely on an application-level signaling device that controls an on-path RSVP proxy function. The difference is that here the RSVP proxies are part of a ciphertext network where all user (bearer) traffic is IPsec encrypted. That has a few implications:
- encrypted flows can't be identified in the ciphertext domain, so network nodes can only classify traffic based on IP address and Differentiated Services codepoints (DSCPs). As a result, only aggregate RSVP reservations (such as those specified in [RFC3175] or [RFC4860]) can be used. This is similar to [RFC4923].
- Figuring out the RSVP Sender Proxy and RSVP Receiver Proxy to use for aggregating a given flow from sender to receiver creates a number of challenges. Details on how this may be achieved are beyond the scope of this document. We observe that, as Figure 17 illustrates, this may be facilitated by a network management interface between the application entity and the IPsec gateways. For example, this interface may be used by the application entity to find out which IPsec gateway is on the path of a given end-to-end flow. Then, the application entity may keep awareness of which RSVP proxy is on the ciphertext path between a given pair of IPsec gateways. How such awareness is achieved is beyond the scope of this document. We simply observe that such awareness can be easily achieved through simple configuration in the particular case where a single (physical or logical) RSVP proxy is fronting a given IPsec gateway. We also observe that when awareness of the RSVP Receiver Proxy for a particular egress IPsec gateway (or end-to-end flow) isn't available, the aggregate reservation may be signaled by the RSVP Sender Proxy to the destination address of the egress IPsec gateway and then proxied by the RSVP Receiver Proxy.
Different flavors of aggregate reservation sizing are possible 🍓. For example, the application entity can initiate an aggregate reservation of fixed size a priori, then keep count of the bandwidth used by sessions and reject sessions that would result in excess usage of that aggregate reservation. The application entity could also re-size the aggregate reservations on a session-by-session basis. Or, it could re-size the aggregate reservations in step increments that typically correspond to the bandwidth requirement of multiple sessions.
Authors' Addresses 🎀
Francois Le Faucheur
Cisco Systems
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
France
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Jukka Manner
Aalto University
Department of Communications and Networking (Comnet)
P.O. Box 13000
FIN-00076 Aalto
Finland
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/
Dan Wing
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
United States
EMail: dwing@cisco.com
Allan Guillou
SFR
40-42 Quai du Point du Jour
Boulogne-Billancourt 92659
France
EMail: allan.guillou@sfr.com📦 where this page comes from
- ietf: rfc5945 2010-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms