TSVWG F. Le Faucheur Internet-Draft Cisco Intended status: Standards Track J. Manner Expires: January 2, 2009 University of Helsinki A. Narayanan Cisco A. Guillou H. Malik Neuf July 1, 2008 RSVP Extensions for Path-Triggered RSVP Receiver Proxy draft-ietf-tsvwg-rsvp-proxy-proto-07.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 2, 2009. Le Faucheur, et al. Expires January 2, 2009 [Page 1] Internet-Draft RSVP Receiver Proxy Extensions July 2008 Abstract RSVP signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the 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 presenting 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. Le Faucheur, et al. Expires January 2, 2009 [Page 2] Internet-Draft RSVP Receiver Proxy Extensions July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. RSVP Extensions for Sender Notification . . . . . . . . . . . 7 3.1. Sender Notification via PathErr Message . . . . . . . . . 10 3.1.1. Composition of SESSION and . . . . 12 3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 13 3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 14 3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 15 3.2. Sender Notification via Notify Message . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 7.2. Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Le Faucheur, et al. Expires January 2, 2009 [Page 3] Internet-Draft RSVP Receiver Proxy Extensions July 2008 1. Introduction Guaranteed 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 RSVP 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 operate 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 need 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 [I-D.ietf-tsvwg-rsvp-proxy-approaches]. That document also discusses, for each approach, how the reservations controlled by the RSVP Proxy can be synchronised 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. 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 changes somewhat 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 synchronisation between RSVP reservation and application requirement 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. Expires January 2, 2009 [Page 4] Internet-Draft RSVP Receiver Proxy Extensions July 2008 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 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. This document specifies extension to RSVP procedures allowing such notifications to be also conveyed towards the sender. This facilitates synchronization by the sender (or RSVP Sender Proxy) between RSVP reservation and application requirements in scenarios involving a Path-Triggered RSVP receiver Proxy. This document discusses extension to facilitate operations in the presence of a Path-triggered RSVP Receiver Proxy. As explicitly pointed out in the text above, 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 operation assuming a regular RSVP sender; however, such operation is equally applicable where an RSVP Sender Proxy is used to initiated RSVP signaling on behalf of a non-RSVP-capable sender. 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]. Le Faucheur, et al. Expires January 2, 2009 [Page 5] Internet-Draft RSVP Receiver Proxy Extensions July 2008 2. Terminology The following terminology is borrowed from [I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the present 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 which would normally be performed by an RSVP-capable receiver if end-to-end RSVP signaling was 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 which would normally be performed by an RSVP-capable sender if end-to-end RSVP signaling was 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 which is not behaving as a RSVP Receiver Proxy nor as a RSVP Sender Proxy. Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, 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 the present 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. Expires January 2, 2009 [Page 6] Internet-Draft RSVP Receiver Proxy Extensions July 2008 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 [I-D.ietf-tsvwg-rsvp-proxy-approaches], 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 Resv message (whose details are discussed below) was received on the downstream interface. This includes performing admission control on the downstream interface, establishing a Resv state (in 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. Expires January 2, 2009 [Page 7] Internet-Draft RSVP Receiver Proxy Extensions July 2008 |----| *** *** *** |----------| |----| | 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 protected by 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 case of reservation failure, conventional RSVP procedures only ensure that the receiver (or the RSVP Receiver Proxy) is notified of the reservation failure. Specifically, in 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. Expires January 2, 2009 [Page 8] Internet-Draft RSVP Receiver Proxy Extensions July 2008 |----| *** *** *** |----------| |----| | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | |----| *** *** *** | Receiver | |----| | Proxy | |----------| --Path---> --Path---> --Path---> --Path---> <---Resv-- <---Resv-- -ResvErr-> -ResvErr-> ===================RSVP===================> ************************************************************> |----| |----| *** | S | Sender | R | Receiver *r* regular RSVP |----| |----| *** router ***> media flow ==> segment of flow path protected by 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 in ensuring that the sender gets a prompt explicit notification in case of reservation failure. This includes faster end-user notification at application layer (e.g. busy signal), faster application level reaction (e.g. application level rerouting), as well as faster release of application-level resources. Section 3.1 defines a method which 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 which 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. In a given network environment, a network administrator may elect to use the method defined in Section 3.1, or the method defined in Le Faucheur, et al. Expires January 2, 2009 [Page 9] Internet-Draft RSVP Receiver Proxy Extensions July 2008 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 has been introduced in order to achieve a similar requirement, which is to allow an MPLS TE Label Switch 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 PathErr Message, is illustrated in Figure 3. Le Faucheur, et al. Expires January 2, 2009 [Page 10] Internet-Draft RSVP Receiver Proxy Extensions July 2008 |----| *** *** *** |----------| |----| | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | |----| *** *** *** | Receiver | |----| | Proxy | |----------| --Path---> --Path---> --Path---> --Path---> <---Resv-- <---Resv-- -ResvErr-> -ResvErr-> <-PathErr- <-PathErr- <-PathErr- <-PathErr- ===================RSVP===================> ************************************************************> |----| |----| *** | S | Sender | R | Receiver *r* regular RSVP |----| |----| *** router ***> media flow ==> segment of flow path to be protected by RSVP reservation (but not protected in this case since reservation failed) 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, CAC failure), the Receiver Proxy MUST generate a PathErr towards the sender. The Receiver Proxy MAY additionally generate a PathErr upon local failures which would not ordinarily cause generation of a ResvErr message, such as described in Appendix B of [RFC2205]. The PathErr generated by the Receiver Proxy corresponds to the sender(s) which triggered generation of Resv messages that failed. For Fixed-Filter (FF) style reservations, the Receiver Proxy sends a PathErr towards the (single) sender matching the failed reservation. Le Faucheur, et al. Expires January 2, 2009 [Page 11] Internet-Draft RSVP Receiver Proxy Extensions July 2008 For Shared-Explicit (SE) style reservations, the Receiver Proxy sends the PathErr(s) towards the set of senders which 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 for generating sender descriptors in PathErr messages. For Wildcard-Filter (WF) style reservations, it is not possible for the receiver to know which sender caused the reservation failure. Therefore, the procedures described in this section do not apply to WF-style reservations. The procedures described in this section apply 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 receivers. These receivers 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 which the sender can attempt to correct. The error code for those errors should explicitly be communicated back to the sender. An examples of this is "Class 1: Admission Control Failure", because the sender could potentially resend a Path with smaller traffic parameters. 2. Errors which the sender has no control over. For these errors, it is sufficient to notify the sender that the reservation was not set up successfully. An example of this is "Class 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 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 The Receiver Proxy MUST insert the SESSION object corresponding to the failed reservation, into the PathErr. For Fixed-Filter (FF) style reservations, the Receiver Proxy MUST insert a corresponding to the failed reservation, into the PathErr. This is equal to the in the ResvErr received by the Receiver Proxy. For Shared-Explicit (SE) style reservations, the Receiver Proxy MUST insert a corresponding to the sender triggering the failed reservation, into the PathErr. This is equal to the in the ResvErr received by the Receiver Proxy. If multiple 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 a that matches a specific sender. The Receiver Proxy MUST generate a PathErr for each ResvErr received, towards the corresponding 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 any 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 other than the ones listed in 1 above, it composes a new ERROR_SPEC with error code ": Unrecoverable Receiver Proxy Error". 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 any error code except than those listed in 1 above, or if the Receiver Proxy generates a PathErr for a local error which ordinarily would 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 which could not process the Resv. Nevertheless, the procedures above MUST be followed. For the error code ": Unrecoverable Receiver Proxy Error", the 16 bits of the Error Value field are: Le Faucheur, et al. Expires January 2, 2009 [Page 13] Internet-Draft RSVP Receiver Proxy Extensions July 2008 * 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 of 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 minimise 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]. 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. Where all routers on the path of a reservation support the Path_State_Removed flag, its use will indeed Le Faucheur, et al. Expires January 2, 2009 [Page 14] Internet-Draft RSVP Receiver Proxy Extensions July 2008 result in expedited resource release and reduced signaling. However, if there is one (or more) RSVP router on the path of the reservation that does not support the Path_State_Removed flag (we refer to such a router as an "old RSVP router"), 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 only release its Path state 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 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 to modify 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 synchronise RSVP reservation state and application state (since it participates in both). The sender(s) needs not be aware of the RSVP reservation state. Thus, we can retain the benefits of receiver-driven operations which were explicitly sought by [RFC2205]. Quoting from it: " In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS". But even for the most simple 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 CAC reject. o the motivation for adding sender error notification in case of receiver proxy lies in the fact that the actual receiver can no longer synchronize RSVP reservation with application state (since the receiver does not participate in RSVP signaling), while the sender can. This motivation does not apply in case of regular receiver. Le Faucheur, et al. Expires January 2, 2009 [Page 15] Internet-Draft RSVP Receiver Proxy Extensions July 2008 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 should not be changed for those 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 at providing a more efficient method than the one defined in Section 3.1. Its objectives include : o allow the failure notification to be sent directly upstream to the sender by the router where the failure occurs (as opposed to first travelling downstream towards the Receiver Proxy and then travelling upstream from the Receiver Proxy to the sender, as effectively happens with the method defined in Section 3.1) o allow the failure notification to travel directly to the sender without hop-by-hop RSVP processing o ensure that such a notification is sent to senders which are capable and willing to process it (i.e. to synchronize reservation status with application) o ensure that such a notification is only sent in case the receiver is not itself capable and willing to do the synchronisation 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] 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 Le Faucheur, et al. Expires January 2, 2009 [Page 16] Internet-Draft RSVP Receiver Proxy Extensions July 2008 Notify message operates as per [RFC3473]. In order to achieve sender notification of reservation failure in the context of the present 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 the address that was included in the Notify Request of the received Path message- a.k.a. the sender's address- and not an address of the Receiver Proxy. As a result, 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 Resv Err code) to the IP address contained in the Resv Notify Request object. Since this address has been set to the sender's address by the Receiver Proxy, the Notify message is sent to the sender. Operation of the Path-Triggered RSVP Receiver Proxy in the case of an admission control failure, using sender notification via Notify Message, is illustrated in Figure 4. Le Faucheur, et al. Expires January 2, 2009 [Page 17] Internet-Draft RSVP Receiver Proxy Extensions July 2008 |----| *** *** *** |----------| |----| | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | |----| *** *** *** | Receiver | |----| | Proxy | |----------| --Path*--> --Path*--> --Path*--> --Path*--> <--Resv*-- <--Resv*-- <------Notify------- -ResvErr-> -ResvErr-> ===================RSVP===================> ************************************************************> |----| |----| *** | S | Sender | R | Receiver *r* regular RSVP |----| |----| *** router ***> media flow ==> segment of flow path to be protected by RSVP reservation (but not protected in this case since reservation failed) Path* = Path message containing a Notify Request object with sender IP Address Resv* = Resv message containing a Notify Request object with sender IP address Notify = Notify message Figure 4: Reservation Failure With Sender Notification via 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, CAC failure), the Receiver Proxy MUST generate a Notify towards the sender. The Receiver Proxy MAY additionally generate a Notify upon local failures which would not ordinarily cause generation of a ResvErr message, such as described in Appendix B of [RFC2205]. When the method of sender notification via Notify message is used, it is RECOMMENDED that the RSVP Receiver Proxy also issues sender Le Faucheur, et al. Expires January 2, 2009 [Page 18] Internet-Draft RSVP Receiver Proxy Extensions July 2008 notification via a PathErr message. This maximizes the chances that the notification reaches 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 Notify message and thus not issue sender notification via 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 very well 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 actually not receive Notify messages conveying downstream notifications. However, this is perfectly fine because the synchronisation 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 could happen to include a Notify Request object in Path messages for a reservation simply because it is interested in getting upstream notifications faster. If the reservation happens to be controlled by an RSVP Receiver Proxy supporting the procedures defined in this section, the sender will then 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 issues sender notification via a PathErr message even when sender notification via Notify message is used, the sender will still be notified of 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, to rely 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. Le Faucheur, et al. Expires January 2, 2009 [Page 19] Internet-Draft RSVP Receiver Proxy Extensions July 2008 4. Security Considerations To ensure the integrity of the associated reservation and admission control mechanisms, the RSVP Authentication mechanisms defined in [RFC2747] and [RFC3097] may be used. Those 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 the RSVP reservations established using an RSVP receiver proxy in accordance with the present document. [RFC2747] discusses several approaches for key distribution. First, the RSVP Authentication shared keys can be distributed manually. This is the base option and its support is mandated for any implementation. However, in some environments, this approach may become a burden if keys frequently change over time. Alternatively, a standard key management protocol for secure key distribution can be used. However, existing key distribution protocols may not be appropriate in all environments because of the complexity or operational burden they involve. The use of RSVP Authentication in parts of the network where there may be one or more IP hops in between two RSVP neighbors raises an additional challenge. This is because, with some RSVP messages such as a Path message, an RSVP router does not know the RSVP next hop for that message at the time of forwarding it. In fact, part of the role of a Path message is precisely to discover the RSVP next hop (and to dynamically re-discover it when it changes, say because of a routing change). Hence, the RSVP router may not know which security association to use when forwarding such a message. In that situation, one approach is to share the same RSVP Authentication shared key across all the RSVP routers of a part of the network where there may be RSVP neighbors with IP hops in between. For example, all the RSVP routers of an administrative domain (including the receiver proxys) could share the same RSVP Authentication key, while different per-neighbor keys could be used between any RSVP router pair straddling the boundary between two administrative domains that have agreed to use RSVP signaling. When the same RSVP Authentication shared key is to be shared among multiple RSVP neighbors, manual key distribution may be used. [I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses applicability of dynamic group key distribution method for dynamic update of such shared keys among RSVP routers. The RSVP Authentication mechanisms do not provide confidentiality. If confidentiality is required, IPsec ESP ([RFC4303]) may be used, although it imposes the burden of key distribution. It also faces Le Faucheur, et al. Expires January 2, 2009 [Page 20] Internet-Draft RSVP Receiver Proxy Extensions July 2008 the additional issue discussed for key management above in the case where there can be IP hops in between RSVP hops. [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of various keying methods for applying IPsec encryption and authentication to RSVP, including use of group keys and dynamic group key distribution. 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 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 where the use of 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 premises while the many RSVP receivers are located in the operator's customers premises. Such an environment is further illustrated in "Annex A.1. RSVP-based VoD CAC in Broadband Aggregation Networks" of [I-D.ietf-tsvwg-rsvp-proxy-approaches]. 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 which 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. 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 RSVP's 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 particular, where the Notify messages are transmitted non-hop-by-hop and the same level of security provided by [RFC2747] is desired, the standard IPsec based integrity and authentication can be used. Alternatively, the sending of non-hop-by-hop Notify messages can be disabled. Finally, Le Faucheur, et al. Expires January 2, 2009 [Page 21] Internet-Draft RSVP Receiver Proxy Extensions July 2008 [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of group keying for non-hop-by-hop Notify messages. Le Faucheur, et al. Expires January 2, 2009 [Page 22] Internet-Draft RSVP Receiver Proxy Extensions July 2008 5. IANA Considerations 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, this document requires that IANA updates the existing entries for these two Error Codes under the "Error Codes and Globally-Defined Error Value Sub-Codes" registry. Each entry should refer to this document, in addition to referring to [RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2 should respectively read: " 1 Admission Control Failure [RFC2205] [RFCXXX] ... 2 Policy Control Failure [RFC2205] [RFCXXX] ... " where [RFCXXX] refers to this document. This document also requires that IANA allocates a new RSVP Error Code ": Unrecoverable Receiver Proxy Error", as discussed in Section 3.1.2. This Error Code is to be allocated under the "Error Codes and Globally-Defined Error Value Sub-Codes" registry. The entry for this error code should read: " TBD Unrecoverable Receiver Proxy Error [RFCXXX] The sixteen bits of the Error Value field are defined in [RFCXXX] " where [RFCXXX] refers to this document and TBD is the value to be allocated by IANA. Le Faucheur, et al. Expires January 2, 2009 [Page 23] Internet-Draft RSVP Receiver Proxy Extensions July 2008 6. 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 Ken Carlberg for his valuable input. Le Faucheur, et al. Expires January 2, 2009 [Page 24] Internet-Draft RSVP Receiver Proxy Extensions July 2008 7. References 7.1. Normative References [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. [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001. [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. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. 7.2. Informative References [I-D.ietf-tsvwg-rsvp-proxy-approaches] Faucheur, F., Manner, J., Wing, D., and A. Guillou, "RSVP Proxy Approaches", draft-ietf-tsvwg-rsvp-proxy-approaches-04 (work in progress), April 2008. [I-D.ietf-tsvwg-rsvp-security-groupkeying] Behringer, M. and F. Faucheur, "Applicability of Keying Methods for RSVP Security", draft-ietf-tsvwg-rsvp-security-groupkeying-00 (work in progress), February 2008. Le Faucheur, et al. Expires January 2, 2009 [Page 25] Internet-Draft RSVP Receiver Proxy Extensions July 2008 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 University of Helsinki P.O. Box 68 University of Helsinki FIN-00014 University of Helsinki Finland Phone: +358 9 191 51298 Email: jmanner@cs.helsinki.fi URI: http://www.cs.helsinki.fi/u/jmanner/ Ashok Narayanan Cisco Systems 300 Beaver Brook Road Boxborough, MAS 01719 United States Email: ashokn@cisco.com Allan Guillou Neuf Cegetel 40-42 Quai du Point du Jour Boulogne-Billancourt, 92659 France Email: allan.guillou@neufcegetel.fr Le Faucheur, et al. Expires January 2, 2009 [Page 26] Internet-Draft RSVP Receiver Proxy Extensions July 2008 Hemant Malik Bharti Airtel Ltd. 4th Floor, Tower A, Unitech Cyber Park Gurgaon, Sector 39, 122001 India Email: Hemant.Malik@airtel.in Le Faucheur, et al. Expires January 2, 2009 [Page 27] Internet-Draft RSVP Receiver Proxy Extensions July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Le Faucheur, et al. Expires January 2, 2009 [Page 28]