RFC 5946

RFC 5946 🎀 Part 1 of 8

Okay bestie, this is RFC 5946, and it's called Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy 💖. It came from the Internet Engineering Task Force (IETF) in October 2010 📅 and it's a Standards Track doc 🔥. Its ISSN is 2070-1721, and it updates RFC 2205 🔄.

The authors are the whole squad 🫶: F. Le Faucheur from Cisco, J. Manner from Aalto University, A. Narayanan from Cisco, A. Guillou from SFR, and H. Malik from Airtel 🌸.

Abstract ✨

Okay so RSVP signaling can set up end-to-end resource reservations in an IP network 🦋. The whole point is to guarantee the Quality of Service (QoS) that certain flows need, and it's giving main character energy 👑.

With classic RSVP, both the data sender and the receiver of a flow take part in the signaling 💅. But literally there are so many use cases where you need a reservation and the receiver, the sender, or both aren't RSVP-capable 😭.

When the receiver isn't RSVP-capable, an RSVP router can act as an RSVP Receiver Proxy 🧚, which means it does the RSVP signaling on behalf of the receiver. That lets reservations get set up on the part of the end-to-end path that runs from the sender to the RSVP Receiver Proxy 🌈.

Now here's the tea ☕. The companion document "RSVP Proxy Approaches" explains that RSVP extensions are needed so a proxy can work when its signaling is triggered by RSVP Path messages coming from the sender 🍓. This document is where those extensions are specified 🎀.

Status of This Memo 📜

This is an Internet Standards Track document 🔥.

It's a product of the IETF, so it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. If you want more on Internet Standards, check Section 2 of RFC 5741 💖.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5946 🦋.

Copyright Notice ⚖️

The copyright is 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, which you can find at http://trustee.ietf.org/license-info as they stand on the publication date 📑. Please read them carefully, because they explain your rights and restrictions for this doc 👀. Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no 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 controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 🙈. Unless you get 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 one exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🌍.

Table of Contents 🗂️

   1. Introduction ....................................................4
      1.1. Conventions Used in This Document ..........................7
   2. Terminology .....................................................7
   3. RSVP Extensions for Sender Notification .........................8
      3.1. Sender Notification via PathErr Message ...................11
           3.1.1. Composition of SESSION and Sender Descriptor .......14
           3.1.2. Composition of ERROR_SPEC ..........................14
           3.1.3. Use of Path_State_Removed Flag .....................15
           3.1.4. Use of PathErr by Regular Receivers ................16
      3.2. Sender Notification via Notify Message ....................17
   4. Mechanisms for Maximizing the Reservation Span .................23
      4.1. Dynamic Discovery of Downstream RSVP Functionality ........24
      4.2. Receiver Proxy Control Policy Element .....................26
           4.2.1. Default Handling ...................................29
   5. Security Considerations ........................................29
      5.1. Security Considerations for the Sender
           Notification via Notify Message ...........................30
      5.2. Security Considerations for the Receiver Proxy
           Control Policy Element ....................................31
   6. IANA Considerations ............................................32
      6.1. RSVP Error Codes ..........................................32
      6.2. Policy Element ............................................32
   7. Acknowledgments ................................................33
   8. References .....................................................33
      8.1. Normative References ......................................33
      8.2. Informative References ....................................34

1. Introduction ✨

okay so bestie, guaranteed Quality of Service (QoS) 💖 for apps with super tight requirements can be achieved by reserving resources in each node on the end-to-end path 🛤️. The main IETF protocol for these reservations is the Resource Reservation Protocol (RSVP), specified in [RFC2205]. RSVP doesn't require every intermediate node to support it, but it assumes that both the sender and the receiver of the data flow support it. There are still environments where it would be useful to reserve resources for a flow (at least for a subset of the flow path) even when the sender or the receiver (or both) isn't RSVP-capable 🥺.

Since the data sender and receiver might both be unaware of RSVP, there are two types of RSVP Proxies 🎀. In the first case, an entity in the network has to invoke RSVP on behalf of the data sender. So it generates RSVP Path messages and eventually receives, processes, and sinks Resv messages. We call this entity the RSVP Sender Proxy. In the second case, an entity has to run RSVP on behalf of the receiver. So it receives Path messages sent by a data sender (or by an RSVP Sender Proxy) and replies to them with Resv messages generated on behalf of the data receiver(s). We call this one the RSVP Receiver Proxy.

RSVP Proxy approaches are presented in [RFC5945]. That doc also covers how the reservations controlled by an RSVP Proxy can be synced with application requirements, like when to establish, maintain, and tear down the reservation 🗓️.

One approach is the Path-Triggered RSVP Receiver Proxy approach. Here, the RSVP Receiver Proxy uses the RSVP Path messages from the sender (or RSVP Sender Proxy) as the cue to set up the reservation for the non-RSVP-capable receiver(s). It's basically an intermediary making reservations on the receiver's behalf, but under the sender's control. This flips the usual model, where receivers control reservations. But it's a huge help when the receiver isn't RSVP-capable 😤. It also lets the Receiver Proxy stay application-unaware by borrowing the application and RSVP awareness of the sender (or RSVP Sender Proxy). Iconic delegation 👑.

Now, the sender (or RSVP Sender Proxy) is the one syncing the reservation with the app, so it really needs to know the reservation state 🧠. Conventional RSVP assumes receivers control reservations, though. So some notifications, notably the error message sent when admission control rejects a reservation, only go toward the receiver. In this setup, that means the Receiver Proxy is the one who sinks them. Section 3 of this document specifies extensions that let these notifications also be conveyed toward the sender. That helps the sender sync the reservation with the application requirements, and it enables sender-driven control of reservations in Path-Triggered Receiver Proxy scenarios 💅.

With unicast applications and RSVP Receiver Proxies, if the sender is notified about the state of the reservation toward the receiver (thanks to this document), it's generally in a great position. It can sync the reservation with the app and do efficient sender-driven reservation. The sender controls the setup or removal of the reservation toward the receiver by sending Path or PathTear messages, respectively. For example, if the sender hears that the reservation for a point-to-point audio session toward the receiver was rejected, it may trigger rejection of the session at the application layer. It may also send a PathTear message to remove any corresponding RSVP state (e.g., Path states) it set up before 🎧.

Multicast apps, though, don't always vibe with RSVP Receiver Proxies 😬. Sender notification about reservation state toward each RSVP Receiver Proxy may not be enough for tight application-level sync by multicast senders. That's because multicast operation is receiver driven. End-to-end RSVP is also receiver driven (precisely so it can handle multicast efficiently), but RSVP Receiver Proxies only allow sender-driven reservation. A sender generally isn't aware of which receivers have joined downstream of a given RSVP Receiver Proxy, or even which RSVP Receiver Proxies have joined downstream of a given failure point. So it may not be possible to support a mode where a given receiver only joins a group if that receiver benefits from a reservation. A sender may also have no recourse if only a subset of RSVP Receiver Proxies return successful reservations, even with application-level signaling running between the sender and receivers, since it may not be able to correctly identify the set of receivers without reservations.

