idnits 2.17.1 draft-ietf-tsvwg-rsvp-proxy-proto-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2205, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2205, updated by this document, for RFC5378 checks: 1997-09-01) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5156 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXX' is mentioned on line 1416, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-rsvp-proxy-approaches-08 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-05 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG F. Le Faucheur 3 Internet-Draft Cisco 4 Updates: 2205 (if approved) J. Manner 5 Intended status: Standards Track TKK 6 Expires: September 9, 2010 A. Narayanan 7 Cisco 8 A. Guillou 9 Neuf 10 H. Malik 11 Bharti 12 March 8, 2010 14 RSVP Extensions for Path-Triggered RSVP Receiver Proxy 15 draft-ietf-tsvwg-rsvp-proxy-proto-11.txt 17 Abstract 19 RSVP signaling can be used to make end-to-end resource reservations 20 in an IP network in order to guarantee the QoS required by certain 21 flows. With conventional RSVP, both the data sender and receiver of 22 a given flow take part in RSVP signaling. Yet, there are many use 23 cases where resource reservation is required, but the receiver, the 24 sender, or both, is not RSVP-capable. Where the receiver is not 25 RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy 26 thereby performing RSVP signaling on behalf of the receiver. This 27 allows resource reservations to be established on the segment of the 28 end-to-end path from the sender to the RSVP Receiver Proxy. However, 29 as discussed in the companion document presenting RSVP Proxy 30 approaches, RSVP extensions are needed to facilitate operations with 31 an RSVP Receiver Proxy whose signaling is triggered by receipt of 32 RSVP Path messages from the sender. This document specifies these 33 extensions. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on September 9, 2010. 57 Copyright Notice 59 Copyright (c) 2010 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the BSD License. 72 This document may contain material from IETF Documents or IETF 73 Contributions published or made publicly available before November 74 10, 2008. The person(s) controlling the copyright in some of this 75 material may not have granted the IETF Trust the right to allow 76 modifications of such material outside the IETF Standards Process. 77 Without obtaining an adequate license from the person(s) controlling 78 the copyright in such materials, this document may not be modified 79 outside the IETF Standards Process, and derivative works of it may 80 not be created outside the IETF Standards Process, except to format 81 it for publication as an RFC or to translate it into languages other 82 than English. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 87 1.1. Conventions Used in This Document . . . . . . . . . . . . 7 88 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 89 3. RSVP Extensions for Sender Notification . . . . . . . . . . . 9 90 3.1. Sender Notification via PathErr Message . . . . . . . . . 12 91 3.1.1. Composition of SESSION and Sender Descriptor . . . . . 15 92 3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 15 93 3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 16 94 3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 17 95 3.2. Sender Notification via Notify Message . . . . . . . . . . 18 96 4. Mechanisms for Maximizing the Reservation Span . . . . . . . . 26 97 4.1. Dynamic Discovery of Downstream RSVP Functionality . . . . 26 98 4.2. Receiver Proxy Control Policy Element . . . . . . . . . . 28 99 4.2.1. Default Handling . . . . . . . . . . . . . . . . . . . 31 100 5. Security Considerations . . . . . . . . . . . . . . . . . . . 32 101 5.1. Security Considerations for the Sender Notification 102 via Notify Message . . . . . . . . . . . . . . . . . . . . 33 103 5.2. Security Considerations for the Receiver Proxy Control 104 Policy Element . . . . . . . . . . . . . . . . . . . . . . 33 105 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 106 6.1. RSVP Error Codes . . . . . . . . . . . . . . . . . . . . . 35 107 6.2. Policy Element . . . . . . . . . . . . . . . . . . . . . . 35 108 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 110 8.1. Normative References . . . . . . . . . . . . . . . . . . . 38 111 8.2. Informative References . . . . . . . . . . . . . . . . . . 39 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 114 1. Introduction 116 Guaranteed QoS for some applications with tight QoS requirements may 117 be achieved by reserving resources in each node on the end-to-end 118 path. The main IETF protocol for these resource reservations is RSVP 119 specified in [RFC2205]. RSVP does not require that all intermediate 120 nodes support RSVP, but it assumes that both the sender and the 121 receiver of the data flow support RSVP. However, there are 122 environments where it would be useful to be able to reserve resources 123 for a flow (at least a subset of the flow path) even when the sender 124 or the receiver (or both) is not RSVP-capable. 126 Since both the data sender and receiver may be unaware of RSVP, there 127 are two types of RSVP Proxies. In the first case, an entity in the 128 network needs to invoke RSVP on behalf of the data sender and thus 129 generate RSVP Path messages, and eventually receive, process and sink 130 Resv messages. We refer to this entity as the RSVP Sender Proxy. In 131 the second case, an entity in the network needs to operate RSVP on 132 behalf of the receiver and thus receive Path messages sent by a data 133 sender (or by an RSVP Sender Proxy), and reply to those with Resv 134 messages generated on behalf of the data receiver(s). We refer to 135 this entity as the RSVP Receiver Proxy. 137 RSVP Proxy approaches are presented in 138 [I-D.ietf-tsvwg-rsvp-proxy-approaches]. That document also 139 discusses, for each approach, how the reservations controlled by the 140 RSVP Proxy can be synchronized with the application requirements 141 (e.g., when to establish, maintain and tear down the RSVP reservation 142 to satisfy application requirements). 144 One RSVP Proxy approach is referred to as the Path-Triggered RSVP 145 Receiver Proxy approach. With this approach, the RSVP Receiver Proxy 146 uses the RSVP Path messages generated by the sender (or RSVP Sender 147 Proxy) as the cue for establishing the RSVP reservation on behalf of 148 the non-RSVP-capable receiver(s). The RSVP Receiver Proxy is 149 effectively acting as an intermediary making reservations (on behalf 150 of the receiver) under the sender's control (or RSVP Sender Proxy's 151 control). This changes somewhat the usual RSVP reservation model 152 where reservations are normally controlled by receivers. Such a 153 change greatly facilitates operations in the scenario of interest 154 here, which is where the receiver is not RSVP-capable. Indeed it 155 allows the RSVP Receiver Proxy to remain application unaware by 156 taking advantage of the application awareness and RSVP awareness of 157 the sender (or RSVP Sender Proxy). 159 Since the synchronization between an RSVP reservation and an 160 application is now effectively performed by the sender (or RSVP 161 Sender Proxy), it is important that the sender (or RSVP Sender Proxy) 162 is aware of the reservation state. However, as conventional RSVP 163 assumes that the reservation is to be controlled by the receiver, 164 some notifications about reservation state (notably the error message 165 sent in case of admission control rejection of the reservation) are 166 only sent towards the receiver and therefore, in our case, sunk by 167 the RSVP Receiver Proxy. Section 3 of the present document specifies 168 extensions to RSVP procedures allowing such notifications to be also 169 conveyed towards the sender. This facilitates synchronization by the 170 sender (or RSVP Sender Proxy) between the RSVP reservation and the 171 application requirements and facilitates sender-driven control of 172 reservation in scenarios involving a Path-Triggered RSVP receiver 173 Proxy. 175 With unicast applications in the presence of RSVP Receiver Proxies, 176 if the sender is notified about the state of the reservation towards 177 the receiver (as enabled by the present document), the sender is 178 generally in a good position to synchronize the reservation with the 179 application and to perform efficient sender-driven reservation: the 180 sender can control establishment (respectively removal) of the 181 reservation towards the receiver by sending Path (respectively 182 PathTear) messages. For example, if the sender is notified that the 183 reservation for a point to point audio session towards the receiver 184 is rejected, the sender may trigger rejection of the session at the 185 application layer and may issue a PathTear message to remove any 186 corresponding RSVP state (e.g. Path states) previously established. 188 However, we note that multicast applications do not always coexist 189 well with RSVP Receiver Proxies, since sender notification about 190 reservation state towards each RSVP Receiver Proxy may not be 191 sufficient to achieve tight application level synchronization by 192 multicast senders. These limitations stem from the fact that 193 multicast operation is receiver-driven and, while end-to-end RSVP is 194 also receiver-driven (precisely to deal with multicast efficiently), 195 the use of RSVP Receiver Proxies only allows sender-driven 196 reservation. For example, a sender generally is not aware of which 197 receivers have joined downstream of a given RSVP Receiver Proxy, or 198 even which RSVP Receiver Proxies have joined downstream of a given 199 failure point. Therefore, it may not be possible to support a mode 200 of operation whereby a given receiver only joins a group if that 201 receiver benefits from a reservation. Additionally, a sender may 202 have no recourse if only a subset of RSVP Receiver Proxies return 203 successful reservations (even if application-level signalling runs 204 between the sender and receivers), since the sender may not be able 205 to correctly identify the set of receivers who do not have 206 reservations. However, it is possible to support a mode of operation 207 whereby multicast traffic is transmitted if and only if all receivers 208 benefit from a reservation (from sender to their respective RSVP 209 Receiver Proxy): the sender can ensure this by sending a PathTear 210 message and stopping transmission whenever it gets a notification for 211 reservation reject for one or more RSVP Receiver Proxy. It is also 212 possible to support a mode of operation whereby receivers join 213 independently of whether they can benefit from a reservation (to 214 their respective RSVP Receiver Proxy) or not, but do benefit from a 215 reservation whenever the corresponding resources are reservable on 216 the relevant path. 218 This document discusses extensions to facilitate operations in the 219 presence of a Path-triggered RSVP Receiver Proxy. As pointed out 220 previously, those apply equally whether RSVP signaling is initiated 221 by a regular RSVP sender or by an RSVP Sender Proxy (with some means 222 to synchronize reservation state with application level requirements 223 that are outside the scope of this document). For readability, the 224 rest of this document discusses operation assuming a regular RSVP 225 sender; however, such operation is equally applicable where an RSVP 226 Sender Proxy is used to initiated RSVP signaling on behalf of a non- 227 RSVP-capable sender. 229 As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], it is 230 important to keep in mind that the strongly recommended RSVP 231 deployment model remains end to end as assumed in [RFC2205] with RSVP 232 support on the sender and the receiver. The end to end model allows 233 the most effective synchronization between the reservation and 234 application requirements. Also, when compared to the end to end RSVP 235 model, the use of RSVP Proxies involves additional operational burden 236 and/or impose some topological constraints. Thus, the purpose of 237 this document is only to allow RSVP deployment in special 238 environments where RSVP just cannot be used on some senders and/or 239 some receivers for reasons specific to the environment. 241 Section 4.1.1 of [I-D.ietf-tsvwg-rsvp-proxy-approaches] discusses 242 mechanisms allowing the RSVP reservation for a given flow to be 243 dynamically extended downstream of an RSVP Proxy whenever possible 244 (i.e. When the receiver is RSVP capable or when there is another 245 RSVP Receiver Proxy downstream). This can considerably alleviate the 246 operational burden and the topological constraints associated with 247 Path-triggered RSVP Receiver Proxies. This allows (without 248 corresponding manual configuration) an RSVP reservation to 249 dynamically span as much of the corresponding flow path as possible, 250 with any arbitrary number of RSVP Receiver Proxies on the flow path 251 and whether the receiver is RSVP capable or not. In turn, this 252 facilitates migration from an RSVP deployment model based on Path- 253 triggered Receiver Proxies to an end-to-end RSVP model, since 254 receivers can gradually and independently be upgraded to support RSVP 255 and then instantaneously benefit from end-to-end reservations. 256 Section 4 of the present document specifies these mechanisms and 257 associated RSVP extensions. 259 1.1. Conventions Used in This Document 261 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 262 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 263 document are to be interpreted as described in [RFC2119]. 265 2. Terminology 267 The following terminology is borrowed from 268 [I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the 269 present document: 271 o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per 272 [RFC2205] 274 o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf 275 of a receiver, the RSVP operations which would normally be 276 performed by an RSVP-capable receiver if end-to-end RSVP signaling 277 was used. Note that while RSVP is used upstream of the RSVP 278 Receiver Proxy, RSVP is not used downstream of the RSVP Receiver 279 Proxy. 281 o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of 282 a sender, the RSVP operations that normally would be performed by 283 an RSVP-capable sender if end-to-end RSVP signaling was used. 284 Note that while RSVP is used downstream of the RSVP Sender Proxy, 285 RSVP is not used upstream of the RSVP Sender Proxy. 287 o Regular RSVP Router: an RSVP-capable router which is not behaving 288 as a RSVP Receiver Proxy nor as a RSVP Sender Proxy. 290 Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, 291 Regular RSVP Router are all relative to one unidirectional flow. A 292 given router may act as the RSVP Receiver Proxy for a flow, as the 293 RSVP Sender Proxy for another flow and as a Regular RSVP router for 294 yet another flow. 296 The following terminology is also used in the present document: 298 o Regular RSVP Sender: an RSVP-capable host behaving as the sender 299 for the considered flow and participating in RSVP signaling in 300 accordance with the sender behavior specified in [RFC2205]. 302 o Regular RSVP Receiver: an RSVP-capable host behaving as the 303 receiver for the considered flow and participating in RSVP 304 signaling in accordance with the receiver behavior specified in 305 [RFC2205]. 307 3. RSVP Extensions for Sender Notification 309 This section defines extensions to RSVP procedures allowing sender 310 notification of reservation failure. This facilitates 311 synchronization by the sender between RSVP reservation and 312 application requirements in scenarios involving a Path-Triggered RSVP 313 Receiver Proxy. 315 As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], with the 316 Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be 317 configured to use receipt of a regular RSVP Path message as the 318 trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP 319 Path message, the RSVP Receiver Proxy: 321 1. establishes the RSVP Path state as per regular RSVP processing 323 2. identifies the downstream interface towards the receiver 325 3. sinks the Path message 327 4. behaves as if a corresponding Resv message (on its way upstream 328 from the receiver) was received on the downstream interface. 329 This includes performing admission control on the downstream 330 interface, establishing a Resv state (in case of successful 331 admission control) and forwarding the Resv message upstream, 332 sending periodic refreshes of the Resv message and tearing down 333 the reservation if the Path state is torn down. 335 Operation of the Path-Triggered Receiver Proxy in the case of a 336 successful reservation is illustrated in Figure 1. 338 |****| *** *** *** |**********| |----| 339 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 340 |****| *** *** *** | Receiver | |----| 341 | Proxy | 342 |**********| 344 --Path---> --Path---> --Path---> --Path---> 346 <---Resv-- <---Resv-- <---Resv-- <---Resv-- 348 ===================RSVP===================> 350 ************************************************************> 352 |****| RSVP-capable |----| Non-RSVP-capable *** 353 | S | Sender | R | Receiver *r* regular RSVP 354 |****| |----| *** router 356 ***> media flow 358 ==> segment of flow path benefiting from an RSVP reservation 360 Figure 1: Successful Reservation 362 We observe that, in the case of successful reservation, conventional 363 RSVP procedures ensure that the sender is notified of the successful 364 reservation establishment. Thus, no extensions are required in the 365 presence of a Path-Triggered RSVP Receiver Proxy in the case of 366 successful reservation establishment. 368 However, in case of reservation failure, conventional RSVP procedures 369 ensure only that the receiver (or the RSVP Receiver Proxy) is 370 notified of the reservation failure. Specifically, in case of an 371 admission control rejection on a regular RSVP router, a ResvErr 372 message is sent downstream towards the receiver. In the presence of 373 an RSVP Receiver Proxy, if we simply follow conventional RSVP 374 procedures, this means that the RSVP Receiver Proxy is notified of 375 the reservation failure, but the sender is not. Operation of the 376 Path-Triggered RSVP Receiver Proxy in the case of an admission 377 control failure, assuming conventional RSVP procedures, is 378 illustrated in Figure 2. 380 |****| *** *** *** |**********| |----| 381 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 382 |****| *** *** *** | Receiver | |----| 383 | Proxy | 384 |**********| 386 --Path---> --Path---> --Path---> --Path---> 388 <---Resv-- <---Resv-- 390 -ResvErr-> -ResvErr-> 392 ===================RSVP===================> 394 ************************************************************> 396 |****| RSVP-capable |----| Non-RSVP-capable *** 397 | S | Sender | R | Receiver *r* regular RSVP 398 |****| |----| *** router 400 ***> media flow 402 ==> segment of flow path benefiting from an RSVP reservation 404 Figure 2: Reservation Failure With Conventional RSVP 406 While the sender could infer reservation failure from the fact that 407 it has not received a Resv message after a certain time, there are 408 clear benefits in ensuring that the sender gets a prompt, explicit 409 notification in case of reservation failure. This includes faster 410 end-user notification at application layer (e.g., busy signal), 411 faster application level reaction (e.g., application level 412 rerouting), as well as faster release of application-level resources. 414 Section 3.1 defines a method that can be used to achieve sender 415 notification of reservation failure. A router implementation 416 claiming compliance with this document MUST support the method 417 defined in Section 3.1. 419 Section 3.2 defines another method that can be used to achieve sender 420 notification of reservation failure. A router implementation 421 claiming compliance with this document MAY support the method defined 422 in Section 3.2. 424 In a given network environment, a network administrator may elect to 425 use the method defined in Section 3.1, or the method defined in 426 Section 3.2, or possibly combine the two. 428 3.1. Sender Notification via PathErr Message 430 With this method, the RSVP Receiver Proxy MUST generate a PathErr 431 message whenever the two following conditions are met: 433 1. The reservation establishment has failed (or the previously 434 established reservation has been torn down) 436 2. The RSVP Receiver Proxy determines that it cannot re-establish 437 the reservation (e.g., by adapting its reservation request in 438 reaction to the error code provided in the received ResvErr in 439 accordance with local policy) 441 Note that this notion of generating a PathErr message upstream in 442 order to notify the sender about a reservation failure is not 443 completely new. It is borrowed from [RFC3209] where it has been 444 introduced in order to achieve a similar requirement, which is to 445 allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end 446 (i.e., the sender) of a failure to establish (or maintain) a TE 447 Tunnel Label Switch Path. 449 Operation of the Path-Triggered RSVP Receiver Proxy in the case of an 450 admission control failure, using sender notification via PathErr 451 Message, is illustrated in Figure 3. 453 |****| *** *** *** |**********| |----| 454 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 455 |****| *** *** *** | Receiver | |----| 456 | Proxy | 457 |**********| 459 --Path---> --Path---> --Path---> --Path---> 461 <---Resv-- <---Resv-- 463 -ResvErr-> -ResvErr-> 465 <-PathErr- <-PathErr- <-PathErr- <-PathErr- 467 ===================RSVP===================> 469 ************************************************************> 471 |****| RSVP-capable |----| Non-RSVP-capable *** 472 | S | Sender | R | Receiver *r* regular RSVP 473 |****| |----| *** router 475 ***> media flow 477 ==> segment of flow path benefiting from RSVP 478 (but not benefiting from a reservation in this case) 480 Figure 3: Reservation Failure With Sender Notification via PathErr 482 The role of this PathErr is to notify the sender that the reservation 483 was not established or was torn down. This may be in the case of 484 receipt of a ResvErr, or because of local failure on the Receiver 485 Proxy. On receipt of a ResvErr, in all situations where the 486 reservation cannot be installed, the Receiver Proxy MUST generate a 487 PathErr towards the sender. For local failures on the Receiver Proxy 488 node, if a similar failure on an RSVP midpoint would cause the 489 generation of a ResvErr (for example, admission control failure), the 490 Receiver Proxy MUST generate a PathErr towards the sender. The 491 Receiver Proxy MAY additionally generate a PathErr upon local 492 failures which would not ordinarily cause generation of a ResvErr 493 message, such as described in Appendix B of [RFC2205]. 495 The PathErr generated by the Receiver Proxy corresponds to the 496 sender(s) that triggered generation of Resv messages that failed. 497 For Fixed-Filter (FF) style reservations, the Receiver Proxy MUST 498 send a PathErr towards the (single) sender matching the failed 499 reservation. For Shared-Explicit (SE) style reservations, the 500 Receiver Proxy MUST send the PathErr(s) towards the set of senders 501 that triggered reservations that failed. This may be a subset of 502 senders sharing the same reservation, in which case the remaining 503 senders would have their reservation intact and would not receive a 504 PathErr. In both cases, the rules described in Section 3.1.8 of 505 [RFC2205] for generating flow descriptors in ResvErr messages, also 506 apply when generating sender descriptors in PathErr messages. 508 For Wildcard-Filter (WF) style reservations, it is not always 509 possible for the Receiver Proxy to reliably know which sender caused 510 the reservation failure. Therefore, the Receiver Proxy SHOULD send a 511 PathErr towards each sender. This means that all the senders will 512 receive a notification that the reservation is not established, 513 including senders that did not cause the reservation failure. 514 Therefore, the method of sender notification via PathErr message is 515 somewhat over-conservative (i.e., in some cases rejecting 516 reservations from some senders when those could have actually been 517 established) when used in combination with Wildcard-Filter style (and 518 when there is more than one sender). 520 The sender notification via PathErr method applies to both unicast 521 and multicast sessions. However, for a multicast session, it is 522 possible that reservation failure (e.g., admission control failure) 523 in a node close to a sender may cause ResvErr messages to be sent to 524 a large group of Receiver Proxies. These Receiver Proxies would, in 525 turn, all send PathErr messages back to the same sender, which could 526 cause a scalability issue in some environments. 528 From the perspective of the sender, errors that prevent a reservation 529 from being set up can be classified in two ways: 531 1. Errors that the sender can attempt to correct. The error code 532 for those errors should explicitly be communicated back to the 533 sender. An examples of this is "Class 1: Admission Control 534 Failure", because the sender could potentially resend a Path with 535 smaller traffic parameters. 537 2. Errors over which the sender has no control. For these errors, 538 it is sufficient to notify the sender that the reservation was 539 not set up successfully. An example of this is "Class 13: 540 Unknown Object", because the sender has no control over the 541 objects inserted into the reservation by the Receiver Proxy. 543 The PathErr message generated by the Receiver Proxy has the same 544 format as regular PathErr messages defined in [RFC2205]. The 545 SESSION, ERROR_SPEC and sender descriptor are composed by the 546 Receiver Proxy as specified in the following subsections. The 547 Receiver Proxy MAY reflect back towards the sender in the PathErr any 548 POLICY_DATA objects received in the ResvErr. 550 3.1.1. Composition of SESSION and Sender Descriptor 552 The Receiver Proxy MUST insert the SESSION object corresponding to 553 the failed reservation, into the PathErr. For Fixed-Filter (FF) 554 style reservations, the Receiver Proxy MUST insert a sender 555 descriptor corresponding to the failed reservation, into the PathErr. 556 This is equal to the error flow descriptor in the ResvErr received by 557 the Receiver Proxy. For Shared-Explicit (SE) style reservations, the 558 Receiver Proxy MUST insert a sender descriptor corresponding to the 559 sender triggering the failed reservation, into the PathErr. This is 560 equal to the error flow descriptor in the ResvErr received by the 561 Receiver Proxy. If multiple flow descriptors could not be admitted 562 at a midpoint node, that node would generate multiple ResvErr 563 messages towards the receiver as per Section 3.1.8 of [RFC2205]. 564 Each ResvErr would contain an error flow descriptor that matches a 565 specific sender. The Receiver Proxy MUST generate a PathErr for each 566 ResvErr received, towards the corresponding sender. As specified 567 earlier, for Wildcard-Filter style reservations, the Receiver Proxy 568 SHOULD send a PathErr to each sender. 570 3.1.2. Composition of ERROR_SPEC 572 The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into 573 the PathErr as follows: 575 1. If the Receiver Proxy receives a ResvErr with any of these error 576 codes: "Code 1 - Admission Control Failure" or "Code 2 - Policy 577 Control Failure" then the Receiver Proxy copies the error code 578 and value from the ERROR_SPEC in the ResvErr, into the ERROR_SPEC 579 of the PathErr message. The error node in the PathErr MUST be 580 set to the address of the Receiver Proxy. This procedure MUST 581 also be followed for a local error on the Receiver Proxy that 582 would ordinarily cause a midpoint to generate a ResvErr with one 583 of the above codes. 585 2. If the Receiver Proxy receives a ResvErr with any error code 586 other than the ones listed in 1 above, it composes a new 587 ERROR_SPEC with error code ": Unrecoverable Receiver Proxy Error". The error node in 589 the PathErr MUST be set to the address of the Receiver Proxy. 590 This procedure MUST also be followed for a local error on the 591 Receiver Proxy that would ordinarily cause a midpoint to generate 592 a ResvErr with any error code except than those listed in 1 593 above, or if the Receiver Proxy generates a PathErr for a local 594 error which ordinarily would not cause generation of a ResvErr. 596 In some cases it may be predetermined that the PathErr will not 597 reach the sender. For example, a node receiving a ResvErr with 598 "Code 3: No Path for Resv", knows a priori that the PathErr 599 message it generates cannot be forwarded by the same node which 600 could not process the Resv. Nevertheless, the procedures above 601 MUST be followed. For the error code ": Unrecoverable Receiver Proxy Error", the 603 16 bits of the Error Value field are: 605 * hhhh hhhh llll llll 607 where the bits are: 609 * hhhh hhhh = 0000 0000: then the low order 8 bits (llll llll) 610 MUST be set by Receiver Proxy to 0000 0000 and MUST be ignored 611 by the sender. 613 * hhhh hhhh = 0000 0001: then the low order 8 bits (llll llll) 614 MUST be set by the Receiver Proxy to the value of the error 615 code received in the ResvErr ERROR_SPEC (or, in case the 616 Receiver Proxy generated the PathErr without having received a 617 ResvErr, to the error code value that would have been included 618 by the Receiver Proxy in the ERROR_SPEC in similar conditions 619 if it was to generate a ResvErr). This error value MAY be 620 used by the sender to further interpret the reason of the 621 reservation failure. 623 * hhhh hhhh = any other value: reserved. 625 3. If the Receiver Proxy Receives a ResvErr with the InPlace flag 626 set in the ERROR_SPEC, it MUST also set the InPlace flag in the 627 ERROR_SPEC of the PathErr. 629 3.1.3. Use of Path_State_Removed Flag 631 [RFC3473] defines an optional behavior whereby a node forwarding a 632 PathErr message can remove the Path State associated with the PathErr 633 message and indicate so by including the Path_State_Removed flag in 634 the ERROR_SPEC object of the PathErr message. This can be used in 635 some situations to expedite release of resources and minimize 636 signaling load. 638 This section discusses aspects of the use of the Path_State_Removed 639 flag that are specific to the RSVP Receiver Proxy. In any other 640 aspects, the Path_State_Removed flag operates as per [RFC3473]. 642 By default, the RSVP Receiver Proxy MUST NOT include the 643 Path_State_Removed flag in the ERROR_SPEC of the PathErr message. 645 This ensures predictable operations in all environments including 646 those where some RSVP routers do not understand the 647 Path_State_Removed flag. 649 The RSVP Receiver Proxy MAY support an OPTIONAL mode (to be activated 650 by configuration) whereby the RSVP Receiver Proxy includes the 651 Path_State_Removed flag in the ERROR_SPEC of the PathErr message and 652 removes its local Path state. When all routers on the path of a 653 reservation support the Path_State_Removed flag, its use will indeed 654 result in expedited resource release and reduced signaling. However, 655 if there are one or more RSVP router on the path of the reservation 656 that do not support the Path_State_Removed flag (we refer to such 657 routers as "old RSVP routers"), the use of the Path_State_Removed 658 flag will actually result in slower resource release and increased 659 signaling. This is because the Path_State_Removed flag will be 660 propagated upstream by an old RSVP router (even if it does not 661 understand it and does not tear its Path state). Thus, the sender 662 will not send a Path Tear and the old RSVP router will release its 663 Path state only through refresh time-out. A network administrator 664 needs to keep these considerations in mind when deciding whether to 665 activate the use of the Path_State_Removed flag on the RSVP Receiver 666 Proxy. In a controlled environment where all routers are known to 667 support the Path_State_Removed flag, its use can be safely activated 668 on the RSVP Receiver Proxy. In other environments, the network 669 administrator needs to assess whether the improvement achieved with 670 some reservations outweighs the degradation experienced by other 671 reservations. 673 3.1.4. Use of PathErr by Regular Receivers 675 Note that while this document specifies that an RSVP Receiver Proxy 676 generates a PathErr upstream in case of reservation failure, this 677 document does NOT propose that the same be done by regular receivers. 678 In other words, this document does NOT propose to modify the behavior 679 of regular receivers as currently specified in [RFC2205]. The 680 rationale for this includes the following: 682 o When the receiver is RSVP capable, the current receiver-driven 683 model of [RFC2205] is fully applicable because the receiver can 684 synchronise RSVP reservation state and application state (since it 685 participates in both). The sender(s) needs not be aware of the 686 RSVP reservation state. Thus, we can retain the benefits of 687 receiver-driven operations which were explicitly sought by 688 [RFC2205]. Quoting from it: " In order to efficiently accommodate 689 large groups, dynamic group membership, and heterogeneous receiver 690 requirements, RSVP makes receivers responsible for requesting a 691 specific QoS". But even for the simplest single_sender/ 692 single_receiver reservations, the current receiver-driven model 693 reduces signaling load and per-hop RSVP processing by not sending 694 any error message to the sender in case of admission control 695 reject. 697 o The motivation for adding sender error notification in case of 698 receiver proxy lies in the fact that the actual receiver can no 699 longer synchronize the RSVP reservation with application state 700 (since the receiver does not participate in RSVP signaling), while 701 the sender can. This motivation does not apply in case of regular 702 receiver. 704 o There is a lot of existing code and deployed systems successfully 705 working under the current [RFC2205] model in the absence of proxy 706 today. The current behavior should not be changed for those 707 unless there were a very strong motivation. 709 3.2. Sender Notification via Notify Message 711 The OPTIONAL method for sender notification of reservation failure 712 defined in this section aims to provide a more efficient method than 713 the one defined in Section 3.1. Its objectives include: 715 o allow the failure notification to be sent directly upstream to the 716 sender by the router where the failure occurs (as opposed to first 717 travelling downstream towards the Receiver Proxy and then 718 travelling upstream from the Receiver Proxy to the sender, as 719 effectively happens with the method defined in Section 3.1) 721 o allow the failure notification to travel without hop-by-hop RSVP 722 processing 724 o ensure that such a notification is sent to senders that are 725 capable and willing to process it (i.e., to synchronize 726 reservation status with application) 728 o ensure that such a notification is only sent in case the receiver 729 is not itself capable and willing to do the synchronization with 730 the application (i.e., because we are in the presence of a 731 Receiver Proxy so that RSVP signaling is not visible to the 732 receiver). 734 Note, however, that such benefits come at the cost of: 736 o a requirement for RSVP routers and senders to support the Notify 737 messages and procedures defined in [RFC3473] 739 o a requirement for senders to process Notify messages traveling 740 upstream but conveying a downstream notification. 742 [RFC3473] defines (in section "4.3 Notify Messages") the Notify 743 message that provides a mechanism to inform non-adjacent nodes of 744 events related to the RSVP reservation. The Notify message differs 745 from the error messages defined in [RFC2205] (i.e., PathErr and 746 ResvErr messages) in that it can be "targeted" to a node other than 747 the immediate upstream or downstream neighbor and that it is a 748 generalized notification mechanism. Notify messages are normally 749 generated only after a Notify Request object has been received. 751 This section discusses aspects of the use of the Notify message that 752 are specific to the RSVP Receiver Proxy. In any other aspects, the 753 Notify message operates as per [RFC3473]. 755 In order to achieve sender notification of reservation failure in the 756 context of the present document: 758 o An RSVP sender interested in being notified of reservation failure 759 MUST include a Notify Request object (containing the sender's IP 760 address) in the Path messages it generates. 762 o Upon receiving a Path message with a Notify Request object, the 763 RSVP Receiver Proxy MUST include a Notify Request object in the 764 Resv messages it generates. This Notify Request object MUST 765 contain: 767 * either the address that was included in the Notify Request of 768 the received Path message- a.k.a. The sender's address-. We 769 refer to this approach as the "Direct Notify". 771 * or an address of the Receiver Proxy. We refer to this approach 772 as the "Indirect Notify". 774 o Upon receiving a downstream error notification (whether in the 775 form of a Notify or a ResvErr or both), the RSVP Receiver Proxy: 777 * MUST generate a Notify message with upstream notification to 778 the corresponding sender, if the sender included a Notify 779 Request object in its Path messages and if Indirect 780 Notification is used. 782 * SHOULD generate a Notify message with upstream notification to 783 the corresponding sender, if the sender included a Notify 784 Request object in its Path messages and if Direct Notification 785 is used. The reason for this recommendation is that the 786 failure node may not support Notify, so that even if Direct 787 Notification was requested by the RSVP Receiver Proxy, the 788 sender may not actually have received a Notify from the failure 789 node: generating a Notify from the Receiver Proxy will 790 accelerate sender notification, as compared to simply relying 791 on PathErr, in this situation. In controlled environments 792 where all the nodes are known to support Notify, the Receiver 793 Proxy MAY be configured to not generate the Notify with 794 upstream notification when Direct Notification is used, in 795 order to avoid duplication of Notify messages (i.e. The sender 796 receiving both a Notify from the failure node and from the 797 Receiver Proxy) 799 As a result of these sender and Receiver Proxy behaviors, as per 800 existing Notify procedures, if an RSVP router detects an error 801 relating to a Resv state (e.g., admission control rejection after IP 802 reroute), the RSVP router will send a Notify message (conveying the 803 downstream notification with the ResvErr error code) to the IP 804 address contained in the Resv Notify Request object. If this address 805 has been set by the RSVP Receiver Proxy to the sender's address 806 (Direct Notify), the Notify message is sent directly to the sender. 807 If this address has been set by the RSVP Receiver Proxy to one of its 808 address (Indirect Notify), the Notify message is sent to the RSVP 809 Receiver Proxy that, in turn, will generate a Notify message directly 810 addressed to the sender. 812 Operation of the Path-Triggered RSVP Receiver Proxy in the case of an 813 admission control failure, using sender notification via Direct 814 Notify, is illustrated in Figure 4. 816 |****| *** *** *** |**********| |----| 817 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 818 |****| *** *** *** | Receiver | |----| 819 | Proxy | 820 |**********| 822 --Path*--> --Path*--> --Path*--> --Path*--> 824 <--Resv*-- <--Resv*-- 826 <------NotifyD-------- 828 -ResvErr-> -ResvErr-> 830 <------------------NotifyU------------------ 832 <-PathErr- <-PathErr- <-PathErr- <-PathErr- 834 ===================RSVP===================> 836 ************************************************************> 838 |****| RSVP-capable |----| Non-RSVP-capable *** 839 | S | Sender | R | Receiver *r* regular RSVP 840 |****| |----| *** router 842 ***> media flow 844 ==> segment of flow path benefiting from RSVP 845 (but not benefiting from a reservation in this case) 847 Path* = Path message containing a Notify Request object 848 with sender IP Address 850 Resv* = Resv message containing a Notify Request object 851 with sender IP address 853 NotifyD = Notify message containing a downstream notification 855 NotifyU = Notify message containing an upstream notification 857 Figure 4: Reservation Failure With Sender Notification via Direct 858 Notify 860 Operation of the Path-Triggered RSVP Receiver Proxy in the case of an 861 admission control failure, using sender notification via Indirect 862 Notify, is illustrated in Figure 5. 864 |****| *** *** *** |**********| |----| 865 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 866 |****| *** *** *** | Receiver | |----| 867 | Proxy | 868 |**********| 870 --Path*--> --Path*--> --Path*--> --Path*--> 872 <--Resv*-- <--Resv*-- 874 -------NotifyD-------> 876 <------------------NotifyU------------------ 878 -ResvErr-> -ResvErr-> 880 <-PathErr- <-PathErr- <-PathErr- <-PathErr- 882 ===================RSVP===================> 884 ************************************************************> 886 |****| RSVP-capable |----| Non-RSVP-capable *** 887 | S | Sender | R | Receiver *r* regular RSVP 888 |****| |----| *** router 890 ***> media flow 892 ==> segment of flow path benefiting from RSVP 893 (but not benefiting from a reservation in this case) 895 Path* = Path message containing a Notify Request object 896 with sender IP Address 898 Resv* = Resv message containing a Notify Request object 899 with RSVP Receiver Proxy IP address 901 NotifyD = Notify message containing a downstream notification 903 NotifyU = Notify message containing an upstream notification 905 Figure 5: Reservation Failure With Sender Notification via Indirect 906 Notify 908 For local failures on the Receiver Proxy node, if a similar failure 909 on an RSVP midpoint would cause the generation of a ResvErr (for 910 example, admission control failure), the Receiver Proxy MUST generate 911 a Notify towards the sender. The Receiver Proxy MAY additionally 912 generate a Notify upon local failures that would not ordinarily cause 913 generation of a ResvErr message, such as described in Appendix B of 914 [RFC2205]. 916 When the method of sender notification via Notify message is used, it 917 is RECOMMENDED that the RSVP Receiver Proxy also issue a sender 918 notification via a PathErr message. This maximizes the chances that 919 the notification will reach the sender in all situations (e.g., even 920 if some RSVP routers do not support the Notify procedure, or if a 921 Notify message gets dropped). However, for controlled environments 922 (e.g., where all RSVP routers are known to support Notify procedures) 923 and where it is desirable to minimize the volume of signaling, the 924 RSVP Receiver Proxy MAY rely exclusively on sender notification via 925 Notify message and thus not issue sender notification via PathErr 926 message. 928 In environments where there are both RSVP-capable receivers and RSVP 929 Receiver Proxies acting on behalf of non RSVP-capable receivers, a 930 sender does not know whether a given reservation is established with 931 an RSVP-capable receiver or with an RSVP Receiver Proxy. Thus, a 932 sender that supports the procedures defined in this section may 933 include a Notify Request object in Path messages for a reservation 934 that happens to be controlled by an RSVP-capable receiver. This 935 document does not define, nor expect, any change in existing receiver 936 behavior. As a result, in this case, the sender will not receive 937 Notify messages conveying downstream notifications. However, this is 938 perfectly fine because the synchronization between the RSVP 939 reservation state and the application requirement can be performed by 940 the actual receiver in this case as per the regular end-to-end RSVP 941 model, so that in this case, the sender need not care about 942 downstream notifications. 944 A sender that does not support the procedures defined in this section 945 might include a Notify Request object in Path messages for a 946 reservation simply because it is interested in getting upstream 947 notifications faster. If the reservation is controlled by an RSVP 948 Receiver Proxy supporting the procedures defined in this section, the 949 sender will also receive unexpected Notify messages containing 950 downstream notifications. It is expected that such a sender will 951 simply naturally drop such downstream notifications as invalid. 952 Because it is RECOMMENDED above that the RSVP Receiver Proxy also 953 issues sender notification via a PathErr message even when sender 954 notification is effected via a Notify message, the sender will still 955 be notified of a reservation failure in accordance with the "sender 956 notification via PathErr" method. In summary, activating the 957 OPTIONAL "sender notification via Notify" method on a Receiver Proxy, 958 does not prevent a sender that does not support this method, to rely 959 on the MANDATORY "sender notification via PathErr" method. It would, 960 however, allow a sender supporting the "sender notification via 961 Notify" method to take advantage of this OPTIONAL method. 963 With Direct Notification, the downstream notification generated by 964 the RSVP router where the failure occurs is sent to the IP address 965 contained in the Notification Request Object of the corresponding 966 Resv message. In the presence of multiple senders towards the same 967 session, it cannot be generally assumed that a separate Resv message 968 is used for each sender (in fact with WF and SE there is a single 969 Resv message for all senders, and with FF the downstream router has 970 the choice of generating separate Resv messages or a single one). 971 Hence, in the presence of multiple senders, Direct Notification 972 cannot guarantee notification of all affected senders. Therefore, 973 Direct Notification is better suited to single sender applications. 975 With Indirect Notification, the RSVP Receiver Proxy can generate 976 Notify messages with the same logic that is used to generate PathErr 977 messages in the "Sender Notification via PathErr" method (in fact 978 those are conveying the same error information, only the Notify is 979 directly addressed to the sender while the PathErr travels hop-by- 980 hop). Therefore, operations of Indirect Notify method in the 981 presence of multiple senders is similar to that of the PathErr method 982 as discussed in Section 3.1: with FF (respectively, SE) a Notify MUST 983 be sent to the sender (respectively, the set of affected senders). 984 With WF, the RSVP Receiver Proxy SHOULD send a Notify to each sender, 985 again resulting in a somewhat over-conservative behavior in the 986 presence of multiple senders. 988 4. Mechanisms for Maximizing the Reservation Span 990 This section defines extensions to RSVP procedures allowing an RSVP 991 reservation to span as much as possible of the flow path, with any 992 arbitrary number of RSVP Receiver Proxies on the flow path and 993 whether the receiver is RSVP capable or not. This facilitates 994 deployment and operations of Path-triggered RSVP Receiver Proxies 995 since it alleviates the topological constraints and/or configuration 996 load otherwise associated with Receiver Proxies (e.g. Make sure 997 there is no RSVP Receiver Proxy for a flow upstream of a given 998 Receiver Proxy, ensure there is no Receiver Proxy for a flow if the 999 receiver is RSVP capable). This also facilitates migration from an 1000 RSVP deployment model based on Path-triggered Receiver Proxies to an 1001 end-to-end RSVP model, since receivers can gradually and 1002 independently be upgraded to support RSVP and then instantaneously 1003 benefit from end-to-end reservations. 1005 Section 4.1 defines a method that allows a Path-triggered Receiver 1006 Proxy function to discover whether there is another Receiver Proxy or 1007 an RSVP capable receiver downstream and then dynamically extend the 1008 span of the RSVP reservation downstream. A router implementation 1009 claiming compliance with this document SHOULD support the method 1010 defined in Section 4.1. 1012 Section 4.2 defines a method that allows a sender to control whether 1013 an RSVP router supporting the Path-triggered Receiver Proxy function 1014 is to behave as a Receiver Proxy for a given flow or not. A router 1015 implementation claiming compliance with this document MAY support the 1016 method defined in Section 4.2. 1018 In a given network environment, a network administrator may elect to 1019 use the method defined in Section 4.1, or the method defined in 1020 Section 4.2, or possibly combine the two. 1022 4.1. Dynamic Discovery of Downstream RSVP Functionality 1024 When generating a proxy Resv message upstream, a Receiver Proxy 1025 supporting dynamic discovery of downstream RSVP functionality MUST 1026 forward the Path message downstream instead of terminating it (unless 1027 dynamic discovery of downstream RSVP functionality is explicitely 1028 disabled). If the destination endpoint supports RSVP (or there is 1029 another Receiver Proxy downstream), it will receive the Path and 1030 generate a Resv upstream. When this Resv message reaches the 1031 Receiver Proxy, it recognizes the presence of a RSVP-capable receiver 1032 (or of another RSVP Receiver Proxy) downstream and MUST internally 1033 converts its state from a proxied reservation to a regular midpoint 1034 RSVP behavior. From then on, the RSVP router MUST behave as a 1035 regular RSVP router for that reservation (i.e. As if the RSVP router 1036 never behaved as an RSVP receiver proxy for that flow). This method 1037 is illustrated in Figure 6. 1039 |****| *** |**********| |----| 1040 | S |---------*r*---------| RSVP |---| R1 | 1041 |****| *** | Receiver | |----| 1042 | Proxy | 1043 | | 1044 | | |****| 1045 | |------------| R2 | 1046 |**********| |****| 1048 ---Path---> --Path---> 1049 (R1) (R1) \-------Path--> 1050 / (R1) 1051 <--Resv--- <---Resv--- 1053 ================RSVP===> 1055 **************************************> 1057 ---Path---> --Path---> 1058 (R2) (R2) \-------------Path----> 1059 / (R2) 1060 <--Resv--- <---Resv--- 1061 <----Resv--- 1063 ================RSVP===========================> 1065 ***********************************************> 1067 |****| RSVP-capable |----| non-RSVP-capable |****| RSVP-capable 1068 | S | Sender | R | Receiver | R | Receiver 1069 |****| |----| |****| 1071 *** 1072 *r* regular RSVP 1073 *** router 1075 (R1) = Path message contains a Session object whose destination is R1 1077 ***> media flow 1079 ==> segment of flow path protected by RSVP reservation 1080 Figure 6: Dynamic Discovery of Downstream RSVP Functionality 1082 If there is no RSVP-capable receiver (or other Receiver Proxy) 1083 downstream of the Receiver Proxy, then the Path messages sent by the 1084 Receiver Proxy every RSVP refresh interval (e.g. 30 seconds by 1085 default) will never be responded to. However, these messages consume 1086 a small amount of bandwidth, and in addition would install some RSVP 1087 state on RSVP-capable midpoint nodes downstream of the first Receiver 1088 Proxy. This is seen as a very minor sub-optimality, however, to 1089 mitigate this, the Receiver Proxy MAY tear down any unanswered 1090 downstream Path state after a predetermined time (that SHOULD be 1091 greater or equal to the Path refresh interval), and MAY stop sending 1092 Path messages for the flow (or MAY only send them at much lower 1093 frequency). 1095 This approach only requires support of the behavior described in the 1096 previous paragraph and does not require any new RSVP extensions. 1098 4.2. Receiver Proxy Control Policy Element 1100 [RFC2750] defines extensions for supporting generic policy based 1101 admission control in RSVP. These extensions include the standard 1102 format of POLICY_DATA objects and a description of RSVP handling of 1103 policy events. 1105 The POLICY_DATA object contains one or more of Policy Elements, each 1106 representing a different (and perhaps orthogonal) policy. As an 1107 example, [RFC3181] specifies the Preemption Priority Policy Element. 1109 The present document defines a new Policy Element called the Receiver 1110 Proxy Control Policy Element. The present document only defines the 1111 use of this Policy Element in Path messages and for unicast 1112 reservations. Other usage are outside the scope of the present 1113 document. 1115 The format of the Receiver Proxy Control Policy Element is as shown 1116 in Figure 7: 1118 0 0 0 1 1 2 2 3 1119 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 1120 +-------------+-------------+-------------+-------------+ 1121 | Length | P-Type=REC_PROXY_CONTROL | 1122 +-------------+-------------+-------------+-------------+ 1123 | Reserved |Control-Value| 1124 +---------------------------+---------------------------+ 1126 Figure 7: Receiver Proxy Control Policy Element 1128 where: 1130 o Length: 16 bits 1132 * Always 8. The overall length of the policy element, in bytes. 1134 o P-Type: 16 bits 1136 * REC_PROXY_CONTROL = To be allocated by IANA (see "IANA 1137 Considerations" section) 1139 o Reserved: 24 bits 1141 * SHALL be set to zero on transmit and SHALL be ignored on 1142 reception 1144 o Control-Value: 8 bits (unsigned) 1146 * 0 (Reserved). An RSVP Receiver Proxy that understands this 1147 policy element MUST ignore the policy element if its Control- 1148 Value is set to that value. 1150 * 1 (Receiver-Proxy-Needed): An Receiver Proxy that understands 1151 this policy element MUST attempt to insert itself as a Receiver 1152 Proxy for that flow if the corresponding Path message contains 1153 this Control-Value. If the Receiver Proxy also supports 1154 dynamic discovery of downstream RSVP functionality as specified 1155 in Section 4.1, it MUST still send the Path message downstream 1156 and attempt to extend the reservation downstream so that the 1157 reservation can be extended to the last Receiver Proxy). An 1158 RSVP sender MAY insert the Receiver Proxy Control Policy 1159 Element with this Control-Value when it knows (say by other 1160 means such as application-level signalling) that the receiver 1161 is not RSVP capable. 1163 * 2 (Receiver-Proxy-Not-Needed): An Receiver Proxy that 1164 understands this policy element MUST NOT attempt to insert 1165 itself as a Receiver Proxy for that flow if the corresponding 1166 Path message contains this Control-Value. An RSVP sender MAY 1167 insert the Receiver Proxy Control Policy Element with this 1168 Control-Value when it knows (say by other means such as 1169 application-level signalling) that the receiver is RSVP 1170 capable. 1172 Figure 8 illustrates the method based on the Receiver Proxy Control 1173 Policy Element and allowing a sender to control whether an RSVP 1174 router supporting the Path-triggered Receiver Proxy function is to 1175 behave as a Receiver Proxy for a given flow or not. 1177 |****| *** |**********| |----| 1178 | S |---------*r*---------| RSVP |---| R1 | 1179 |****| *** | Receiver | |----| 1180 | Proxy | 1181 | | 1182 | | |****| 1183 | |------------| R2 | 1184 |**********| |****| 1186 ---Path---> --Path---> 1187 (R1/N) (R1/N) 1189 <--Resv--- <---Resv--- 1191 ================RSVP===> 1193 **************************************> 1195 ---Path---> --Path---> ----Path----> 1196 (R2/NN) (R2/NN) (R2/NN) 1198 <--Resv--- <---Resv--- <----Resv---- 1200 ================RSVP===========================> 1202 ***********************************************> 1204 |****| RSVP-capable |----| non-RSVP-capable |****| RSVP-capable 1205 | S | Sender | R | Receiver | R | Receiver 1206 |****| |----| |****| 1208 *** 1209 *r* regular RSVP 1210 *** router 1211 (R1) = Path message contains a Session object whose destination is R1 1213 (N) = Path message contains a Receiver Proxy Control Policy Element 1214 whose Control-Value is set to Receiver-Proxy-Needed 1216 (NN) = Path message contains a Receiver Proxy Control Policy Element 1217 whose Control-Value is set to Receiver-Proxy-Not-Needed 1219 ***> media flow 1221 ==> segment of flow path protected by RSVP reservation 1223 Figure 8: Receiver Proxy Control by Sender 1225 4.2.1. Default Handling 1227 As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes 1228 (PINs) implement a default handling of POLICY_DATA objects ensuring 1229 that those objects can traverse PIN nodes in transit from one Policy 1230 Enforcement Point (PEP) to another. This applies to the situations 1231 where POLICY_DATA objects contain the Receiver Proxy Control Policy 1232 Element specified in this document, so that those can traverse PIN 1233 nodes. 1235 Section 4.2 of [RFC2750] also defines a similar default behavior for 1236 policy-capable nodes that do not recognized a particular Policy 1237 Element. This applies to the Receiver Proxy Control Policy Element 1238 specified in this document, so that those can traverse policy-capable 1239 nodes that do not support this document. 1241 5. Security Considerations 1243 As this document defines extensions to RSVP, the security 1244 considerations of RSVP apply. Those are discussed in [RFC2205], 1245 [RFC4230] and [I-D.ietf-tsvwg-rsvp-security-groupkeying]. Approaches 1246 for addressing those concerns are discussed further below. 1248 The RSVP Authentication mechanisms defined in [RFC2747] and [RFC3097] 1249 protect RSVP message integrity hop-by-hop and provide node 1250 authentication as well as replay protection, thereby protecting 1251 against corruption and spoofing of RSVP messages. These hop-by-hop 1252 integrity mechanisms can be used to protect RSVP reservations 1253 established using an RSVP receiver proxy in accordance with the 1254 present document. [I-D.ietf-tsvwg-rsvp-security-groupkeying] 1255 discusses key types and key provisioning methods as well as their 1256 respective applicability to RSVP authentication. RSVP Authentication 1257 (defined in [RFC2747] and [RFC3097]) SHOULD be supported by an 1258 implementation of the present document. 1260 [I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses 1261 applicability of IPsec mechanisms ([RFC4302], [RFC4303]) and 1262 associated key provisioning methods for security protection of RSVP. 1263 This discussion applies to the protection of RSVP in the presence of 1264 Path-triggered RSVP Receiver Proxies as defined in the present 1265 document. 1267 A subset of RSVP messages are signaled with the router alert option 1268 ([RFC2113],[RFC2711]). Based on the current security concerns 1269 associated with the use of the IP router alert option, the 1270 applicability of RSVP (and therefore of the RSVP Proxy approaches 1271 discussed in the present document) is limited to controlled 1272 environments (i.e. Environments where the security risks associated 1273 with the use of the router alert option are understood and protected 1274 against). The security aspects and common practices around the use 1275 of the current IP router alert option and consequences of using the 1276 IP router alert option by applications such as RSVP are discussed in 1277 details in [I-D.rahman-rtg-router-alert-considerations]. 1279 When an RSVP receiver proxy is used, the RSVP reservation is no 1280 longer controlled by the receiver, but rather is controlled by the 1281 receiver proxy (using hints received from the sender in the Path 1282 message) on behalf of the sender. Thus, the receiver proxy ought to 1283 be trusted by the end-systems to control the RSVP reservation 1284 appropriately. However, basic RSVP operation already assumes a trust 1285 model where end-systems trust RSVP nodes to appropriately perform 1286 RSVP reservations. So the use of RSVP receiver proxy is not seen as 1287 introducing any significant additional security threat or as 1288 modifying the RSVP trust model. 1290 In fact, there are situations where the use of RSVP receiver proxy 1291 reduces the security risks. One example is where a network operator 1292 relies on RSVP to perform resource reservation and admission control 1293 within a network and where RSVP senders and RSVP routers are located 1294 in the operator premises while the many RSVP receivers are located in 1295 the operator's customers premises. Such an environment is further 1296 illustrated in "Annex A.1. RSVP-based VoD Admission Control in 1297 Broadband Aggregation Networks" of 1298 [I-D.ietf-tsvwg-rsvp-proxy-approaches]. From the operator's 1299 perspective, the RSVP routers and RSVP senders are in physically 1300 secured locations and therefore exposed to a lower risk of being 1301 tampered with; While the receivers are in locations that are 1302 physically unsecured and therefore subject to a higher risk of being 1303 tampered with. The use of an RSVP receiver proxy function 1304 effectively increases the security of the operator's reservation and 1305 admission control solution by completely excluding receivers from its 1306 operation. Filters can be placed at the edge of the operator network 1307 discarding any RSVP message received from end-users. This provides a 1308 very simple and effective protection of the RSVP reservation and 1309 admission control solution operating inside the operator's network. 1311 5.1. Security Considerations for the Sender Notification via Notify 1312 Message 1314 This document defines in Section 3.2 an optional method relying on 1315 the use of the Notify message specified in [RFC3473]. The Notify 1316 message can be sent in a non-hop-by-hop fashion that precludes use of 1317 RSVP hop-by-hop integrity and authentication model. The approaches 1318 and considerations for addressing this issue presented in the 1319 Security Considerations section of [RFC3473] apply. In particular, 1320 where the Notify messages are transmitted non-hop-by-hop and the same 1321 level of security provided by [RFC2747] is desired, IPsec-based 1322 integrity and authentication can be used ([RFC4302] or [RFC4303]). 1323 Alternatively, the sending of non-hop-by-hop Notify messages can be 1324 disabled. Finally, [I-D.ietf-tsvwg-rsvp-security-groupkeying] 1325 discusses applicability of group keying for non-hop-by-hop Notify 1326 messages. 1328 5.2. Security Considerations for the Receiver Proxy Control Policy 1329 Element 1331 This document also defines inSection 4.2 the optional Receiver Proxy 1332 Control Policy Element. Policy Elements are signaled by RSVP through 1333 encapsulation in a Policy Data object as defined in [RFC2750]. 1334 Therefore, like any other Policy Elements, the integrity of the 1335 Receiver Proxy Control Policy Element can be protected as discussed 1336 in section 6 of [RFC2750] by two optional security mechanisms. 1338 The first mechanism relies on the RSVP Authentication discussed above 1339 that provides a chain of trust when all RSVP nodes are policy 1340 capable. With this mechanism, the INTEGRITY object is carried inside 1341 RSVP messages. 1343 The second mechanism relies on the INTEGRITY object within the 1344 POLICY_DATA object to guarantee integrity between RSVP Policy 1345 Enforcement Points (PEPs) that are not RSVP neighbors. This is 1346 useful only when some RSVP nodes are Policy Ignorant Nodes (PINs). 1347 The INTEGRITY object within the POLICY_DATA object MAY be supported 1348 by an implementation of the present document. 1350 Details for computation of the content of the INTEGRITY object can be 1351 found in Appendix B of [RFC2750]. This states that the Policy 1352 Decision Point (PDP), at its discretion, and based on destination 1353 PEP/PDP or other criteria, selects an Authentication Key and the hash 1354 algorithm to be used. Keys to be used between PDPs can be 1355 distributed manually or via standard key management protocol for 1356 secure key distribution. 1358 Note that where non-RSVP hops may exist in between RSVP hops, as well 1359 as where RSVP capable Policy Ignorant Nodes (PINs) may exist in 1360 between PEPs, it may be difficult for the PDP to determine what is 1361 the destination PDP for a POLICY_DATA object contained in some RSVP 1362 messages (such as a Path message). This is because in those cases 1363 the next PEP is not known at the time of forwarding the message. In 1364 this situation, key shared across multiple PDPs may be used. This is 1365 conceptually similar to the use of key shared across multiple RSVP 1366 neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying]. 1367 We observe also that this issue may not exist in some deployment 1368 scenarios where a single (or low number of) PDP is used to control 1369 all the PEPs of a region (such as an administrative domain). In such 1370 scenarios, it may be easy for a PDP to determine what is the next hop 1371 PDP, even when the next hop PEP is not known, simply by determining 1372 what is the next region that will be traversed (say based on the 1373 destination address). 1375 6. IANA Considerations 1377 6.1. RSVP Error Codes 1379 Since, as discussed in Section 3.1.2, this document allows two Error 1380 Codes to be used in PathErr messages while [RFC2205] only specified 1381 their use in ResvErr messages, this document requires that IANA 1382 updates the existing entries for these two Error Codes under the 1383 "Error Codes and Globally-Defined Error Value Sub-Codes" registry. 1384 Each entry should refer to this document, in addition to referring to 1385 [RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2 1386 should respectively read: 1388 " 1390 1 Admission Control Failure [RFC2205] [RFCXXX] 1392 ... 1394 2 Policy Control Failure [RFC2205] [RFCXXX] 1396 ... 1398 " 1400 where [RFCXXX] refers to this document. 1402 This document also requires that IANA allocates a new RSVP Error Code 1403 ": Unrecoverable Receiver Proxy Error", as discussed in 1404 Section 3.1.2. This Error Code is to be allocated under the "Error 1405 Codes and Globally-Defined Error Value Sub-Codes" registry. The 1406 entry for this error code should read: 1408 " 1410 TBD Unrecoverable Receiver Proxy Error [RFCXXX] 1412 The sixteen bits of the Error Value field are defined in [RFCXXX] 1414 " 1416 where [RFCXXX] refers to this document and TBD is the value to be 1417 allocated by IANA. 1419 6.2. Policy Element 1421 This document defines in Section 4.2 a new Policy Element called the 1422 Receiver Proxy Control Policy Element. As specified in [RFC2750], 1423 Standard RSVP Policy Elements (P-type values) are to be assigned by 1424 IANA as per "IETF Consensus" policy following the policies outlined 1425 in [RFC2434] (this policy is now called "IETF Review" as per 1426 [RFC5226]) . 1428 Thus, this document requires that IANA allocates one P-Type to the 1429 Receiver Proxy Control Policy Element from the Standard RSVP Policy 1430 Element range. 1432 In Section 4.2, the present document defines a Control-Value field 1433 inside the Receiver Proxy Control Policy Element. IANA needs to 1434 create a registry for this field and allocate the following values: 1436 o 0 : Reserved 1438 o 1 : Receiver-Proxy-Needed 1440 o 2 : Receiver-Proxy-Not-Needed 1442 Following the policies outlined in [RFC5226], numbers in the range 1443 3-127 are allocated according to the "IETF Review" policy, numbers in 1444 the range 128-240 as "First Come First Served" and numbers between 1445 241-255 are reserved for "Private Use". 1447 7. Acknowledgments 1449 This document benefited from discussions with Carol Iturralde and 1450 Anca Zamfir. Lou Berger, Adrian Farrel and John Drake provided 1451 review and guidance, in particular on the usage of the 1452 Path_State_Removed flag and of the Notify message, both borrowed from 1453 [RFC3473]. We also thank Stephen Kent, Ken Carlberg and Tim Polk for 1454 their valuable input and proposed enhancements. Finally we thank 1455 Cullen Jennings, Magnus Westerlund and Robert Sparks for stimulating 1456 the work on extensions maximizing the reservation span and 1457 facilitating migration from Proxy model to end-to-end RSVP model. 1459 8. References 1461 8.1. Normative References 1463 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 1464 February 1997. 1466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1467 Requirement Levels", BCP 14, RFC 2119, March 1997. 1469 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1470 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1471 Functional Specification", RFC 2205, September 1997. 1473 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1474 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1475 October 1998. 1477 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1478 RFC 2711, October 1999. 1480 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1481 Authentication", RFC 2747, January 2000. 1483 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 1484 RFC 2750, January 2000. 1486 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 1487 Authentication -- Updated Message Type Value", RFC 3097, 1488 April 2001. 1490 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1491 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1492 Tunnels", RFC 3209, December 2001. 1494 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1495 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1496 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1498 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1499 December 2005. 1501 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1502 RFC 4303, December 2005. 1504 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1505 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1506 May 2008. 1508 8.2. Informative References 1510 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 1511 Faucheur, F., Guillou, A., Manner, J., and D. Wing, "RSVP 1512 Proxy Approaches", 1513 draft-ietf-tsvwg-rsvp-proxy-approaches-08 (work in 1514 progress), October 2009. 1516 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 1517 Behringer, M. and F. Faucheur, "Applicability of Keying 1518 Methods for RSVP Security", 1519 draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in 1520 progress), June 2009. 1522 [I-D.rahman-rtg-router-alert-considerations] 1523 Faucheur, F., "IP Router Alert Considerations and Usage", 1524 draft-rahman-rtg-router-alert-considerations-03 (work in 1525 progress), October 2009. 1527 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 1528 RFC 3181, October 2001. 1530 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 1531 Properties", RFC 4230, December 2005. 1533 Authors' Addresses 1535 Francois Le Faucheur 1536 Cisco Systems 1537 Greenside, 400 Avenue de Roumanille 1538 Sophia Antipolis 06410 1539 France 1541 Phone: +33 4 97 23 26 19 1542 Email: flefauch@cisco.com 1544 Jukka Manner 1545 Helsinki University of Technology (TKK) 1546 P.O. Box 3000 1547 Espoo FIN-02015 TKK 1548 Finland 1550 Phone: +358 9 451 2481 1551 Email: jukka.manner@tkk.fi 1552 URI: http://www.netlab.tkk.fi/~jmanner/ 1554 Ashok Narayanan 1555 Cisco Systems 1556 300 Beaver Brook Road 1557 Boxborough, MAS 01719 1558 United States 1560 Email: ashokn@cisco.com 1562 Allan Guillou 1563 SFR 1564 40-42 Quai du Point du Jour 1565 Boulogne-Billancourt, 92659 1566 France 1568 Email: allan.guillou@sfr.com 1569 Hemant Malik 1570 Bharti Airtel Ltd. 1571 4th Floor, Tower A, Unitech Cyber Park 1572 Gurgaon, Sector 39, 122001 1573 India 1575 Email: Hemant.Malik@airtel.in