diff options
Diffstat (limited to 'doc/rfc/rfc5946.txt')
| -rw-r--r-- | doc/rfc/rfc5946.txt | 1963 |
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc5946.txt b/doc/rfc/rfc5946.txt new file mode 100644 index 0000000..49809c5 --- /dev/null +++ b/doc/rfc/rfc5946.txt @@ -0,0 +1,1963 @@ + + + + + + +Internet Engineering Task Force (IETF) F. Le Faucheur +Request for Comments: 5946 Cisco +Updates: 2205 J. Manner +Category: Standards Track Aalto University +ISSN: 2070-1721 A. Narayanan + Cisco + A. Guillou + SFR + H. Malik + Airtel + October 2010 + + + Resource Reservation Protocol (RSVP) Extensions + for Path-Triggered RSVP Receiver Proxy + +Abstract + + Resource Reservation Protocol (RSVP) signaling can be used to make + end-to-end resource reservations in an IP network in order to + guarantee the Quality of Service (QoS) required by certain flows. + With conventional RSVP, both the data sender and receiver of a given + flow take part in RSVP signaling. Yet, there are many use cases + where resource reservation is required, but the receiver, the sender, + or both, is not RSVP-capable. Where the receiver is not RSVP- + capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby + performing RSVP signaling on behalf of the receiver. This allows + resource reservations to be established on the segment of the end-to- + end path from the sender to the RSVP Receiver Proxy. However, as + discussed in the companion document "RSVP Proxy Approaches", RSVP + extensions are needed to facilitate operations with an RSVP Receiver + Proxy whose signaling is triggered by receipt of RSVP Path messages + from the sender. This document specifies these extensions. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5946. + + + + +Le Faucheur, et al. Standards Track [Page 1] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + +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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, 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, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Le Faucheur, et al. Standards Track [Page 2] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + +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 + + + + + + + + + + + + + + + + + + + + + + + +Le Faucheur, et al. Standards Track [Page 3] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + +1. Introduction + + Guaranteed Quality of Service (QoS) for some applications with tight + QoS requirements may be achieved by reserving resources in each node + on the end-to-end path. The main IETF protocol for these resource + reservations is the Resource Reservation Protocol (RSVP), as + specified in [RFC2205]. RSVP does not require that all intermediate + nodes support RSVP, but it assumes that both the sender and the + receiver of the data flow support RSVP. However, there are + environments where it would be useful to be able to reserve resources + for a flow (at least a subset of the flow path) even when the sender + or the receiver (or both) is not RSVP-capable. + + Since both the data sender and receiver may be unaware of RSVP, there + are two types of RSVP Proxies. In the first case, an entity in the + network needs to invoke RSVP on behalf of the data sender and thus + generate RSVP Path messages, and eventually receive, process, and + sink Resv messages. We refer to this entity as the RSVP Sender + Proxy. In the second case, an entity in the network needs to operate + RSVP on behalf of the receiver and thus receive Path messages sent by + a data sender (or by an RSVP Sender Proxy), and reply to those with + Resv messages generated on behalf of the data receiver(s). We refer + to this entity as the RSVP Receiver Proxy. + + RSVP Proxy approaches are presented in [RFC5945]. That document also + discusses, for each approach, how the reservations controlled by the + RSVP Proxy can be synchronized with the application requirements + (e.g., when to establish, maintain, and tear down the RSVP + reservation to satisfy application requirements). + + One RSVP Proxy approach is referred to as the Path-Triggered RSVP + Receiver Proxy approach. With this approach, the RSVP Receiver Proxy + uses the RSVP Path messages generated by the sender (or RSVP Sender + Proxy) as the cue for establishing the RSVP reservation on behalf of + the non-RSVP-capable receiver(s). The RSVP Receiver Proxy is + effectively acting as an intermediary making reservations (on behalf + of the receiver) under the sender's control (or RSVP Sender Proxy's + control). This somewhat changes the usual RSVP reservation model + where reservations are normally controlled by receivers. Such a + change greatly facilitates operations in the scenario of interest + here, which is where the receiver is not RSVP-capable. Indeed it + allows the RSVP Receiver Proxy to remain application-unaware by + taking advantage of the application awareness and RSVP awareness of + the sender (or RSVP Sender Proxy). + + Since the synchronization between an RSVP reservation and an + application is now effectively performed by the sender (or RSVP + Sender Proxy), it is important that the sender (or RSVP Sender Proxy) + + + +Le Faucheur, et al. Standards Track [Page 4] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + is aware of the reservation state. However, as conventional RSVP + assumes that the reservation is to be controlled by the receiver, + some notifications about reservation state (notably the error message + sent in the case of admission control rejection of the reservation) + are only sent towards the receiver and therefore, in our case, sunk + by the RSVP Receiver Proxy. Section 3 of this document specifies + extensions to RSVP procedures allowing such notifications to be also + conveyed towards the sender. This facilitates synchronization by the + sender (or RSVP Sender Proxy) between the RSVP reservation and the + application requirements, and it facilitates sender-driven control of + reservation in scenarios involving a Path-Triggered RSVP Receiver + Proxy. + + With unicast applications in the presence of RSVP Receiver Proxies, + if the sender is notified about the state of the reservation towards + the receiver (as enabled by this document), the sender is generally + in a good position to synchronize the reservation with the + application and to perform efficient sender-driven reservation: the + sender can control the establishment or removal of the reservation + towards the receiver by sending Path or PathTear messages, + respectively. For example, if the sender is notified that the + reservation for a point-to-point audio session towards the receiver + is rejected, the sender may trigger rejection of the session at the + application layer and may issue a PathTear message to remove any + corresponding RSVP state (e.g., Path states) previously established. + + However, we note that multicast applications do not always coexist + well with RSVP Receiver Proxies, since sender notification about + reservation state towards each RSVP Receiver Proxy may not be + sufficient to achieve tight application-level synchronization by + multicast senders. These limitations stem from the fact that + multicast operation is receiver driven and, while end-to-end RSVP is + also receiver driven (precisely to deal with multicast efficiently), + the use of RSVP Receiver Proxies only allows sender-driven + reservation. For example, a sender generally is not 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. Therefore, it may not be possible to support a mode + of operation whereby a given receiver only joins a group if that + receiver benefits from a reservation. Additionally, a sender may + have no recourse if only a subset of RSVP Receiver Proxies return + successful reservations (even if application-level signaling runs + between the sender and receivers), since the sender may not be able + to correctly identify the set of receivers who do not have + reservations. However, it is possible to support a mode of operation + whereby multicast traffic is transmitted if and only if all receivers + benefit from a reservation (from sender to their respective RSVP + Receiver Proxy): the sender can ensure this by sending a PathTear + + + +Le Faucheur, et al. Standards Track [Page 5] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + message and stopping transmission whenever it gets a notification for + reservation reject for one or more RSVP Receiver Proxies. It is also + possible to support a mode of operation whereby receivers join + independently of whether or not they can benefit from a reservation + (to their respective RSVP Receiver Proxy), but do benefit from a + reservation whenever the corresponding resources are reservable on + the relevant path. + + This document discusses extensions to facilitate operations in the + presence of a Path-Triggered RSVP Receiver Proxy. As pointed out + previously, those apply equally whether RSVP signaling is initiated + by a regular RSVP sender or by an RSVP Sender Proxy (with some means + to synchronize reservation state with application-level requirements + that are outside the scope of this document). For readability, the + rest of this document discusses operations assuming a regular RSVP + sender; however, such an operation is equally applicable where an + RSVP Sender Proxy is used to initiated RSVP signaling on behalf of a + non-RSVP-capable sender. + + As discussed in [RFC5945], it is important to keep in mind 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. + Also, when compared to the end-to-end RSVP model, the use of RSVP + Proxies involves additional operational burden and/or imposes some + topological constraints. Thus, the purpose of this document is only + to allow RSVP deployment in special environments where RSVP just + cannot be used on some senders and/or some receivers for reasons + specific to the environment. + + Section 4.1.1 of [RFC5945] discusses mechanisms allowing the RSVP + reservation for a given flow to be dynamically extended downstream of + an RSVP Proxy whenever possible (i.e., when the receiver is RSVP- + capable or when there is another RSVP Receiver Proxy downstream). + This can considerably alleviate the operational burden and the + topological constraints associated with Path-Triggered RSVP Receiver + Proxies. This allows (without corresponding manual configuration) an + RSVP reservation to dynamically span as much of the corresponding + flow path as possible, with any arbitrary number of RSVP Receiver + Proxies on the flow path and whether or not the receiver is RSVP- + capable. In turn, this facilitates migration from an RSVP deployment + model based on Path-Triggered Receiver Proxies to an end-to-end RSVP + model, since receivers can gradually and independently be upgraded to + support RSVP and then instantaneously benefit from end-to-end + reservations. Section 4 of this document specifies these mechanisms + and associated RSVP extensions. + + + + +Le Faucheur, et al. Standards Track [Page 6] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + +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 + extensively in this document: + + o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per + [RFC2205]. + + o 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 the RSVP Receiver + Proxy. + + o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of + a sender, the RSVP operations that normally would 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 the RSVP Sender Proxy. + + o 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: + + o 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]. + + o 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]. + + + + + +Le Faucheur, et al. Standards Track [Page 7] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + +3. RSVP Extensions for Sender Notification + + This section defines extensions to RSVP procedures allowing sender + notification of reservation failure. This facilitates + synchronization by the sender between RSVP reservation and + application requirements in scenarios involving a Path-Triggered RSVP + Receiver Proxy. + + As discussed in [RFC5945], with the Path-Triggered RSVP Receiver + Proxy approach, the RSVP router may be configured to use receipt of a + regular RSVP Path message as the trigger for RSVP Receiver Proxy + behavior. On receipt of the RSVP Path message, the RSVP Receiver + Proxy: + + 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. + + Operation of the Path-Triggered Receiver Proxy in the case of a + successful reservation is illustrated in Figure 1. + + + + + + + + + + + + + + + + + + + + + +Le Faucheur, et al. Standards Track [Page 8] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + |****| *** *** *** |**********| |----| + | 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 + + We observe that, in the case of successful reservation, conventional + RSVP procedures ensure that the sender is notified of the successful + reservation establishment. Thus, no extensions are required in the + presence of a Path-Triggered RSVP Receiver Proxy in the case of + successful reservation establishment. + + However, in the case of reservation failure, conventional RSVP + procedures ensure only that the receiver (or the RSVP Receiver Proxy) + is notified of the reservation failure. Specifically, in the case of + an admission control rejection on a regular RSVP router, a ResvErr + message is sent downstream towards the receiver. In the presence of + an RSVP Receiver Proxy, if we simply follow conventional RSVP + procedures, this means that the RSVP Receiver Proxy is notified of + the reservation failure, but the sender is not. Operation of the + Path-Triggered RSVP Receiver Proxy in the case of an admission + control failure, assuming conventional RSVP procedures, is + illustrated in Figure 2. + + + + + + + + +Le Faucheur, et al. Standards Track [Page 9] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + |****| *** *** *** |**********| |----| + | 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 + + While the sender could infer reservation failure from the fact that + it has not received a Resv message after a certain time, there are + clear benefits to ensuring that the sender gets a prompt, explicit + notification in the case of reservation failure. This includes + faster end-user notification at the application layer (e.g., busy + signal) and faster application-level reaction (e.g., application- + level rerouting), as well as faster release of application-level + resources. + + Section 3.1 defines a method that can be used to achieve sender + notification of reservation failure. A router implementation + claiming compliance with this document MUST support the method + defined in Section 3.1. + + Section 3.2 defines another method that can be used to achieve sender + notification of reservation failure. A router implementation + claiming compliance with this document MAY support the method defined + in Section 3.2. + + + + + + +Le Faucheur, et al. Standards Track [Page 10] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + In a given network environment, a network administrator may elect to + use the method defined in Section 3.1, the method defined in + Section 3.2, or possibly combine the two. + +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). + + Note that this notion of generating a PathErr message upstream in + order to notify the sender about a reservation failure is not + completely new. It is borrowed from [RFC3209] where it was + introduced in order to satisfy a similar requirement, which is to + allow an MPLS Traffic Engineering (TE) Label Switching Router to + notify the TE Tunnel head-end (i.e., the sender) of a failure to + establish (or maintain) a TE Tunnel Label Switch Path. + + Operation of the Path-Triggered RSVP Receiver Proxy in the case of an + admission control failure, using sender notification via a PathErr + message, is illustrated in Figure 3. + + + + + + + + + + + + + + + + + + + + + + + +Le Faucheur, et al. Standards Track [Page 11] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + |****| *** *** *** |**********| |----| + | 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 role of this PathErr is to notify the sender that the reservation + was not established or was torn down. This may be in the case of + receipt of a ResvErr, or because of local failure on the Receiver + Proxy. On receipt of a ResvErr, in all situations where the + reservation cannot be installed, 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 cause the + generation of a ResvErr (for example, 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 would not ordinarily cause generation of a ResvErr + message, such as those described in Appendix B of [RFC2205]. + + The PathErr generated by the Receiver Proxy corresponds to the + sender(s) that triggered generation of Resv messages that 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 + + + +Le Faucheur, et al. Standards Track [Page 12] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + Receiver Proxy MUST send the PathErr(s) towards the set of senders + that triggered reservations that failed. This may be a subset of + senders sharing the same reservation, in which case the remaining + senders would have their reservation intact and would not receive a + PathErr. In both cases, the rules described in Section 3.1.8 of + [RFC2205] for generating flow descriptors in ResvErr messages also + apply when generating sender descriptors in PathErr messages. + + For WF-style (Wildcard-Filter) reservations, it is not always + possible for the Receiver Proxy to reliably know which sender caused + the reservation failure. Therefore, the Receiver Proxy SHOULD send a + PathErr towards each sender. This means that all the senders will + receive a notification that the reservation is not established, + including senders that did not cause the reservation failure. + Therefore, the method of sender notification via a PathErr message is + somewhat overly conservative (i.e., in some cases, rejecting + reservations from some senders when those could have actually been + established) when used in combination with the Wildcard-Filter style + (and when there is more than one sender). + + The sender notification via the PathErr method applies to both + unicast and multicast sessions. However, for a multicast session, it + is possible that reservation failure (e.g., admission control + failure) in a node close to a sender may cause ResvErr messages to be + sent to a large group of Receiver Proxies. These Receiver Proxies + would, in turn, all send PathErr messages back to the same sender, + which could cause a scalability issue in some environments. + + From the perspective of the sender, errors that prevent a reservation + from being set up can be classified in two ways: + + 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. + + 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. + + 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 + + + + + +Le Faucheur, et al. Standards Track [Page 13] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + Receiver Proxy as specified in the following subsections. The + Receiver Proxy MAY reflect back towards the sender in the PathErr any + POLICY_DATA objects received in the ResvErr. + +3.1.1. Composition of SESSION and Sender Descriptor + + The Receiver Proxy MUST insert the SESSION object corresponding to + the failed reservation into the PathErr. For FF-style reservations, + the Receiver Proxy MUST insert a sender descriptor corresponding to + the failed reservation into the PathErr. This is equal to the error + flow descriptor in the ResvErr received by the Receiver Proxy. For + SE-style reservations, the Receiver Proxy MUST insert a sender + descriptor corresponding to the sender triggering the failed + reservation into the PathErr. This is equal to the error flow + descriptor in the ResvErr received by the Receiver Proxy. If + multiple flow descriptors could not be admitted at a midpoint node, + that node would generate multiple ResvErr messages towards the + receiver as per Section 3.1.8 of [RFC2205]. Each ResvErr would + contain an error flow descriptor that matches a specific sender. The + Receiver Proxy MUST generate a PathErr for each ResvErr received + towards the corresponding sender. As specified 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 to be inserted into + the PathErr as follows: + + 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 the Receiver Proxy 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 + + + +Le Faucheur, et al. Standards Track [Page 14] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + not cause generation of a ResvErr. In some cases, it may be + predetermined that the PathErr will not reach 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. Nevertheless, 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 + + where the bits are: + + * 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 whereby a node forwarding a + PathErr message can remove the Path state associated with the PathErr + message and indicate so by including the Path_State_Removed flag in + the ERROR_SPEC object of the PathErr message. This can be used in + some situations to expedite release of resources and minimize + signaling load. + + This section discusses aspects of the use of the Path_State_Removed + flag that are specific to the RSVP Receiver Proxy. In any other + aspects, the Path_State_Removed flag operates as per [RFC3473]. + + + + + + +Le Faucheur, et al. Standards Track [Page 15] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + By default, the RSVP Receiver Proxy MUST NOT include the + Path_State_Removed flag in the ERROR_SPEC of the PathErr message. + This ensures predictable operations in all environments including + those where some RSVP routers do not understand the + Path_State_Removed flag. + + The RSVP Receiver Proxy MAY support an OPTIONAL mode (to be activated + by configuration) whereby the RSVP Receiver Proxy includes the + Path_State_Removed flag in the ERROR_SPEC of the PathErr message and + removes its local Path state. When all routers on the path of a + reservation support the Path_State_Removed flag, its use will indeed + result in expedited resource release and reduced signaling. However, + if there are one or more RSVP routers on the path of the reservation + that do not support the Path_State_Removed flag (we refer to such + routers as "old RSVP routers"), the use of the Path_State_Removed + flag will actually result in slower resource release and increased + signaling. This is because the Path_State_Removed flag will be + propagated upstream by an old RSVP router (even if it does not + understand it and does not tear its Path state). Thus, the sender + will not send a Path Tear, and the old RSVP router will release its + Path state only through refresh time-out. A network administrator + needs to keep these considerations in mind when deciding whether to + activate the use of the Path_State_Removed flag on the RSVP Receiver + Proxy. In a controlled environment where all routers are known to + support the Path_State_Removed flag, its use can be safely activated + on the RSVP Receiver Proxy. In other environments, the network + administrator needs to assess whether the improvement achieved with + some reservations outweighs the degradation experienced by other + reservations. + +3.1.4. Use of PathErr by Regular Receivers + + Note that while this document specifies that an RSVP Receiver Proxy + generates a PathErr upstream in the case of reservation failure, this + document does NOT propose that the same be done by regular receivers. + In other words, this document does NOT propose modifying the behavior + of regular receivers as currently specified in [RFC2205]. The + rationale for this includes the following: + + o When the receiver is RSVP-capable, the current receiver-driven + model of [RFC2205] is fully applicable because the receiver can + synchronize RSVP reservation state and application state (since it + participates in both). The sender(s) need not be aware of the + RSVP reservation state. Thus, we can retain the benefits of + receiver-driven operations that were explicitly sought by + [RFC2205], which states, "In order to efficiently accommodate + large groups, dynamic group membership, and heterogeneous receiver + requirements, RSVP makes receivers responsible for requesting a + + + +Le Faucheur, et al. Standards Track [Page 16] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + specific QoS". But even for the simplest single_sender/ + single_receiver reservations, the current receiver-driven model + reduces signaling load and per-hop RSVP processing by not sending + any error message to the sender in case of admission control + reject. + + o The motivation for adding sender error notification in the case of + an RSVP Receiver Proxy lies in the fact that the actual receiver + can no longer synchronize the RSVP reservation with application + state (since the receiver does not participate in RSVP signaling), + while the sender can. This motivation does not apply in the case + of a regular receiver. + + o There is a lot of existing code and deployed systems successfully + working under the current [RFC2205] model in the absence of proxy + today. The current behavior of existing deployed systems should + not be changed unless there were a very strong motivation. + +3.2. Sender Notification via Notify Message + + The OPTIONAL method for sender notification of reservation failure + defined in this section aims to provide a more efficient method than + the one defined in Section 3.1. Its objectives include: + + o allowing the failure notification to be sent directly upstream to + the sender by the router where the failure occurs (as opposed to + first traveling downstream towards the Receiver Proxy and then + traveling upstream from the Receiver Proxy to the sender, as + effectively happens with the method defined in Section 3.1). + + o allowing the failure notification to travel without hop-by-hop + RSVP processing. + + o ensuring that such a notification is sent to senders that are + capable and willing to process it (i.e., to synchronize + reservation status with application). + + o 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). + + Note, however, that such benefits come at the cost of: + + o a requirement for RSVP routers and senders to support the Notify + messages and procedures defined in [RFC3473]. + + + + +Le Faucheur, et al. Standards Track [Page 17] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + o 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 that provides 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 that it is a + generalized notification mechanism. Notify messages are normally + generated only after a Notify Request object has been received. + + This section discusses aspects of the use of the Notify message that + are specific to the RSVP Receiver Proxy. In any other aspects, the + Notify message operates as per [RFC3473]. + + In order to achieve sender notification of reservation failure in the + context of this document: + + o An RSVP sender interested in being notified of reservation failure + MUST include a Notify Request object (containing the sender's IP + address) in the Path messages it generates. + + o 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. + + o Upon receiving a downstream error notification (whether in the + form of a Notify, ResvErr, or both), the RSVP Receiver Proxy: + + * MUST generate a Notify message with upstream notification to + the corresponding sender, if the sender included a Notify + Request object in its Path messages and if Indirect + Notification is used. + + * SHOULD generate a Notify message with upstream notification to + the corresponding sender, if the sender included a Notify + Request object in its Path messages and if Direct Notification + is used. The reason for this recommendation is that the + failure node may not support Notify, so that even if Direct + + + +Le Faucheur, et al. Standards Track [Page 18] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + Notification was requested by the RSVP Receiver Proxy, the + sender may not actually have received a Notify from the failure + node: generating a Notify from the Receiver Proxy will + accelerate sender notification, as compared to simply relying + on PathErr, in this situation. In controlled environments + where all the nodes are known to support Notify, the Receiver + Proxy MAY be configured to not generate the Notify with + upstream notification when Direct Notification is used, in + order to avoid duplication of Notify messages (i.e., the sender + receiving both a Notify from the failure node and from the + Receiver Proxy). + + As a result of these sender and Receiver Proxy behaviors, as per + existing Notify procedures, if an RSVP router detects an error + relating to a Resv state (e.g., admission control rejection after IP + reroute), the RSVP router will send a Notify message (conveying the + downstream notification with the ResvErr error code) to the IP + address contained in the Resv Notify Request object. If this address + has been set by the RSVP Receiver Proxy to the sender's address + (Direct Notify), the Notify message is sent directly to the sender. + If this address has been set by the RSVP Receiver Proxy to one of its + own addresses (Indirect Notify), the Notify message is sent to the + RSVP Receiver Proxy that, in turn, will generate a Notify message + directly addressed to the sender. + + Operation of the Path-Triggered RSVP Receiver Proxy in the case of an + admission control failure, using sender notification via Direct + Notify, is illustrated in Figure 4. + + + + + + + + + + + + + + + + + + + + + + + +Le Faucheur, et al. Standards Track [Page 19] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + |****| *** *** *** |**********| |----| + | 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 + + Operation of the Path-Triggered RSVP Receiver Proxy in the case of an + admission control failure, using sender notification via Indirect + Notify, is illustrated in Figure 5. + + + +Le Faucheur, et al. Standards Track [Page 20] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + |****| *** *** *** |**********| |----| + | 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 + + For local failures on the Receiver Proxy node, if a similar failure + on an RSVP midpoint would cause the generation of a ResvErr (for + example, admission control failure), the Receiver Proxy MUST generate + + + +Le Faucheur, et al. Standards Track [Page 21] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + a Notify towards the sender. The Receiver Proxy MAY additionally + generate a Notify upon local failures that would not ordinarily cause + generation of a ResvErr message, such as those described in + Appendix B of [RFC2205]. + + When the method of sender notification via a Notify message is used, + it is RECOMMENDED that the RSVP Receiver Proxy also issue a sender + notification via a PathErr message. This maximizes the chances that + the notification will reach the sender in all situations (e.g., even + if some RSVP routers do not support the Notify procedure, or if a + Notify message gets dropped). However, for controlled environments + (e.g., where all RSVP routers are known to support Notify procedures) + and where it is desirable to minimize the volume of signaling, the + RSVP Receiver Proxy MAY rely exclusively on sender notification via a + Notify message and thus not issue sender notification via a PathErr + message. + + In environments where there are both RSVP-capable receivers and RSVP + Receiver Proxies acting on behalf of non-RSVP-capable receivers, a + sender does not know whether a given reservation is established with + an RSVP-capable receiver or with an RSVP Receiver Proxy. Thus, a + sender that supports the procedures defined in this section may + include a Notify Request object in Path messages for a reservation + that happens to be controlled by an RSVP-capable receiver. This + document does not define, nor expect, any change in existing receiver + behavior. As a result, in this case, the sender will not receive + Notify messages conveying downstream notifications. However, this is + perfectly fine because the synchronization between the RSVP + reservation state and the application requirement can be performed by + the actual receiver in this case as per the regular end-to-end RSVP + model, so that in this case, the sender need not care about + downstream notifications. + + A sender that does not support the procedures defined in this section + might include a Notify Request object in Path messages for a + reservation simply because it is interested in getting upstream + notifications faster. If the reservation is controlled by an RSVP + Receiver Proxy supporting the procedures defined in this section, the + sender will also receive unexpected Notify messages containing + downstream notifications. It is expected that such a sender will + simply naturally drop such downstream notifications as invalid. + Because it is RECOMMENDED above that the RSVP Receiver Proxy also + issue a sender notification via a PathErr message even when sender + notification is effected via a Notify message, the sender will still + be notified of a reservation failure in accordance with the "sender + notification via PathErr" method. In summary, activating the + OPTIONAL "sender notification via Notify" method on a Receiver Proxy + does not prevent a sender that does not support this method from + + + +Le Faucheur, et al. Standards Track [Page 22] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + relying on the MANDATORY "sender notification via PathErr" method. + It would, however, allow a sender supporting the "sender notification + via Notify" method to take advantage of this OPTIONAL method. + + With Direct Notification, the downstream notification generated by + the RSVP router where the failure occurs is sent to the IP address + contained in the Notification Request Object of the corresponding + Resv message. In the presence of multiple senders towards the same + session, it cannot be generally assumed that a separate Resv message + is used for each sender (in fact, with WF and SE there is a single + Resv message for all senders, and with FF the downstream router has + the choice of generating separate Resv messages or a single one). + Hence, in the presence of multiple senders, Direct Notification + cannot guarantee notification of all affected senders. Therefore, + Direct Notification is better suited to single-sender applications. + + With Indirect Notification, the RSVP Receiver Proxy can generate + Notify messages with the same logic that is used to generate PathErr + messages in the "Sender Notification via PathErr" method (in fact, + those are conveying the same error information, only the Notify is + directly addressed to the sender while the PathErr travels hop-by- + hop). Therefore, operations of the Indirect Notify method in the + presence of multiple senders is similar to that of the PathErr method + as discussed in Section 3.1: with FF or SE, a Notify MUST be sent to + the sender or the set of affected senders, respectively. With WF, + the RSVP Receiver Proxy SHOULD send a Notify to each sender, again + resulting in a somewhat overly conservative behavior in the presence + of multiple senders. + +4. Mechanisms for Maximizing the Reservation Span + + This section defines extensions to RSVP procedures allowing an RSVP + reservation to span as much of the flow path as possible, with any + arbitrary number of RSVP Receiver Proxies on the flow path and + whether or not the receiver is RSVP-capable. This facilitates + deployment and operations of Path-Triggered RSVP Receiver Proxies + since it alleviates the topological constraints and/or configuration + load otherwise associated with Receiver Proxies (e.g., make sure + there is no RSVP Receiver Proxy for a flow upstream of a given + Receiver Proxy, ensure there is no Receiver Proxy for a flow if the + receiver is RSVP-capable). This also facilitates migration from an + RSVP deployment model based on Path-Triggered Receiver Proxies to an + end-to-end RSVP model, since receivers can gradually and + independently be upgraded to support RSVP and then instantaneously + benefit from end-to-end reservations. + + + + + + +Le Faucheur, et al. Standards Track [Page 23] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + Section 4.1 defines a method that allows a Path-Triggered Receiver + Proxy function to discover whether there is another Receiver Proxy or + an RSVP-capable receiver downstream and then dynamically extend the + span of the RSVP reservation downstream. A router implementation + claiming compliance with this document SHOULD support the method + defined in Section 4.1. + + Section 4.2 defines a method that allows a sender to control whether + or not an RSVP router supporting the Path-Triggered Receiver Proxy + function is to behave 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. + + In a given network environment, a network administrator may elect to + use the method defined in Section 4.1, or the method defined in + Section 4.2, or possibly combine the two. + +4.1. Dynamic Discovery of Downstream RSVP Functionality + + When generating a proxy Resv message upstream, a Receiver Proxy + supporting 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 is + another Receiver Proxy downstream), it will receive the Path and + generate a Resv upstream. When this Resv message reaches the + Receiver Proxy, it recognizes the presence of an RSVP-capable + receiver (or of 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). This + method is illustrated in Figure 6. + + + + + + + + + + + + + + + + + + +Le Faucheur, et al. Standards Track [Page 24] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + |****| *** |**********| |----| + | 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 + + + + + + +Le Faucheur, et al. Standards Track [Page 25] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + If there is no RSVP-capable receiver (or other Receiver Proxy) + downstream of the Receiver Proxy, then the Path messages sent by the + Receiver Proxy every RSVP refresh interval (e.g., 30 seconds by + default) will never be responded to. However, these messages consume + a small amount of bandwidth, and in addition would install some RSVP + state on RSVP-capable midpoint nodes downstream of the first Receiver + Proxy. This is seen as a very minor sub-optimality; however, to + mitigate this, 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 requires support of the behavior described in the + previous paragraph and does not require any new RSVP extensions. + +4.2. Receiver Proxy Control Policy Element + + [RFC2750] defines extensions for supporting generic policy-based + admission control in RSVP. These extensions include the standard + format of POLICY_DATA objects and a description of RSVP handling of + policy events. + + The POLICY_DATA object contains one or more policy elements, each + representing a different (and perhaps orthogonal) policy. As an + example, [RFC3181] specifies the preemption priority policy element. + + This document defines a new policy element called the Receiver Proxy + Control policy element. This document only defines the use of this + policy element in Path messages and for unicast reservations. Other + usage is outside the scope of this document. + + The format of the Receiver Proxy Control policy element is as shown + in 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 + + + + + + + +Le Faucheur, et al. Standards Track [Page 26] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + where: + + o Length: 16 bits + + * Always 8. The overall length of the policy element, in bytes. + + o P-Type: 16 bits + + * REC_PROXY_CONTROL = 0x07 (see the "IANA Considerations" + section). + + o Reserved: 24 bits + + * SHALL be set to zero on transmit and SHALL be ignored on + reception. + + o 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 illustrates the method based on the Receiver Proxy Control + policy element that allows a sender to control whether or not an RSVP + router supporting the Path-Triggered Receiver Proxy function is to + behave as a Receiver Proxy for a given flow. + + + + +Le Faucheur, et al. Standards Track [Page 27] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + |****| *** |**********| |----| + | 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 + + + +Le Faucheur, et al. Standards Track [Page 28] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + +4.2.1. Default Handling + + As specified in Section 4.2 of [RFC2750], Policy-Ignorant Nodes + (PINs) implement a default handling of POLICY_DATA objects ensuring + that those objects can traverse PINs in transit from one Policy + Enforcement Point (PEP) to another. This applies to the situations + in which POLICY_DATA objects contain the Receiver Proxy Control + policy element specified in this document, so that those objects can + traverse PINs. + + Section 4.2 of [RFC2750] also defines a similar default behavior for + policy-capable nodes that do not recognize a particular policy + element. This applies to the Receiver Proxy Control policy element + specified in this document, so that messages carrying the element can + traverse policy-capable nodes that do not support the extensions + described in this document. + +5. Security Considerations + + As this document defines extensions to RSVP, the security + considerations of RSVP apply, which are discussed in [RFC2205], + [RFC4230], and [SEC-GRP-KEY]. Approaches for addressing those + concerns are discussed further below. + + The RSVP authentication mechanisms defined in [RFC2747] and [RFC3097] + protect RSVP message integrity hop-by-hop and provide node + authentication as well as replay protection, thereby protecting + against corruption and spoofing of RSVP messages. These hop-by-hop + integrity mechanisms can be used to protect RSVP reservations + established using an RSVP Receiver Proxy in accordance with this + document. [SEC-GRP-KEY] discusses key types and key provisioning + methods as well as their respective applicability to RSVP + authentication. RSVP authentication (defined in [RFC2747] and + [RFC3097]) SHOULD be supported by an implementation of this document. + + [SEC-GRP-KEY] also discusses applicability of IPsec mechanisms + ([RFC4302], [RFC4303]) and associated key provisioning methods for + security protection of RSVP. This discussion applies to the + protection of RSVP in the presence of Path-Triggered RSVP Receiver + Proxies as defined in this document. + + A subset of RSVP messages are signaled with the IP router alert + option ([RFC2113], [RFC2711]). Based on the current security + concerns associated with the use of the IP router alert option, the + applicability of RSVP (and therefore of the RSVP Proxy approaches + discussed in this document) is limited to controlled environments + + + + + +Le Faucheur, et al. Standards Track [Page 29] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + (i.e., where the security risks associated with the use of the IP + router alert option are understood and protected against). The + security aspects and common practices around the use of the current + IP router alert option, and consequences of using the IP router alert + option by applications such as RSVP, are discussed in detail in + [RTR-ALERT]. + + When an RSVP Receiver Proxy is used, the RSVP reservation is no + longer controlled by the receiver, but rather is controlled by the + Receiver Proxy (using hints received from the sender in the Path + message) on behalf of the sender. Thus, the Receiver Proxy ought to + be trusted by the end-systems to control the RSVP reservation + appropriately. However, basic RSVP operation already assumes a trust + model where end-systems trust RSVP nodes to appropriately perform + RSVP reservations. So the use of an RSVP Receiver Proxy is not seen + as introducing any significant additional security threat or as + modifying the RSVP trust model. + + In fact, there are situations in which the use of an RSVP Receiver + Proxy reduces the security risks. One example is where a network + operator relies on RSVP to perform resource reservation and admission + control within a network and where RSVP senders and RSVP routers are + located in the operator's premises, while the many RSVP receivers are + located in the operator's customers' premises. Such an environment + is further illustrated in Appendix A.1, "RSVP-Based VoD Admission + Control in Broadband Aggregation Networks", of [RFC5945]. From the + operator's perspective, the RSVP routers and RSVP senders are in + physically secured locations and therefore exposed to a lower risk of + being tampered with, while the receivers are in locations that are + physically unsecured and therefore subject to a higher risk of being + tampered with. The use of an RSVP Receiver Proxy function + effectively increases the security of the operator's reservation and + admission control solution by completely excluding receivers from its + operation. Filters can be placed at the edge of the operator + network, discarding any RSVP message received from end-users. This + provides a very simple and effective protection of the RSVP + reservation and admission control solution operating 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 relying on + the use of the Notify message specified in [RFC3473]. The Notify + message can be sent in a non-hop-by-hop fashion that precludes the + use of the RSVP hop-by-hop integrity and authentication model. The + approaches and considerations for addressing this issue presented in + the Security Considerations section of [RFC3473] apply. In + + + +Le Faucheur, et al. Standards Track [Page 30] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + particular, where the Notify messages are transmitted non-hop-by-hop + and the same level of security provided by [RFC2747] is desired, + IPsec-based integrity and authentication can be used ([RFC4302] or + [RFC4303]). Alternatively, the sending of non-hop-by-hop Notify + messages can be disabled. Finally, [SEC-GRP-KEY] discusses the + applicability of group keying for 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 are signaled by RSVP + through encapsulation in a Policy Data object as defined in + [RFC2750]. Therefore, like any other policy elements, the integrity + of the Receiver Proxy Control policy element can be protected as + discussed in Section 6 of [RFC2750] by two optional security + mechanisms. + + The first mechanism relies on the RSVP authentication discussed above + that 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 + useful only 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 for the computation of the content of the INTEGRITY object + can be found in Appendix B of [RFC2750]. This states that the Policy + Decision Point (PDP), at its discretion, and based on destination + PEP/PDP or other criteria, selects an Authentication Key and the hash + algorithm to be used. Keys to be used between PDPs can be + distributed manually or via a standard key management protocol for + secure key distribution. + + Note that where non-RSVP hops may exist in between RSVP hops, as well + as where RSVP-capable Policy-Ignorant Nodes (PINs) may exist in + between PEPs, it may be difficult for the PDP to determine what the + destination PDP is for a POLICY_DATA object contained in some RSVP + messages (such as a Path message). This is because in those cases, + the next PEP is not known at the time of forwarding the message. In + this situation, a key shared across multiple PDPs may be used. This + is conceptually similar to the use of a key shared across multiple + RSVP neighbors, as discussed in [SEC-GRP-KEY]. We also observe that + this issue may not exist in some deployment scenarios where a single + + + +Le Faucheur, et al. Standards Track [Page 31] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + PDP (or a low number of PDPs) is used to control all the PEPs of a + region (such as an administrative domain). In such scenarios, it may + be easy for a PDP to determine what the next-hop PDP is, even when + the next-hop PEP is not known, simply by determining what the next + region is that will be traversed (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 under 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 entry 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 has been 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 as per "IETF Consensus" policy following the + policies outlined in [RFC2434] (this policy is now called "IETF + Review" as per [RFC5226]). + + Thus, IANA has allocated one P-Type to the Receiver Proxy Control + policy element from the standard RSVP policy element range. + + + + + + + +Le Faucheur, et al. Standards Track [Page 32] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + 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: + + o 0 : Reserved + + o 1 : Receiver-Proxy-Needed + + o 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 + + [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. + + + + +Le Faucheur, et al. Standards Track [Page 33] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + [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 + + [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. + + + + + +Le Faucheur, et al. Standards Track [Page 34] + +RFC 5946 RSVP Receiver Proxy Extensions October 2010 + + + [SEC-GRP-KEY] Behringer, M. and F. Le Faucheur, "Applicability of + Keying Methods for RSVP Security", Work in Progress, + June 2010. + +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/ + + Ashok Narayanan + Cisco Systems + 300 Beaver Brook Road + Boxborough, MA 01719 + United States + EMail: ashokn@cisco.com + + + Allan Guillou + SFR + 40-42 Quai du Point du Jour + Boulogne-Billancourt 92659 + France + EMail: allan.guillou@sfr.com + + + Hemant Malik + Bharti Airtel, Ltd. + 4th Floor, Plot No. 16 + Udyog Vihar, Phase IV + Gurgaon, 122015 + India + EMail: Hemant.Malik@airtel.in + + + + +Le Faucheur, et al. Standards Track [Page 35] + |