Still, it's possible to support a mode where multicast traffic is transmitted if and only if all receivers benefit from a reservation (from the sender to their respective RSVP Receiver Proxy). The sender makes sure of this by sending a PathTear message and stopping transmission whenever it gets a reservation-reject notification for one or more RSVP Receiver Proxies. It's also possible to support a mode where receivers join independently of whether they can benefit from a reservation (to their respective RSVP Receiver Proxy). They benefit from a reservation whenever the corresponding resources are reservable on the relevant path 🌈.

This document discusses extensions that make operations easier when a Path-Triggered RSVP Receiver Proxy is in play. As pointed out earlier, they apply equally whether RSVP signaling is initiated by a regular RSVP sender or by an RSVP Sender Proxy. (The latter comes with some way to sync reservation state with application-level requirements, which is outside the scope of this document.) For readability, the rest of this document discusses operations assuming a regular RSVP sender. Such operation is equally applicable where an RSVP Sender Proxy is used to initiate RSVP signaling on behalf of a non-RSVP-capable sender 🧚.

As discussed in [RFC5945], it's important to remember that the strongly recommended RSVP deployment model remains 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. Compared to the end-to-end RSVP model, using RSVP Proxies adds operational burden and/or imposes some topological constraints. So the purpose of this document is only 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.

Section 4.1.1 of [RFC5945] discusses mechanisms that allow the RSVP reservation for a given flow to be dynamically extended downstream of an RSVP Proxy whenever possible. That's when the receiver is RSVP-capable, or when there's another RSVP Receiver Proxy downstream. This can considerably ease the operational burden and topological constraints tied to Path-Triggered RSVP Receiver Proxies. It lets an RSVP reservation dynamically span as much of the flow path as possible, with any arbitrary number of RSVP Receiver Proxies on the path and whether or not the receiver is RSVP-capable, all without corresponding manual configuration 🔥. This also makes it easier to move from a Path-Triggered Receiver Proxy deployment to an end-to-end RSVP model. Receivers can be upgraded to support RSVP gradually and independently, then instantly benefit from end-to-end reservations. Section 4 of this document specifies these mechanisms and the associated RSVP extensions.

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 [RFC2119].

2. Terminology 💜

The following terminology is borrowed from [RFC5945] and is used a LOT in this document:

• RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per [RFC2205].
• RSVP Receiver Proxy: an RSVP-capable router performing, on behalf of a receiver, the RSVP operations that would normally be performed by an RSVP-capable receiver if end-to-end RSVP signaling were used. Note that while RSVP is used upstream of the RSVP Receiver Proxy, RSVP is not used downstream of it.
• RSVP Sender Proxy: an RSVP-capable router performing, on behalf of a sender, the RSVP operations that would normally be performed by an RSVP-capable sender if end-to-end RSVP signaling were used. Note that while RSVP is used downstream of the RSVP Sender Proxy, RSVP is not used upstream of it.
• Regular RSVP Router: an RSVP-capable router that is not behaving as an RSVP Receiver Proxy nor as an RSVP Sender Proxy.

Note that the roles of the RSVP Receiver Proxy, RSVP Sender Proxy, and regular RSVP Router are all relative to one unidirectional flow. A given router may act as the RSVP Receiver Proxy for a flow, as the RSVP Sender Proxy for another flow, and as a regular RSVP Router for yet another flow 🦋.

The following terminology is also used in this document:

• Regular RSVP sender: an RSVP-capable host behaving as the sender for the considered flow, and participating in RSVP signaling in accordance with the sender behavior specified in [RFC2205].
• Regular RSVP receiver: an RSVP-capable host behaving as the receiver for the considered flow, and participating in RSVP signaling in accordance with the receiver behavior specified in [RFC2205].

3. RSVP Extensions for Sender Notification ✨

okay bestie, this section is about giving the sender a heads-up when its reservation fails 💌 The whole point is keeping the RSVP reservation and what the app actually needs in sync, specifically when you've got a Path-Triggered RSVP Receiver Proxy in the mix 🧚

As discussed in [RFC5945], with the Path-Triggered RSVP Receiver Proxy approach, the RSVP router can be configured to treat receiving a regular RSVP Path message as the trigger for Receiver Proxy behavior 🦋 When a Path message shows up, the Receiver Proxy does this:

1. establishes the RSVP Path state as per regular RSVP processing. 🌸
2. identifies the downstream interface towards the receiver. 🗺️
3. sinks the Path message. 🫧
4. behaves as if a corresponding Resv message (on its way upstream from the receiver) was received on the downstream interface. This includes performing admission control on the downstream interface, establishing a Resv state (in the case of successful admission control), and forwarding the Resv message upstream, sending periodic refreshes of the Resv message and tearing down the reservation if the Path state is torn down. 💅

Here's how it looks when the reservation works 👀

 |****|        ***        ***        ***        |**********|      |----|
 | S  |--------*r*--------*r*--------*r*--------| RSVP     |------| R  |
 |****|        ***        ***        ***        | Receiver |      |----|
                                                | Proxy    |
                                                |**********|

      --Path---> --Path---> --Path---> --Path--->

      <---Resv-- <---Resv-- <---Resv-- <---Resv--

      ===================RSVP===================>

      ************************************************************>


 |****| RSVP-capable     |----| Non-RSVP-capable        ***
 | S  | Sender           | R  | Receiver                *r* regular RSVP
 |****|                  |----|                         *** router


 ***> media flow

 ==>  segment of flow path benefiting from an RSVP reservation

                     Figure 1: Successful Reservation

So here's the good news 🎀 When the reservation succeeds, regular RSVP already makes sure the sender gets told it worked. So no extensions are needed with a Path-Triggered RSVP Receiver Proxy when establishment goes through fine. Easy win 🙌

Now the messy part 😭 When the reservation fails, regular RSVP only makes sure the receiver (or the RSVP Receiver Proxy) hears about it. Specifically, if a regular RSVP router rejects something on admission control, a ResvErr message gets sent downstream toward the receiver. With a Receiver Proxy in the picture, following conventional RSVP means the Proxy finds out about the failure, but the sender does not. Major ghosting energy 💀 Here's what that looks like:

 |****|        ***        ***        ***        |**********|      |----|
 | S  |--------*r*--------*r*--------*r*--------| RSVP     |------| R  |
 |****|        ***        ***        ***        | Receiver |      |----|
                                                | Proxy    |
                                                |**********|

      --Path---> --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 benefiting from an RSVP reservation

           Figure 2: Reservation Failure with Conventional RSVP

Okay, so the sender could figure out something went wrong by noticing it never got a Resv message after a while 🙈 But it's so much better to get a prompt, explicit notification when the reservation fails. We're talking faster end-user notification at the application layer (think a busy signal 📞), faster application-level reactions (like application-level rerouting 🔀), and faster release of application-level resources 🧹 Main character energy for the whole app stack ✨

Section 3.1 defines one method for getting that sender notification of reservation failure. A router implementation claiming compliance with this document MUST support the method defined in Section 3.1. Non-negotiable 🔥

Section 3.2 defines another method for the same job. A router implementation claiming compliance with this document MAY support the method defined in Section 3.2. Optional, so it's your call 🫶

In a given network environment, a network administrator can pick the method in Section 3.1, pick the method in Section 3.2, or possibly combine the two 🧩 Flexible, iykyk.

---

3.1. Sender Notification via PathErr Message 🦋

With this method, the RSVP Receiver Proxy MUST generate a PathErr message whenever the two following conditions are met:

1. The reservation establishment has failed (or the previously established reservation has been torn down).
2. The RSVP Receiver Proxy determines that it cannot re-establish the reservation (e.g., by adapting its reservation request in reaction to the error code provided in the received ResvErr in accordance with local policy).

Now, the idea of sending a PathErr upstream to tell the sender about a reservation failure isn't actually brand new 💅 It's borrowed from [RFC3209], where it was introduced to meet a similar need: letting an MPLS Traffic Engineering (TE) Label Switching Router tell the TE Tunnel head-end (aka the sender) that it couldn't establish (or keep up) a TE Tunnel Label Switch Path. Recycling good ideas, iconic behavior 👑

Here's how the Path-Triggered RSVP Receiver Proxy looks when admission control fails and it uses a PathErr message to tell the sender 🌈

 |****|        ***        ***        ***        |**********|      |----|
 | S  |--------*r*--------*r*--------*r*--------| RSVP     |------| R  |
 |****|        ***        ***        ***        | Receiver |      |----|
                                                | Proxy    |
                                                |**********|

      --Path---> --Path---> --Path---> --Path--->

                            <---Resv-- <---Resv--

                            -ResvErr-> -ResvErr->

      <-PathErr- <-PathErr- <-PathErr- <-PathErr-

      ===================RSVP===================>

      ************************************************************>


 |****| RSVP-capable  |----| Non-RSVP-capable   ***
 | S  | Sender        | R  | Receiver           *r* regular RSVP
 |****|               |----|                    *** router

 ***> media flow

 ==>  segment of flow path benefiting from RSVP
      (but not benefiting from a reservation in this case)

    Figure 3: Reservation Failure with Sender Notification via PathErr

The whole job of this PathErr is to tell the sender the reservation wasn't established or got torn down 📣 That can happen because a ResvErr came in, or because something broke locally on the Receiver Proxy. When a ResvErr arrives and the reservation can't be installed in any situation, the Receiver Proxy MUST generate a PathErr towards the sender. For local failures on the Receiver Proxy node, if a similar failure on an RSVP midpoint would have caused a ResvErr to be generated (for example, an admission control failure), the Receiver Proxy MUST generate a PathErr towards the sender. The Receiver Proxy MAY additionally generate a PathErr upon local failures that wouldn't normally cause a ResvErr message to be generated, such as those described in Appendix B of [RFC2205]. Optional extra credit 🌟

The PathErr from the Receiver Proxy goes to the sender(s) that triggered the Resv messages which failed 🎯 For FF-style (Fixed-Filter) reservations, the Receiver Proxy MUST send a PathErr towards the (single) sender matching the failed reservation. For SE-style (Shared-Explicit) reservations, the Receiver Proxy MUST send the PathErr(s) towards the set of senders that triggered reservations that failed. That might be a subset of the senders sharing the same reservation, in which case the remaining senders keep their reservation intact and don't get a PathErr 🫧 In both cases, the rules in Section 3.1.8 of [RFC2205] for generating flow descriptors in ResvErr messages also apply when generating sender descriptors in PathErr messages. Consistency is everything 💜

WF-style (Wildcard-Filter) reservations are trickier 😬 Sometimes the Receiver Proxy just can't reliably know which sender caused the failure. So the Receiver Proxy SHOULD send a PathErr towards each sender. The downside is that every sender gets told the reservation isn't established, including the ones that didn't cause the failure 🙃 That makes sender notification via the PathErr method kind of overly conservative with the Wildcard-Filter style (when there's more than one sender). It can end up rejecting reservations from some senders when those reservations could've actually been set up. Oof, bestie.

The sender notification via PathErr works for both unicast and multicast sessions 🌐 But for multicast, a reservation failure close to a sender (say, admission control failing at a node near it) can send ResvErr messages to a big group of Receiver Proxies. All those Receiver Proxies would then send PathErr messages back to that same sender, and in some environments that could turn into a scalability issue 😵‍💫

Heads up: in a big multicast group, one failure near the sender can turn into a flood of PathErr messages all landing on the same sender. Keep scalability in mind 🚨

From the sender's point of view, errors that stop a reservation from being set up fall into two buckets 🪣

1. Errors that the sender can attempt to correct. The error code for these errors should explicitly be communicated back to the sender. An example of this is "Code 1: Admission Control Failure", because the sender could potentially resend a Path message with smaller traffic parameters. Fixable, so spill the code 💁
2. Errors over which the sender has no control. For these errors, it is sufficient to notify the sender that the reservation was not set up successfully. An example of this is "Code 13: Unknown Object", because the sender has no control over the objects inserted into the reservation by the Receiver Proxy. Not the sender's fault, so a simple "not set up" is enough 🤷‍♀️

The PathErr message generated by the Receiver Proxy has the same format as regular PathErr messages defined in [RFC2205] 📦 The SESSION, ERROR_SPEC, and sender descriptor are composed by the Receiver Proxy as specified in the following subsections. And the Receiver Proxy MAY reflect back towards the sender in the PathErr any POLICY_DATA objects received in the ResvErr 🎁 Optional, but a nice touch 🫶

3.1.1. Composition of SESSION and Sender Descriptor 💌

Okay bestie, so the Receiver Proxy MUST pop the SESSION object for the failed reservation right into the PathErr 💖. For FF-style reservations, the Receiver Proxy MUST also insert a sender descriptor for the failed reservation into the PathErr. That descriptor is equal to the error flow descriptor in the ResvErr the Receiver Proxy received. For SE-style reservations, the Receiver Proxy MUST insert a sender descriptor for the sender that triggered the failed reservation into the PathErr, again matching the error flow descriptor in the ResvErr it got ✨.

Now here's the spicy part 🌶️. If a midpoint node can't admit several flow descriptors, it generates multiple ResvErr messages toward the receiver, as per Section 3.1.8 of [RFC2205]. Each ResvErr carries an error flow descriptor that matches one specific sender. The Receiver Proxy MUST generate a PathErr for each ResvErr it receives, sent toward the matching sender. And like we said earlier, for WF-style reservations the Receiver Proxy SHOULD send a PathErr to each sender 🦋.

3.1.2. Composition of ERROR_SPEC 🎀

The Receiver Proxy MUST compose the ERROR_SPEC going into the PathErr like this:

1. If the Receiver Proxy receives a ResvErr with either of these error codes -- "Code 1: Admission Control Failure" or "Code 2: Policy Control Failure" -- then it copies the error code and value from the ERROR_SPEC in the ResvErr into the ERROR_SPEC of the PathErr message. The error node in the PathErr MUST be set to the address of the Receiver Proxy. This procedure MUST also be followed for a local error on the Receiver Proxy that would ordinarily cause a midpoint to generate a ResvErr with one of the above codes.
2. If the Receiver Proxy receives a ResvErr with any error code except the ones listed in item 1 above, it composes a new ERROR_SPEC with error code "36: Unrecoverable Receiver Proxy Error". The error node address in the PathErr MUST be set to the address of the Receiver Proxy. This procedure MUST also be followed for a local error on the Receiver Proxy that would ordinarily cause a midpoint to generate a ResvErr with any error code other than those listed in item 1 above, or if the Receiver Proxy generates a PathErr for a local error that ordinarily would not cause generation of a ResvErr.

Sometimes it's already known that the PathErr won't make it back to the sender 😭. For example, a node receiving a ResvErr with "Code 3: No Path for Resv" knows a priori that the PathErr message it generates cannot be forwarded by the same node that could not process the Resv. Even so, the procedures above MUST be followed.

For the error code "36: Unrecoverable Receiver Proxy Error", the 16 bits of the Error Value field are:

hhhh hhhh llll llll

Here's what the bits mean:

• hhhh hhhh = 0000 0000: then the low order 8 bits (llll llll) MUST be set by Receiver Proxy to 0000 0000 and MUST be ignored by the sender.
• hhhh hhhh = 0000 0001: then the low order 8 bits (llll llll) MUST be set by the Receiver Proxy to the value of the error code received in the ResvErr ERROR_SPEC (or, in case the Receiver Proxy generated the PathErr without having received a ResvErr, to the error code value that would have been included by the Receiver Proxy in the ERROR_SPEC in similar conditions if it was to generate a ResvErr). This error value MAY be used by the sender to further interpret the reason for the reservation failure.
• hhhh hhhh = any other value: reserved.

3. If the Receiver Proxy receives a ResvErr with the InPlace flag set in the ERROR_SPEC, it MUST also set the InPlace flag in the ERROR_SPEC of the PathErr.

3.1.3. Use of Path_State_Removed Flag 🧹

[RFC3473] defines an optional behavior where a node forwarding a PathErr message can remove the Path state associated with that PathErr message, and says so by including the Path_State_Removed flag in the ERROR_SPEC object of the PathErr message. This can help release resources faster and cut down on signaling load in some situations, which is honestly iconic 🙌.

This section talks about the Path_State_Removed flag stuff that's specific to the RSVP Receiver Proxy. For everything else, the Path_State_Removed flag works exactly as described in [RFC3473] 📖.

By default, the RSVP Receiver Proxy MUST NOT include the Path_State_Removed flag in the ERROR_SPEC of the PathErr message. This keeps things predictable in every environment, including ones where some RSVP routers don't understand the Path_State_Removed flag 🫶.

The RSVP Receiver Proxy MAY support an OPTIONAL mode (turned on by configuration) where it includes the Path_State_Removed flag in the ERROR_SPEC of the PathErr message and removes its local Path state. When every router on the path of a reservation supports the Path_State_Removed flag, using it really does lead to faster resource release and less signaling 🚀. But if there's one or more RSVP routers on the path that don't support the Path_State_Removed flag (we call these "old RSVP routers"), using it actually makes resource release slower and signaling heavier 💀. That's because an old RSVP router will propagate the Path_State_Removed flag upstream even though it doesn't understand it and doesn't tear down its Path state. So the sender won't send a Path Tear, and the old RSVP router only releases its Path state when the refresh time-out hits.

A network administrator needs to keep all of this in mind before deciding whether to turn on the Path_State_Removed flag on the RSVP Receiver Proxy 🧐. In a controlled environment where every router is known to support the Path_State_Removed flag, it can safely be turned on at the RSVP Receiver Proxy. In other environments, the administrator needs to figure out whether the gain for some reservations is worth the slowdown for other reservations.

3.1.4. Use of PathErr by Regular Receivers 🙅‍♀️

Heads up: even though this document says an RSVP Receiver Proxy generates a PathErr upstream when a reservation fails, it does not say regular receivers should do the same. This document does not propose changing how regular receivers behave, as currently specified in [RFC2205]. Here's why:

• When the receiver is RSVP-capable, the current receiver-driven model of [RFC2205] works perfectly, because the receiver can keep RSVP reservation state and application state in sync (since it takes part in both). The sender(s) don't need to know about the RSVP reservation state. So we keep the receiver-driven perks that [RFC2205] explicitly wanted, which says, "In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS". Even for the simplest single_sender/single_receiver reservations, the current receiver-driven model cuts signaling load and per-hop RSVP processing by not sending any error message to the sender on an admission control reject 🌸.
• The reason for adding sender error notification when there's an RSVP Receiver Proxy is that the actual receiver can no longer sync the RSVP reservation with application state (since it doesn't take part in RSVP signaling), but the sender can. That reason doesn't apply to a regular receiver 💅.
• There's already a ton of existing code and deployed systems happily working under the current [RFC2205] model without a proxy. The current behavior of those systems shouldn't change unless there's a really strong motivation 🥹.

3.2. Sender Notification via Notify Message 🔔

The OPTIONAL method for sender notification of reservation failure defined in this section is meant to be more efficient than the one in Section 3.1. Its goals include:

• allowing the failure notification to be sent directly upstream to the sender by the router where the failure happens (as opposed to first traveling downstream toward the Receiver Proxy and then traveling upstream from the Receiver Proxy to the sender, which is effectively what happens with the method in Section 3.1).
• allowing the failure notification to travel without hop-by-hop RSVP processing.
• ensuring that such a notification is sent only to senders that are capable and willing to process it (i.e., to synchronize reservation status with application).
• ensuring that such a notification is only sent in case the receiver is not itself capable and willing to do the synchronization with the application (i.e., because we are in the presence of a Receiver Proxy so that RSVP signaling is not visible to the receiver).

Now, these perks don't come free 😤. They cost:

• a requirement for RSVP routers and senders to support the Notify messages and procedures defined in [RFC3473].
• a requirement for senders to process Notify messages traveling upstream but conveying a downstream notification.

[RFC3473] defines (in Section 4.3, "Notify Messages") the Notify message, which is a mechanism to inform non-adjacent nodes of events related to the RSVP reservation. The Notify message differs from the error messages defined in [RFC2205] (i.e., PathErr and ResvErr messages) in that it can be "targeted" to a node other than the immediate upstream or downstream neighbor, and it's a generalized notification mechanism. Notify messages are normally generated only after a Notify Request object has been received 🧚.

This section talks about the Notify message stuff that's specific to the RSVP Receiver Proxy. For every other aspect, the Notify message works as per [RFC3473] 💜.

To get sender notification of reservation failure working in the context of this document:

• An RSVP sender that wants to be notified of reservation failure MUST include a Notify Request object (containing the sender's IP address) in the Path messages it generates.
• Upon receiving a Path message with a Notify Request object, the RSVP Receiver Proxy MUST include a Notify Request object in the Resv messages it generates. This Notify Request object MUST contain either:
  • the address that was included in the Notify Request of the received Path message, a.k.a. the sender's address. We refer to this approach as the "Direct Notify" approach, or
  • an address of the Receiver Proxy. We refer to this approach as the "Indirect Notify" approach.
• Upon receiving a downstream error notification (whether in the form of a Notify, ResvErr, or both), the RSVP Receiver Proxy:
• Bestie, the Receiver Proxy MUST generate a Notify message with upstream notification to the matching sender, if that sender put a Notify Request object in its Path messages and Indirect Notification is in use. 💅
• The Receiver Proxy SHOULD generate a Notify message with upstream notification to the matching sender, if that sender put a Notify Request object in its Path messages and Direct Notification is in use. 🫶 The reason is that the failure node might not support Notify at all, so even when the Receiver Proxy asked for Direct Notification, the sender might never get a Notify from the failure node. If the Receiver Proxy sends its own Notify, the sender hears about it faster than if it just waited on PathErr in that situation. ⏩
• In controlled environments where every node is known to support Notify, the Receiver Proxy MAY be set up to skip the upstream Notify when Direct Notification is used. The goal is to avoid duplicates, so the sender doesn't get both a Notify from the failure node and one from the Receiver Proxy. 🙈

Okay so, because of all these sender and Receiver Proxy behaviors, and the existing Notify rules, here's how it plays out: if an RSVP router notices a problem with a Resv state (like an admission control rejection after an IP reroute), it sends a Notify message carrying the downstream notification with the ResvErr error code. That Notify goes to the IP address in the Resv Notify Request object. If the Receiver Proxy set that address to the sender's address (Direct Notify), the Notify goes straight to the sender. 🦋 If the Receiver Proxy set it to one of its own addresses (Indirect Notify), the Notify goes to the Receiver Proxy, and then the Receiver Proxy makes a fresh Notify addressed to the sender. It's giving relay race. 🏃‍♀️

Here's what the Path-Triggered RSVP Receiver Proxy looks like during an admission control failure using Direct Notify. Figure 4 has the whole vibe:

 |****|        ***        ***        ***        |**********|      |----|
 | S  |--------*r*--------*r*--------*r*--------| RSVP     |------| R  |
 |****|        ***        ***        ***        | Receiver |      |----|
                                                | Proxy    |
                                                |**********|

      --Path*--> --Path*--> --Path*--> --Path*-->

                            <--Resv*-- <--Resv*--

      <------NotifyD--------

                            -ResvErr-> -ResvErr->

      <------------------NotifyU------------------

      <-PathErr- <-PathErr- <-PathErr- <-PathErr-

      ===================RSVP===================>

      ************************************************************>


 |****| RSVP-capable  |----| Non-RSVP-capable   ***
 | S  | Sender        | R  | Receiver           *r* regular RSVP
 |****|               |----|                    *** router

 ***> media flow

 ==>  segment of flow path benefiting from RSVP
      (but not benefiting from a reservation in this case)

 Path*  = Path message containing a Notify Request object
          with sender IP Address

 Resv*  = Resv message containing a Notify Request object
          with sender IP address

 NotifyD = Notify message containing a downstream notification

 NotifyU = Notify message containing an upstream notification

          Figure 4: Reservation Failure with Sender Notification
                             via Direct Notify

Next up, the same situation but with Indirect Notify, which is shown in Figure 5. Same energy, different routing. ✨

 |****|        ***        ***        ***        |**********|      |----|
 | S  |--------*r*--------*r*--------*r*--------| RSVP     |------| R  |
 |****|        ***        ***        ***        | Receiver |      |----|
                                                | Proxy    |
                                                |**********|

      --Path*--> --Path*--> --Path*--> --Path*-->

                            <--Resv*-- <--Resv*--

                            -------NotifyD------->

      <------------------NotifyU------------------

                            -ResvErr-> -ResvErr->

      <-PathErr- <-PathErr- <-PathErr- <-PathErr-

      ===================RSVP===================>

      ************************************************************>


 |****| RSVP-capable  |----| Non-RSVP-capable   ***
 | S  | Sender        | R  | Receiver           *r* regular RSVP
 |****|               |----|                    *** router

 ***> media flow

 ==>  segment of flow path benefiting from RSVP
      (but not benefiting from a reservation in this case)

 Path*  = Path message containing a Notify Request object
          with sender IP Address

 Resv*  = Resv message containing a Notify Request object
          with RSVP Receiver Proxy IP address

 NotifyD = Notify message containing a downstream notification

 NotifyU = Notify message containing an upstream notification

          Figure 5: Reservation Failure with Sender Notification
                            via Indirect Notify

Now, local failures on the Receiver Proxy node itself. 🧚 If a similar failure on an RSVP midpoint would cause a ResvErr to be generated (admission control failure is the classic example), the Receiver Proxy MUST generate a Notify toward the sender. The Receiver Proxy MAY also generate a Notify for local failures that wouldn't normally cause a ResvErr, like the ones described in Appendix B of [RFC2205]. 🌸

When sender notification happens through a Notify message, it is RECOMMENDED that the RSVP Receiver Proxy also send sender notification through a PathErr message. This gives the notification the best chance of reaching the sender in every situation, like if some RSVP routers don't support the Notify procedure or a Notify message gets dropped. 😭 That said, in controlled environments where all RSVP routers are known to support the Notify procedures, and where you want to keep signaling volume low, the RSVP Receiver Proxy MAY rely only on sender notification via Notify and skip the PathErr message entirely. 💜

Here's a tricky bit: in environments with both RSVP-capable receivers and RSVP Receiver Proxies standing in for non-RSVP-capable receivers, a sender can't tell whether a given reservation is set up with a real RSVP receiver or with a Receiver Proxy. So a sender that follows the procedures in this section might put a Notify Request object in Path messages even for a reservation controlled by an RSVP-capable receiver. This document doesn't define, or expect, any change to existing receiver behavior. So in that case the sender won't get Notify messages carrying downstream notifications. That's totally fine though, because the real receiver handles syncing the RSVP reservation state with the application's needs through the regular end-to-end RSVP model. The sender doesn't need to care about downstream notifications here. 🫶

A sender that doesn't support these procedures might still put a Notify Request object in Path messages, just because it wants upstream notifications faster. If the reservation is controlled by a Receiver Proxy that does support these procedures, that sender will also receive Notify messages carrying downstream notifications it didn't ask for. It's expected that such a sender will just drop those downstream notifications as invalid. 🙃 And since the Receiver Proxy is RECOMMENDED to also send a PathErr even when it uses a Notify, the sender still gets told about the reservation failure through the "sender notification via PathErr" method. 🎀 Summing up: turning on the OPTIONAL "sender notification via Notify" method on a Receiver Proxy doesn't stop a sender that doesn't support that method from relying on the MANDATORY "sender notification via PathErr" method. It does let a sender that supports "sender notification via Notify" take advantage of the OPTIONAL method. ✨

With Direct Notification, the downstream notification made by the RSVP router where the failure happens goes to the IP address in the Notification Request Object of the matching Resv message. 🦋 But when there are multiple senders on the same session, you can't assume each sender has its own Resv message. With WF and SE there's one single Resv message for all senders, and with FF the downstream router can choose between separate Resv messages or one combined message. 👑 So with multiple senders, Direct Notification can't guarantee that every affected sender gets notified. That's why Direct Notification is better suited to single-sender applications. 💖

With Indirect Notification, the RSVP Receiver Proxy can generate Notify messages using the same logic it uses to generate PathErr messages in the "Sender Notification via PathErr" method. Honestly, they carry the same error information. The only difference is the Notify is addressed straight to the sender, while the PathErr travels hop-by-hop. 🌈 So with multiple senders, the Indirect Notify method behaves a lot like the PathErr method from Section 3.1. With FF or SE, a Notify MUST be sent to the sender or to the set of affected senders, respectively. With WF, the RSVP Receiver Proxy SHOULD send a Notify to each sender. Which, yes, is a bit overly cautious when there are multiple senders. 🥹

4. Mechanisms for Maximizing the Reservation Span ✨

Okay bestie, this section is all about letting an RSVP reservation stretch across as much of the flow path as possible 💖. We're talking any number of RSVP Receiver Proxies on the path, and it doesn't even care whether the receiver is RSVP-capable or not 🦋. This is so much easier to deploy and run, because Path-Triggered Receiver Proxies normally come with annoying topology rules and config babysitting. You'd have to make sure there's no Receiver Proxy upstream of a given one, and no Receiver Proxy for a flow at all if the receiver already speaks RSVP 😭. Migration is also way smoother. Receivers can get upgraded one at a time and then instantly benefit from end-to-end reservations 🌈.

Section 4.1 defines a method that lets a Path-Triggered Receiver Proxy figure out whether there's another Receiver Proxy or an RSVP-capable receiver further downstream, and then extend the reservation span downstream on the fly 🧚. A router implementation claiming compliance with this document SHOULD support the method defined in Section 4.1.

Section 4.2 defines a method that lets a sender decide whether an RSVP router with the Path-Triggered Receiver Proxy function acts as a Receiver Proxy for a given flow 💅. A router implementation claiming compliance with this document MAY support the method defined in Section 4.2.

Network admins can pick the method from Section 4.1, the one from Section 4.2, or honestly even mix the two together 🍓.

---

4.1. Dynamic Discovery of Downstream RSVP Functionality

Okay, so when a Receiver Proxy generates a proxy Resv message upstream, a Receiver Proxy that supports dynamic discovery of downstream RSVP functionality MUST forward the Path message downstream instead of terminating it (unless dynamic discovery of downstream RSVP functionality is explicitly disabled) 🔥. If the destination endpoint supports RSVP (or there's another Receiver Proxy downstream), it gets the Path and generates a Resv upstream. When that Resv reaches the Receiver Proxy, the proxy realizes there's an RSVP-capable receiver (or another RSVP Receiver Proxy) downstream and MUST internally convert its state from a proxied reservation to a regular midpoint RSVP behavior. From then on, the RSVP router MUST behave as a regular RSVP router for that reservation (i.e., as if the RSVP router never behaved as an RSVP Receiver Proxy for that flow) ✨. The whole vibe is shown in Figure 6 🦋.

   |****|         ***         |**********|   |----|
   | 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 6: Dynamic Discovery of Downstream RSVP Functionality

Now, if there's no RSVP-capable receiver (or other Receiver Proxy) downstream of the Receiver Proxy, then the Path messages it sends every RSVP refresh interval (e.g., 30 seconds by default) will never get a response 😭. Those messages eat a small amount of bandwidth, and they'd also install some RSVP state on RSVP-capable midpoint nodes downstream of the first Receiver Proxy. It's a very minor sub-optimality, ngl 🙈. To fix it, the Receiver Proxy MAY tear down any unanswered downstream Path state after a predetermined time (that SHOULD be greater or equal to the Path refresh interval), and MAY stop sending Path messages for the flow (or MAY only send them at much lower frequency) 🌸.

This approach only needs the behavior from the paragraph right above, and it doesn't need any new RSVP extensions 💜.

---

4.2. Receiver Proxy Control Policy Element

Okay so [RFC2750] is the one that adds extensions for generic policy-based admission control in RSVP 💅. Those extensions bring the standard format of POLICY_DATA objects and a description of how RSVP handles policy events.

A POLICY_DATA object holds one or more policy elements, and each one represents a different (and maybe orthogonal) policy 🎀. For example, [RFC3181] specifies the preemption priority policy element.

This document defines a brand-new policy element called the Receiver Proxy Control policy element 👑. It's only defined for use in Path messages and for unicast reservations. Any other usage is outside the scope of this document 🙈.

The Receiver Proxy Control policy element looks like Figure 7 💖:

       0           0 0           1 1           2 2           3
       0  . . .    7 8   . . .   5 6    . . .  3 4  . . .    1
      +-------------+-------------+-------------+-------------+
      |     Length                | P-Type=REC_PROXY_CONTROL  |
      +-------------+-------------+-------------+-------------+
      |              Reserved                   |Control-Value|
      +---------------------------+---------------------------+

           Figure 7: Receiver Proxy Control Policy Element

Here's the breakdown 🧚:

• Length: 16 bits
  • Always 8. The overall length of the policy element, in bytes.
• P-Type: 16 bits
  • REC_PROXY_CONTROL = 0x07 (see the "IANA Considerations" section).
• Reserved: 24 bits
  • SHALL be set to zero on transmit and SHALL be ignored on reception.
• Control-Value: 8 bits (unsigned)
  • 0 (Reserved): An RSVP Receiver Proxy that understands this policy element MUST ignore the policy element if its Control-Value is set to that value.
  • 1 (Receiver-Proxy-Needed): An RSVP Receiver Proxy that understands this policy element MUST attempt to insert itself as a Receiver Proxy for that flow if the corresponding Path message contains this Control-Value. If the Receiver Proxy also supports dynamic discovery of downstream RSVP functionality as specified in Section 4.1, it MUST still send the Path message downstream and attempt to extend the reservation downstream so that the reservation can be extended to the last Receiver Proxy). An RSVP sender MAY insert the Receiver Proxy Control policy element with this Control-Value when it knows (say, by other means, such as application-level signaling) that the receiver is not RSVP-capable.
  • 2 (Receiver-Proxy-Not-Needed): An RSVP Receiver Proxy that understands this policy element MUST NOT attempt to insert itself as a Receiver Proxy for that flow if the corresponding Path message contains this Control-Value. An RSVP sender MAY insert the Receiver Proxy Control policy element with this Control-Value when it knows (say, by other means, such as application-level signaling) that the receiver is RSVP-capable.

Figure 8 shows the method based on the Receiver Proxy Control policy element, which lets a sender control whether an RSVP router with the Path-Triggered Receiver Proxy function acts as a Receiver Proxy for a given flow 🦋.

   |****|         ***         |**********|   |----|
   | S  |---------*r*---------| RSVP     |---| R1 |
   |****|         ***         | Receiver |   |----|
                              | Proxy    |
                              |          |
                              |          |            |****|
                              |          |------------| R2 |
                              |**********|            |****|

        ---Path--->  --Path--->
         (R1/N)      (R1/N)

        <--Resv---  <---Resv---

       ================RSVP===>

       **************************************>


        ---Path--->  --Path--->          ----Path---->
         (R2/NN)      (R2/NN)               (R2/NN)

        <--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

   (N)  = Path message contains a Receiver Proxy Control policy element
        whose Control-Value is set to Receiver-Proxy-Needed

   (NN) = Path message contains a Receiver Proxy Control policy element
        whose Control-Value is set to Receiver-Proxy-Not-Needed

   ***> media flow
   ==>  segment of flow path protected by RSVP reservation

               Figure 8: Receiver Proxy Control by Sender

4.2.1. Default Handling

Section 4.2 of [RFC2750] says Policy-Ignorant Nodes (PINs) use a default handling of POLICY_DATA objects so those objects can traverse PINs on their way from one Policy Enforcement Point (PEP) to another 🌈. That applies when POLICY_DATA objects carry the Receiver Proxy Control policy element from this document, so those objects can get through PINs too 💅.

Section 4.2 of [RFC2750] also defines a similar default behavior for policy-capable nodes that don't recognize a particular policy element 🫶. That covers the Receiver Proxy Control policy element specified in this document, so messages carrying it can pass through policy-capable nodes that don't support the extensions described here 💖.

5. Security Considerations 🔒✨

okay bestie, this doc extends RSVP, so all the RSVP security stuff applies too 💅 Check out [RFC2205], [RFC4230], and [SEC-GRP-KEY] for the full picture. We'll get into how to handle those concerns below 🫶

RSVP's authentication mechanisms in [RFC2747] and [RFC3097] protect message integrity hop-by-hop and provide node authentication and replay protection, so corruption and spoofing of RSVP messages get shut down 🛡️ These hop-by-hop integrity mechanisms can also protect reservations set up through an RSVP Receiver Proxy under this document. [SEC-GRP-KEY] covers key types, key provisioning methods, and how well each one fits RSVP authentication. RSVP authentication (defined in [RFC2747] and [RFC3097]) SHOULD be supported by an implementation of this document. 🔑

[SEC-GRP-KEY] also looks at IPsec mechanisms ([RFC4302], [RFC4303]) and their key provisioning methods for securing RSVP. This applies to RSVP protection when Path-Triggered RSVP Receiver Proxies are in play, as defined here ✨

Some RSVP messages go out with the IP router alert option ([RFC2113], [RFC2711]). Because of the current security concerns with that option, RSVP (and therefore the RSVP Proxy approaches in this document) is limited to controlled environments, meaning places where the risks of the IP router alert option are understood and protected against 🚧 The security aspects, common practices, and consequences of apps like RSVP using the IP router alert option are covered in depth in [RTR-ALERT] 📖

When an RSVP Receiver Proxy is used, the reservation is no longer controlled by the receiver. Instead, the Receiver Proxy controls it, using hints from the sender in the Path message, on behalf of the sender 👀 So the Receiver Proxy ought to be trusted by the end-systems to handle the reservation properly. But honestly, basic RSVP already runs on a trust model where end-systems trust RSVP nodes to do reservations correctly. So using an RSVP Receiver Proxy isn't seen as adding any big new security threat or changing the RSVP trust model. Not a big deal! 🙌

Also, there are situations where an RSVP Receiver Proxy actually reduces security risks 😤 Take a network operator who uses RSVP for resource reservation and admission control inside their network, with RSVP senders and RSVP routers on the operator's premises and lots of RSVP receivers at the operator's customers' premises. That setup is illustrated in Appendix A.1, "RSVP-Based VoD Admission Control in Broadband Aggregation Networks", of [RFC5945] 🎬 From the operator's view, the RSVP routers and senders sit in physically secured spots, so they're at lower risk of tampering. The receivers are in physically unsecured spots, so they're at higher risk. Using an RSVP Receiver Proxy boosts the security of the operator's reservation and admission control solution by completely leaving receivers out of its operation. Filters can sit at the edge of the operator network and discard any RSVP message received from end-users. That's a super simple and effective way to protect the reservation and admission control solution running inside the operator's network 💖

5.1. Security Considerations for the Sender Notification via Notify Message 📨

This document defines, in Section 3.2, an optional method that relies on the Notify message specified in [RFC3473]. The Notify message can be sent in a non-hop-by-hop fashion, which rules out the RSVP hop-by-hop integrity and authentication model 😬 The approaches and considerations for this issue in the Security Considerations section of [RFC3473] apply here. Specifically, if Notify messages go non-hop-by-hop and you want the same level of security that [RFC2747] provides, IPsec-based integrity and authentication can be used ([RFC4302] or [RFC4303]). Alternatively, sending non-hop-by-hop Notify messages can be disabled 🙅‍♀️ Finally, [SEC-GRP-KEY] discusses how group keying applies to non-hop-by-hop Notify messages 🗝️

5.2. Security Considerations for the Receiver Proxy Control Policy Element 🧾

This document also defines, in Section 4.2, the optional Receiver Proxy Control policy element. Policy elements get signaled by RSVP by being encapsulated in a Policy Data object, as defined in [RFC2750]. So, like any other policy element, the integrity of the Receiver Proxy Control policy element can be protected as discussed in Section 6 of [RFC2750] using two optional security mechanisms 🔐

The first mechanism relies on the RSVP authentication discussed above, which provides a chain of trust when all RSVP nodes are policy capable. With this mechanism, the INTEGRITY object is carried inside RSVP messages.

The second mechanism relies on the INTEGRITY object within the POLICY_DATA object to guarantee integrity between RSVP Policy Enforcement Points (PEPs) that are not RSVP neighbors. This is only useful when some RSVP nodes are Policy-Ignorant Nodes (PINs). The INTEGRITY object within the POLICY_DATA object MAY be supported by an implementation of this document 🌸

Details on computing the content of the INTEGRITY object are in Appendix B of [RFC2750]. That appendix says the Policy Decision Point (PDP), at its discretion and based on the destination PEP/PDP or other criteria, selects an Authentication Key and the hash algorithm to use. Keys used between PDPs can be distributed manually or through a standard key management protocol for secure key distribution 🔑

Now here's the tricky part 🥺 Where non-RSVP hops may exist between RSVP hops, and where RSVP-capable Policy-Ignorant Nodes (PINs) may exist between PEPs, it can be hard for the PDP to figure out who the destination PDP is for a POLICY_DATA object in some RSVP messages (like a Path message). That's because the next PEP isn't known yet when the message gets forwarded. In that case, a key shared across multiple PDPs may be used. This is conceptually similar to using a key shared across multiple RSVP neighbors, as discussed in [SEC-GRP-KEY]. We also note that this issue may not show up in some deployments where a single PDP (or a low number of PDPs) controls all the PEPs in a region, such as an administrative domain. In those cases, it may be easy for a PDP to work out the next-hop PDP even when the next-hop PEP is unknown, just by figuring out which region will be traversed next (say, based on the destination address) 🗺️✨

6. IANA Considerations 📋

6.1. RSVP Error Codes 🚨

Since, as discussed in Section 3.1.2, this document allows two error codes to be used in PathErr messages while [RFC2205] only specified their use in ResvErr messages, IANA has updated the existing entries for these two error codes in the "Error Codes and Globally-Defined Error Value Sub-Codes" registry. Each entry refers to this document, in addition to referring to [RFC2205]. Specifically, the entries for Error Code 1 and Error Code 2 read:

1 Admission Control Failure [RFC2205] [RFC5946]

2 Policy Control Failure [RFC2205] [RFC5946]

IANA has also allocated a new RSVP Error Code, "36;: Unrecoverable Receiver Proxy Error", as discussed in Section 3.1.2. This error code is allocated under the "Error Codes and Globally-Defined Error Value Sub-Codes" registry. The entry for this error code reads:

36 Unrecoverable Receiver Proxy Error [RFC5946]

The sixteen bits of the Error Value field are defined in [RFC5946] 🔢

6.2. Policy Element 🧩

This document defines, in Section 4.2, a new policy element called the Receiver Proxy Control policy element. As specified in [RFC2750], standard RSVP policy elements (P-Type values) are to be assigned by IANA under the "IETF Consensus" policy, following the policies outlined in [RFC2434] (this policy is now called "IETF Review" per [RFC5226]).

So IANA has allocated one P-Type to the Receiver Proxy Control policy element from the standard RSVP policy element range 🎀

In Section 4.2, this document defines a Control-Value field inside the Receiver Proxy Control policy element. IANA has created the "Receiver Proxy Control Policy Element (P-Type 0x07) Control-Value field" registry and allocated the following values:

• 0 : Reserved
• 1 : Receiver-Proxy-Needed
• 2 : Receiver-Proxy-Not-Needed

Following the policies outlined in [RFC5226], numbers in the range 3-127 are allocated according to the "IETF Review" policy, numbers in the range 128-240 are assigned on a "First Come First Served" basis, and numbers in the range 241-255 are reserved for "Private Use" 🌈

7. Acknowledgments 💜

This document benefited from discussions with Carol Iturralde and Anca Zamfir 🫶 Lou Berger, Adrian Farrel, and John Drake provided review and guidance, in particular on the usage of the Path_State_Removed flag and of the Notify message, both borrowed from [RFC3473]. We also thank Stephen Kent, Ken Carlberg, and Tim Polk for their valuable input and proposed enhancements. Finally, we thank Cullen Jennings, Magnus Westerlund, and Robert Sparks for stimulating the work on extensions maximizing the reservation span and facilitating migration from the Proxy model to the end-to-end RSVP model 🦋✨

8. References 📚

8.1. Normative References 📚

okay so these are the docs this spec literally can't function without, bestie 💅 the must-reads 🫶

• [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
• [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
• [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
• [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
• [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
• [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
• [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
• [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
• [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
• [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
• [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

---

8.2. Informative References 🌸

these ones are the extra reading 🧚 super helpful for the vibes, but the spec doesn't hinge on them, so no panic if you skip 'em 💜

• [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
• [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005.
• [RFC5945] Le Faucheur, F., Manner, J., Wing, D., and A. Guillou, "Resource Reservation Protocol (RSVP) Proxy Approaches", RFC 5945, October 2010.
• [RTR-ALERT] Le Faucheur, F., "IP Router Alert Considerations and Usage", Work in Progress, October 2009.
• [SEC-GRP-KEY] Behringer, M. and F. Le Faucheur, "Applicability of Keying Methods for RSVP Security", Work in Progress, June 2010.

---

Authors' Addresses ✨

meet the squad who built this 🎀 here's where to find them 💖

Francois Le Faucheur 🦋

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 💜

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/

Ashok Narayanan 🍓

Ashok Narayanan
Cisco Systems
300 Beaver Brook Road
Boxborough, MA  01719
United States
EMail: ashokn@cisco.com

Allan Guillou 🌈

Allan Guillou
SFR
40-42 Quai du Point du Jour
Boulogne-Billancourt  92659
France
EMail: allan.guillou@sfr.com

Hemant Malik 👑

Hemant Malik
Bharti Airtel, Ltd.
4th Floor, Plot No. 16
Udyog Vihar, Phase IV
Gurgaon,   122015
India
EMail: Hemant.Malik@airtel.in