idnits 2.17.1 draft-ietf-tsvwg-rsvp-proxy-proto-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 946. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 957. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 964. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 970. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 11, 2007) is 6042 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 841, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 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 Intended status: Standards Track J. Manner 5 Expires: April 13, 2008 University of Helsinki 6 A. Narayanan 7 Cisco 8 A. Guillou 9 Neuf 10 H. Malik 11 Bharti 12 October 11, 2007 14 RSVP Extensions for Path-Triggered RSVP Receiver Proxy 15 draft-ietf-tsvwg-rsvp-proxy-proto-02.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 13, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 RSVP signaling can be used to make end-to-end resource reservations 49 in an IP network in order to guarantee the QoS required by certain 50 flows. With conventional RSVP, both the data sender and receiver of 51 a given flow take part in RSVP signaling. Yet, there are many use 52 cases where resource reservation is required, but the receiver, the 53 sender, or both, is not RSVP-capable. Where the receiver is not 54 RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy 55 thereby performing RSVP signaling on behalf of the receiver. This 56 allows resource reservations to be established on the segment of the 57 end-to-end path from the sender to the RSVP Receiver Proxy. However, 58 as discussed in the companion document presenting RSVP Proxy 59 approaches, RSVP extensions are needed to facilitate operations with 60 an RSVP Receiver Proxy whose signaling is triggered by receipt of 61 RSVP Path messages from the sender. This document specifies these 62 extensions. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. RSVP Extensions for Sender Notification . . . . . . . . . . . 7 70 3.1. Sender Notification via PathErr Message . . . . . . . . . 10 71 3.1.1. Composition of SESSION and . . . . 12 72 3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 13 73 3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 14 74 3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 15 75 3.2. Sender Notification via Notify Message . . . . . . . . . . 16 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 80 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24 81 7.2. Informative References . . . . . . . . . . . . . . . . . . 24 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 83 Intellectual Property and Copyright Statements . . . . . . . . . . 27 85 1. Introduction 87 Guaranteed QoS for some applications with tight Qos requirements may 88 be achieved by reserving resources in each node on the end-to-end 89 path. The main IETF protocol for these resource reservations is RSVP 90 specified in [RFC2205]. RSVP does not require that all intermediate 91 nodes support RSVP, but it assumes that both the sender and the 92 receiver of the data flow support RSVP. However, there are 93 environments where it would be useful to be able to reserve resources 94 for a flow (at least a subset of the flow path) even when the sender 95 or the receiver (or both) is not RSVP-capable. 97 Since both the data sender and receiver may be unaware of RSVP, there 98 are two distinct RSVP Proxy cases. In the first case, an entity in 99 the network must operate on behalf of the data sender, generate RSVP 100 Path messages, and eventually receive, process and sink Resv 101 messages. We refer to this entity as the RSVP Sender Proxy. In the 102 second case, an entity in the network must receive Path messages sent 103 by a data sender (or by an RSVP Sender Proxy), and reply to those 104 with Resv messages generated on behalf of the data receiver(s). We 105 refer to this entity as the RSVP Receiver Proxy. 107 RSVP Proxy approaches are presented in 108 [I-D.ietf-tsvwg-rsvp-proxy-approaches]. That document also 109 discusses, for each approach, how the reservations controlled by the 110 RSVP Proxy can be synchronised with the application requirements 111 (e.g. when to establish, maintain and tear down the RSVP reservation 112 to satisfy application requirements). 114 One RSVP Proxy approach is referred to as the Path-Triggered RSVP 115 Receiver Proxy approach. With this approach, the RSVP Receiver Proxy 116 uses the RSVP Path messages generated by the sender (or RSVP Sender 117 Proxy) as the cue for establishing the RSVP reservation on behalf of 118 the non-RSVP-capable receiver. The RSVP Receiver Proxy is 119 effectively acting as an intermediary making reservations (on behalf 120 of the receiver) under the sender's control (or RSVP Sender Proxy's 121 control). This changes somewhat the usual RSVP reservation model 122 where reservations are normally controlled by receivers. Such a 123 change greatly facilitates operations in the scenario of interest 124 here, which is where the receiver is not RSVP-capable. Indeed it 125 allows the RSVP Receiver Proxy to remain application unaware by 126 taking advantage of the application awareness and RSVP awareness of 127 the sender (or RSVP Sender Proxy). 129 Since the synchronisation between RSVP reservation and application 130 requirement is now effectively performed by the sender (or RSVP 131 Sender Proxy), it is important that the sender (or RSVP Sender Proxy) 132 is aware of the reservation state. However, as conventional RSVP 133 assumes that the reservation is to be controlled by the receiver, 134 some notifications about reservation state (notably the error message 135 sent in case of admission control rejection of the reservation) are 136 only sent towards the receiver and therefore, in our case, sunk by 137 the RSVP Receiver Proxy. This document specifies extension to RSVP 138 procedures allowing such notifications to be also conveyed towards 139 the sender. This facilitates synchronization by the sender (or RSVP 140 Sender Proxy) between RSVP reservation and application requirements 141 in scenarios involving a Path-Triggered RSVP receiver Proxy. 143 This document discusses extension to facilitate operations in the 144 presence of an RSVP Receiver Proxy. As explicitely pointed out in 145 the text above, those apply equally whether RSVP signaling is 146 initiated by a regular RSVP sender or by an RSVP Sender Proxy (with 147 some means to synchronize reservation state with application level 148 requirements that are outside the scope of this document). For 149 readability, the rest of this document discusses operation assuming a 150 regular RSVP sender; however, such operation is equallly applicable 151 where an RSVP Sender Proxy is used to initiated RSVP signaling on 152 behalf of a non-RSVP-capable sender. 154 1.1. Conventions Used in This Document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 2. Terminology 162 The following terminology is borrowed from 163 [I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the 164 present document: 166 o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per 167 [RFC2205] 169 o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf 170 of a receiver, the RSVP operations which would normally be 171 performed by an RSVP-capable receiver if end-to-end RSVP signaling 172 was used. Note that while RSVP is used upstream of the RSVP 173 Receiver Proxy, RSVP is not used downstream of the RSVP Receiver 174 Proxy. 176 o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of 177 a sender, the RSVP operations which would normally be performed by 178 an RSVP-capable sender if end-to-end RSVP signaling was used. 179 Note that while RSVP is used downstream of the RSVP Sender Proxy, 180 RSVP is not used upstream of the RSVP Sender Proxy. 182 o Regular RSVP Router: an RSVP-capable router which is not behaving 183 as a RSVP Receiver Proxy nor as a RSVP Sender Proxy. 185 o Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, 186 Regular RSVP Router are all relative to one unidirectional flow. 187 A given router may act as the RSVP Receiver Proxy for a flow, as 188 the RSVP Sender Proxy for another flow and as a Regular RSVP 189 router for yet another flow. 191 The following terminology is also used in the present document: 193 o Regular RSVP Sender: an RSVP-capable host behaving as the sender 194 for the considered flow and participating in RSVP signaling in 195 accordance with the sender behavior specified in [RFC2205]. 197 o Regular RSVP Receiver: an RSVP-capable host behaving as the 198 receiver for the considered flow and participating in RSVP 199 signaling in accordance with the receiver behavior specified in 200 [RFC2205]. 202 3. RSVP Extensions for Sender Notification 204 This section defines extensions to RSVP procedures allowing sender 205 notification of reservation failure. This facilitates 206 synchronization by the sender between RSVP reservation and 207 application requirements in scenarios involving a Path-Triggered RSVP 208 Receiver Proxy. 210 As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], with the 211 Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be 212 configured to use receipt of a regular RSVP Path message as the 213 trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP 214 Path message, the RSVP Receiver Proxy: 216 1. establishes the RSVP Path state as per regular RSVP processing 218 2. identifies the downstream interface towards the receiver 220 3. sinks the Path message 222 4. behaves as if a Resv message (whose details are discussed below) 223 was received on the downstream interface. This includes 224 performing admission control on the downstream interface, 225 establishing a Resv state (in case of successful admission 226 control) and forwarding the Resv message upstream, sending 227 periodic refreshes of the Resv message and tearing down the 228 reservation if the Path state is torn down. 230 Operation of the Path-Triggered Receiver Proxy in the case of a 231 successful reservation is illustrated in Figure 1. 233 |----| *** *** *** |----------| |----| 234 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 235 |----| *** *** *** | Receiver | |----| 236 | Proxy | 237 |----------| 239 ************************************************************> 241 ===================RSVP===================> 243 --Path---> --Path---> --Path---> --Path---> 245 <---Resv-- <---Resv-- <---Resv-- <---Resv-- 247 |----| RSVP-capable |----| Non-RSVP-capable *** 248 | S | Sender | R | Receiver *r* regular RSVP 249 |----| |----| *** router 251 ***> media flow 253 ==> segment of flow path protected by RSVP reservation 255 Figure 1: Successful Reservation 257 We observe that, in the case of successful reservation, conventional 258 RSVP procedures ensure that the sender is notified of the successful 259 reservation establishment. Thus, no extensions are required in the 260 presence of a Path-Triggered RSVP Receiver Proxy in the case of 261 successful reservation establishment. 263 However, in case of reservation failure, conventional RSVP procedures 264 only ensure that the receiver (or the RSVP Receiver Proxy) is 265 notified of the reservation failure. Specifically, in case of an 266 admission control rejection on a regular RSVP router, a ResvErr 267 message is sent downstream towards the receiver. In the presence of 268 an RSVP Receiver Proxy, if we simply follow conventional RSVP 269 procedures, this means that the RSVP Receiver Proxy is notified of 270 the reservation failure, but the sender is not. Operation of the 271 Path-Triggered RSVP Receiver Proxy in the case of an admission 272 control failure, assuming conventional RSVP procedures, is 273 illustrated in Figure 2. 275 |----| *** *** *** |----------| |----| 276 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 277 |----| *** *** *** | Receiver | |----| 278 | Proxy | 279 |----------| 281 ************************************************************> 283 ===================RSVP===================> 285 --Path---> --Path---> --Path---> --Path---> 287 <---Resv-- <---Resv-- 289 -ResvErr-> -ResvErr-> 291 |----| |----| *** 292 | S | Sender | R | Receiver *r* regular RSVP 293 |----| |----| *** router 295 ***> media flow 297 ==> segment of flow path protected by RSVP reservation 299 Figure 2: Reservation Failure With Conventional RSVP 301 While the sender could infer reservation failure from the fact that 302 it has not received a Resv message after a certain time, there are 303 clear benefits in ensuring that the sender gets a prompt explicit 304 notification in case of reservation failure. This includes faster 305 enduser notification at application layer (e.g. busy signal), faster 306 application level reaction (e.g. application level rerouting), as 307 well as faster release of application-level resources. 309 Section 3.1 defines a method which can be used to achieve sender 310 notification of reservation failure. A router implementation 311 claiming compliance with this document MUST support the method 312 defined in Section 3.1. 314 Section 3.2 defines another method which can be used to achieve 315 sender notification of reservation failure. A router implementation 316 claiming compliance with this document MAY support the method defined 317 in Section 3.2. 319 In a given network environment, a network administrator may elect to 320 use the method defined in Section 3.1, or the method defined in 321 Section 3.2, or possibly combine the two. 323 3.1. Sender Notification via PathErr Message 325 With this method, the RSVP Receiver Proxy MUST generate a PathErr 326 message whenever the two following conditions are met: 328 1. The reservation establishment has failed (or the previously 329 established reservation has been torn down) 331 2. The RSVP Receiver Proxy determines that it cannot re-establish 332 the reservation (e.g. by adapting its reservation request in 333 reaction to the error code provided in the received ResvErr in 334 accordance with local policy) 336 Note that this notion of generating a PathErr message upstream in 337 order to notify the sender about a reservation failure is not 338 completely new. It is borrowed from [RFC3209] where it has been 339 introduced in order to achieve a similar requirement, which is to 340 allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end 341 (i.e. the sender) of a failure to establish (or maintain) a TE Tunnel 342 Label Switch Path. 344 Operation of the Path-Triggered RSVP Receiver Proxy in the case of an 345 admission control failure, using sender notification via PathErr 346 Message, is illustrated in Figure 3. 348 |----| *** *** *** |----------| |----| 349 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 350 |----| *** *** *** | Receiver | |----| 351 | Proxy | 352 |----------| 354 ************************************************************> 356 ===================RSVP===================> 358 --Path---> --Path---> --Path---> --Path---> 360 <---Resv-- <---Resv-- 362 -ResvErr-> -ResvErr-> 364 <-PathErr- <-PathErr- <-PathErr- <-PathErr- 366 |----| |----| *** 367 | S | Sender | R | Receiver *r* regular RSVP 368 |----| |----| *** router 370 ***> media flow 372 ==> segment of flow path protected by RSVP reservation 374 Figure 3: Reservation Failure With Sender Notification via PathErr 376 The role of this PathErr is to notify the sender that the reservation 377 was not established or was torn down. This may be in the case of 378 receipt of a ResvErr, or because of local failure on the Receiver 379 Proxy. On receipt of a ResvErr, in all situations where the 380 reservation cannot be installed, the Receiver Proxy MUST generate a 381 PathErr towards the sender. For local failures on the Receiver Proxy 382 node, if a similar failure on an RSVP midpoint would cause the 383 generation of a ResvErr (for example, CAC failure), the Receiver 384 Proxy MUST generate a PathErr towards the sender. The Receiver Proxy 385 MAY additionally generate a PathErr upon local failures which would 386 not ordinarily cause generation of a ResvErr message, such as 387 described in Appendix B of [RFC2205]. 389 The PathErr generated by the Receiver Proxy corresponds to the 390 sender(s) which triggered generation of Resv messages that failed. 391 For Fixed-Filter (FF) style reservations, the Receiver Proxy sends a 392 PathErr towards the (single) sender matching the failed reservation. 394 For Shared-Explicit (SE) style reservations, the Receiver Proxy sends 395 the PathErr(s) towards the set of senders which triggered 396 reservations that failed. This may be a subset of senders sharing 397 the same reservation, in which case the remaining senders would have 398 their reservation intact and would not receive a PathErr. In both 399 cases, the rules described in Section 3.1.8 of [RFC2205] for 400 generating flow descriptors in ResvErr messages, also apply for 401 generating sender descriptors in PathErr messages. 403 For Wildcard-Filter (WF) style reservations, it is not possible for 404 the receiver to know which sender caused the reservation failure. 405 Therefore, the procedures described in this section do not apply to 406 WF-style reservations. 408 The procedures described in this section apply to both unicast and 409 multicast sessions. However, for a multicast session, it is possible 410 that reservation failure (e.g. admission control failure) in a node 411 close to a sender may cause ResvErr messages to be sent to a large 412 group of receivers. These receivers would, in turn, all send PathErr 413 messages back to the same sender, which could cause a scalability 414 issue in some environments. From the perspective of the sender, 415 errors that prevent a reservation from being set up can be classified 416 in two ways: 418 1. Errors which the sender can attempt to correct. The error code 419 for those errors should explicitly be communicated back to the 420 sender. An examples of this is "Class 1: Admission Control 421 Failure", because the sender could potentially resend a Path with 422 smaller traffic parameters. 424 2. Errors which the sender has no control over. For these errors, 425 it is sufficient to notify the sender that the reservation was 426 not set up successfully. An example of this is "Class 13: 427 Unknown Object", because the sender has no control over the 428 objects inserted into the reservation by the Receiver Proxy. 430 The PathErr message generated by the Receiver Proxy has the same 431 format as regular PathErr messages defined in [RFC2205]. The 432 SESSION, ERROR_SPEC and sender descriptor are composed by the 433 Receiver Proxy as specified in the following subsections. The 434 Receiver Proxy MAY reflect back towards the sender in the PathErr any 435 POLICY_DATA objects received in the ResvErr. 437 3.1.1. Composition of SESSION and 439 The Receiver Proxy MUST insert the SESSION object corresponding to 440 the failed reservation, into the PathErr. For Fixed-Filter (FF) 441 style reservations, the Receiver Proxy MUST insert a corresponding to the failed reservation, into the 443 PathErr. This is equal to the in the ResvErr 444 received by the Receiver Proxy. For Shared-Explicit (SE) style 445 reservations, the Receiver Proxy MUST insert a 446 corresponding to the sender triggering the failed reservation, into 447 the PathErr. This is equal to the in the ResvErr 448 received by the Receiver Proxy. If multiple could 449 not be admitted at a midpoint node, that node would generate multiple 450 ResvErrs messages towards the receiver as per Section 3.1.8 of 451 [RFC2205]. Each ResvErr would contain a that 452 matches a specific sender. The Receiver Proxy MUST generate a 453 PathErr for each ResvErr received, towards the corresponding sender. 455 3.1.2. Composition of ERROR_SPEC 457 The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into 458 the PathErr as follows: 460 1. If the Receiver Proxy receives a ResvErr with any of these error 461 codes: "Code 1 - Admission Control Failure" or "Code 2 - Policy 462 Control Failure" then the Receiver Proxy copies the error code 463 and value from the ERROR_SPEC in the ResvErr, into the ERROR_SPEC 464 of the PathErr message. The error node in the PathErr MUST be 465 set to the address of the Receiver Proxy. This procedure MUST 466 also be followed for a local error on the Receiver Proxy that 467 would ordinarily cause a midpoint to generate a ResvErr with one 468 of the above codes. 470 2. If the Receiver Proxy receives a ResvErr with any error code 471 other than the ones listed in 1 above, it composes a new 472 ERROR_SPEC with error code ": Unrecoverable Receiver Proxy Error". The error node in 474 the PathErr MUST be set to the address of the Receiver Proxy. 475 This procedure MUST also be followed for a local error on the 476 Receiver Proxy that would ordinarily cause a midpoint to generate 477 a ResvErr with any error code except than those listed in 1 478 above, or if the Receiver Proxy generates a PathErr for a local 479 error which ordinarily would not cause generation of a ResvErr. 480 In some cases it may be predetermined that the PathErr will not 481 reach the sender. For example, a node receiving a ResvErr with 482 "Code 3: No Path for Resv", knows a priori that the PathErr 483 message it generates cannot be forwarded by the same node which 484 could not process the Resv. Nevertheless, the procedures above 485 MUST be followed. For the error code ": Unrecoverable Receiver Proxy Error", the 487 16 bits of the Error Value field are: 489 * hhhh hhhh llll llll 491 where the bits are: 493 * hhhh hhhh = 0000 0000: then the low order 8 bits (llll llll) 494 MUST be set by Receiver Proxy to 0000 0000 and MUST be ignored 495 by the sender. 497 * hhhh hhhh = 0000 0001: then the low order 8 bits (llll llll) 498 MUST be set by the Receiver Proxy to the value of the error 499 code received in the ResvErr ERROR_SPEC (or, in case the 500 Receiver Proxy generated the PathErr without having received a 501 ResvErr, to the error code value that would have been included 502 by the Receiver Proxy in the ERROR_SPEC in similar conditions 503 if it was to generate a ResvErr). This error value MAY be 504 used by the sender to further interpret the reason of the 505 reservation failure. 507 * hhhh hhhh = any other value: reserved. 509 3. If the Receiver Proxy Receives a ResvErr with the InPlace flag 510 set in the ERROR_SPEC, it MUST also set the InPlace flag in the 511 ERROR_SPEC of the PathErr. 513 3.1.3. Use of Path_State_Removed Flag 515 [RFC3473] defines an optional behavior whereby a node forwarding a 516 PathErr message can remove the Path State associated with the PathErr 517 message and indicate so by including the Path_State_Removed flag in 518 the ERROR_SPEC object of the PathErr message. This can be used in 519 some situations to expedite release of resources and minimise 520 signaling load. 522 This section discusses aspects of the use of the Path_State_Removed 523 flag that are specific to the RSVP Receiver Proxy. In any other 524 aspects, the Path_State_Removed flag operates as per [RFC3473]. 526 By default, the RSVP Receiver Proxy MUST not include the 527 Path_State_Removed flag in the ERROR_SPEC of the PathErr message. 528 This ensures predictable operations in all environments including 529 those where some RSVP routers do not understand the 530 Path_State_Removed flag. 532 Optionally, the RSVP Receiver Proxy MAY support an optional mode that 533 can be activated by configuration whereby the RSVP Receiver Proxy 534 includes the Path_State_Removed flag in the ERROR_SPEC of the PathErr 535 message and removes its local Path state. Where all routers on the 536 path of a reservation support the Path_State_Removed flag, its use 537 will indeed result in expedited resource release and reduced 538 signaling. However, if there is one (or more) "old" router on the 539 path of the reservation that does not support the Path_State_Removed 540 flag, its use will actually result in slower resource release and 541 increased signaling. This is because the Path_State_Removed flag 542 will be propagated upstream by an "old" router (even if it does not 543 understand it and does not tear its Path state). Thus, the sender 544 will not send a Path Tear and the "old" router will only release its 545 Path state through refresh time-out. A network administrator needs 546 to keep these considerations in mind when deciding whether to 547 activate the use of the Path_State_Removed flag on the RSVP Receiver 548 Proxy. In a controlled environment where all routers are known to 549 support the Path_State_Removed flag, its use can be safely activated 550 on the RSVP Receiver Proxy. In other environments, the network 551 administrator needs to assess whether the improvement achieved with 552 some reservations outweighs the degradation experienced by other 553 reservations. 555 3.1.4. Use of PathErr by Regular Receivers 557 Note that while this document specifies that an RSVP Receiver Proxy 558 generates a PathErr upstream in case of reservation failure, this 559 document does NOT propose that the same be done by regular receivers. 560 In other words, this document does NOT propose to modify the behavior 561 of regular receivers as currently specified in [RFC2205]. The 562 rationale for this includes the following: 564 o when the receiver is RSVP capable, the current receiver-driven 565 model of [RFC2205] is fully applicable because the receiver can 566 synchronise RSVP reservation state and application state (since it 567 participates in both). The sender(s) needs not be aware of the 568 RSVP reservation state. Thus, we can retain the benefits of 569 receiver-driven operations which were explicitly sought by 570 [RFC2205]. Quoting from it: " In order to efficiently accommodate 571 large groups, dynamic group membership, and heterogeneous receiver 572 requirements, RSVP makes receivers responsible for requesting a 573 specific QoS". But even for the most simple single_sender/ 574 single_receiver reservations, the current receiver-driven model 575 reduces signaling load and per-hop RSVP processing by not sending 576 any error message to the sender in case of CAC reject. 578 o the motivation for adding sender error notification in case of 579 receiver proxy lies in the fact that the actual receiver can no 580 lomger synchronize RSVP reservation with application state (since 581 the receiver does not participate in RSVP signaling), while the 582 sender can. This motivation does not apply in case of regular 583 receiver. 585 o there is a lot of existing code and deployed systems successfully 586 working under the current [RFC2205] model in the absence of proxy 587 today. The current behavior should not be changed for those 588 unless there were a very strong motivation. 590 3.2. Sender Notification via Notify Message 592 The OPTIONAL method for sender notification of reservation failure 593 defined in this section aims at providing a more efficient method 594 than the one defined in Section 3.1. Its objectives include : 596 o allow the failure notification to be sent directly upstream to the 597 sender by the router where the failure occurs (as opposed to first 598 travelling downstream towards the Receiver Proxy and then 599 travelling upstream from the Receiver Proxy to the sender, as 600 effectively happens with the method defined in Section 3.1) 602 o allow the failure notification to travel directly to the sender 603 without hop-by-hop RSVP processing 605 o ensure that such a notification is only sent to senders which are 606 capable and willing to process it (i.e. to synchronize reservation 607 status with application) 609 o ensure that such a notification is only sent in case the receiver 610 is not itself capable and willing to do the synchronisation with 611 the application (i.e. because we are in the presence of a receiver 612 proxy so that RSVP signaling is not visible to the receiver) 614 Note, however, that such benefits come at the cost of more 615 sophistication and of a requirement for RSVP routers and senders to 616 support the Notify messages and procedures defined in [RFC3473]. 618 [RFC3473] defines (in section "4.3 Notify Messages") the Notify 619 message that provides a mechanism to inform non-adjacent nodes of 620 events related to the RSVP reservation. The Notify message differs 621 from the error messages defined in [RFC2205] (i.e., PathErr and 622 ResvErr messages) in that it can be "targeted" to a node other than 623 the immediate upstream or downstream neighbor and that it is a 624 generalized notification mechanism. Notify messages are normally 625 generated only after a Notify Request object has been received. 627 This section discusses aspects of the use of the Notify message that 628 are specific to the RSVP Receiver Proxy. In any other aspects, the 629 Notify message operates as per [RFC3473]. 631 In order to achieve sender notification of reservation failure in the 632 context of the present document: 634 o an RSVP sender interested in being notified of reservation failure 635 MUST include a Notify Request object (containing the sender's IP 636 address) in the Path messages it generates 638 o Upon receiving a Path message with a Notify Request object, the 639 RSVP Receiver Proxy MUST include a Notify Request object in the 640 Resv messages it generates. This Notify Request object MUST 641 contain the address that was included in the Notify Request of the 642 received Path message- a.k.a. the sender's address- and not an 643 address of the Receiver Proxy. 645 As a result, as per existing Notify procedures, if an RSVP router 646 detects an error relating to a Resv state (e.g. Admission Control 647 rejection after IP reroute), the RSVP router will send a Notify 648 message (conveying the Resv Err code) to the IP address contained in 649 the Resv Notify Request object. Since this address has been set to 650 the sender's address by the Receiver Proxy, the Notify message is 651 sent to the sender. 653 Operation of the Path-Triggered RSVP Receiver Proxy in the case of an 654 admission control failure, using sender notification via Notify 655 Message, is illustrated in Figure 4. 657 |----| *** *** *** |----------| |----| 658 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 659 |----| *** *** *** | Receiver | |----| 660 | Proxy | 661 |----------| 663 ************************************************************> 665 ===================RSVP===================> 667 --Path---> --Path---> --Path---> --Path---> 669 <---Resv-- <---Resv-- 671 <------Notify------- 672 -ResvErr-> -ResvErr-> 674 |----| |----| *** 675 | S | Sender | R | Receiver *r* regular RSVP 676 |----| |----| *** router 678 ***> media flow 680 ==> segment of flow path protected by RSVP reservation 682 Path* = Path message containing a Notify Request object 683 with sender IP Address 685 Resv* = Resv message containing a Notify Request object 686 with sender IP address 688 Notify = Notify message 690 Figure 4: Reservation Failure With Sender Notification via Notify 692 For local failures on the Receiver Proxy node, if a similar failure 693 on an RSVP midpoint would cause the generation of a ResvErr (for 694 example, CAC failure), the Receiver Proxy MUST generate a Notify 695 towards the sender. The Receiver Proxy MAY additionally generate a 696 Notify upon local failures which would not ordinarily cause 697 generation of a ResvErr message, such as described in Appendix B of 698 [RFC2205]. 700 4. Security Considerations 702 To ensure the integrity of the associated reservation and admission 703 control mechanisms, the RSVP Authentication mechanisms defined in 704 [RFC2747] and [RFC3097] may be used. These protect RSVP message 705 integrity hop-by-hop and provide node authentication as well as 706 replay protection, thereby protecting against corruption and spoofing 707 of RSVP messages. These hop-by-hop integrity mechanisms can be used 708 to protect the RSVP reservations established using an RSVP receiver 709 proxy in accordance with the present document. 711 [RFC2747] discusses several approaches for key distribution. First, 712 the RSVP Authentication shared keys can be distributed manually. 713 This is the base option and its support is mandated for any 714 implementation. However, in some environments, this approach may 715 become a burden if keys frequently change over time. Alternatively, 716 a standard key management protocol for secure key distribution can be 717 used. However, existing key distribution protocols may not be 718 appropriate in all environments because of the complexity or 719 operational burden they involve. 721 The use of RSVP Authentication in parts of the network where there 722 may be one or more IP hops in between two RSVP neighbors raises an 723 additional challenge. This is because, with some RSVP messages such 724 as a Path message, an RSVP router does not know the RSVP next hop for 725 that message at the time of forwarding it. In fact, part of the role 726 of a Path message is precisely to discover the RSVP next hop (and to 727 dynamically re-discover it when it changes, say because of a routing 728 change). Hence, the RSVP router may not know which security 729 association to use when forwarding such a message. In that 730 situation, one approach is to share the same RSVP Authentication 731 shared key across all the RSVP routers of a part of the network where 732 there may be RSVP neighbors with IP hops in between. For example, 733 all the RSVP routers of an administrative domain (including the 734 receiver proxys) could share the same RSVP Authentication key, while 735 different per-neighbor keys could be used between any RSVP router 736 pair straddling the boundary between two administrative domains that 737 have agreed to use RSVP signaling. 739 When the same RSVP Authentication shared key is to be shared among 740 multiple RSVP neighbors, manual key distribution may be used. It 741 might also be possible, in the future, to adapt a multicast dynamic 742 group key distribution method (e.g. from IETF Multicast Security 743 Working Group) for dynamic key distribution among RSVP nodes. This 744 is discussed in [I-D.behringer-tsvwg-rsvp-security-groupkeying]. For 745 situations where RSVP is being used for unicast flows across domain 746 boundaries, it is not currently clear how one might provide automated 747 key management. 749 The RSVP Authentication mechanisms do not provide confidentiality. 750 If confidentiality is required, IPsec ESP ([RFC4303]) may be used, 751 although it imposes the burden of key distribution. It also faces 752 the additional issue discussed for key management above in the case 753 where there can be IP hops in between RSVP hops. In the future, 754 confidentiality solutions may be developed for the case where there 755 can be IP hops in between RSVP hops, perhaps again by adapting 756 confidentiality solutions developed by the IETF MSEC Working Group. 757 Such confidentiality solutions for RSVP are outside the scope of this 758 document. 760 When an RSVP receiver proxy is used, the RSVP reservation is no 761 longer controlled by the receiver, but rather is controlled by the 762 receiver proxy (using hints received from the sender in the Path 763 message) on behalf of the sender. Thus, the receiver proxy ought to 764 be trusted by the end-systems to control the RSVP reservation 765 appropriately. However, basic RSVP operation already assumes a trust 766 model where end-systems trust RSVP nodes to appropriately perform 767 RSVP reservations. So the use of RSVP receiver proxy is not seen as 768 introducing any significant additional security threat or as 769 modifying the RSVP trust model. 771 In fact, there are situations where the use of RSVP receiver proxy 772 reduces the security risks. One example is where a network operator 773 relies on RSVP to perform resource reservation and admission control 774 within a network and where RSVP senders and RSVP routers are located 775 in the operator premises while the many RSVP receivers are located in 776 the operator's customers premises. Such an environment is further 777 illustrated in "Annex A.1. RSVP-based VoD CAC in Broadband 778 Aggregation Networks" of [I-D.ietf-tsvwg-rsvp-proxy-approaches]. 779 From the operator's perspective, the RSVP routers and RSVP senders 780 are in physically secured locations and therefore exposed to a lower 781 risk of being tampered with; While the receivers are in locations 782 which are physically unsecured and therefore subject to a higher risk 783 of being tampered with. The use of an RSVP receiver proxy function 784 effectively increases the security of the operator's reservation and 785 admission control solution by completely excluding receivers from its 786 operation. Filters can be placed at the edge of the operator network 787 discarding any RSVP message received from end-users. This provides a 788 very simple and effective protection of the RSVP reservation and 789 admission control solution operating inside the operator's network. 791 This document defines in Section 3.2 an optional method relying on 792 the use of the Notify message specified in [RFC3473]. The Notify 793 message can be sent in a non-hop-by-hop fashion that precludes RSVP's 794 hop-by-hop integrity and authentication model. The approaches and 795 considerations for addressing this issue presented in the Security 796 Considerations section of [RFC3473] apply. In particular, where the 797 Notify messages are transmitted non-hop-by-hop and the same level of 798 security provided by [RFC2747] is desired, the standard IPsec based 799 integrity and authentication can be used. Alternatively, the sending 800 of non-hop-by-hop Notify messages can be disabled. 802 5. IANA Considerations 804 Since, as discussed in Section 3.1.2, this document allows two Error 805 Codes to be used in PathErr messages while [RFC2205] only specified 806 their use in ResvErr messages, this document requires that IANA 807 updates the existing entries for these two Error Codes under the 808 "Error Codes and Globally-Defined Error Value Sub-Codes" registry. 809 Each entry should refer to this document, in addition to referring to 810 [RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2 811 should respectively read: 813 " 815 1 Admission Control Failure [RFC2205] [RFCXXX] 817 ... 819 2 Policy Control Failure [RFC2205] [RFCXXX] 821 ... 823 " 825 where [RFCXXX] refers to this document. 827 This document also requires that IANA allocates a new RSVP Error Code 828 ": Unrecoverable Receiver Proxy Error", as discussed in 829 Section 3.1.2. This Error Code is to be allocated under the "Error 830 Codes and Globally-Defined Error Value Sub-Codes" registry. The 831 entry for this error code should read: 833 " 835 TBD Unrecoverable Receiver Proxy Error [RFCXXX] 837 The sixteen bits of the Error Value field are defined in [RFCXXX] 839 " 841 where [RFCXXX] refers to this document and TBD is the value to be 842 allocated by IANA. 844 6. Acknowledgments 846 This document benefited from discussions with Carol Iturralde and 847 Amca Zamfir. 849 7. References 851 7.1. Normative References 853 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 854 Requirement Levels", BCP 14, RFC 2119, March 1997. 856 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 857 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 858 Functional Specification", RFC 2205, September 1997. 860 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 861 Authentication", RFC 2747, January 2000. 863 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 864 Authentication -- Updated Message Type Value", RFC 3097, 865 April 2001. 867 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 868 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 869 Tunnels", RFC 3209, December 2001. 871 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 872 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 873 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 875 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 876 RFC 4303, December 2005. 878 7.2. Informative References 880 [I-D.behringer-tsvwg-rsvp-security-groupkeying] 881 Behringer, M. and F. Le Faucheur, "A Framework for RSVP 882 Security Using Dynamic Group Keying", July 2007. 884 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 885 Le Faucheur, F., Manner, J., Wing, D., and A. Guillou, 886 "RSVP Proxy Approaches", July 2007. 888 Authors' Addresses 890 Francois Le Faucheur 891 Cisco Systems 892 Greenside, 400 Avenue de Roumanille 893 Sophia Antipolis 06410 894 France 896 Phone: +33 4 97 23 26 19 897 Email: flefauch@cisco.com 899 Jukka Manner 900 University of Helsinki 901 P.O. Box 68 902 University of Helsinki FIN-00014 University of Helsinki 903 Finland 905 Phone: +358 9 191 51298 906 Email: jmanner@cs.helsinki.fi 907 URI: http://www.cs.helsinki.fi/u/jmanner/ 909 Ashok Narayanan 910 Cisco Systems 911 300 Beaver Brook Road 912 Boxborough, MAS 01719 913 United States 915 Email: ashokn@cisco.com 917 Allan Guillou 918 Neuf Cegetel 919 40-42 Quai du Point du Jour 920 Boulogne-Billancourt, 92659 921 France 923 Email: allan.guillou@neufcegetel.fr 924 Hemant Malik 925 Bharti Airtel Ltd. 926 4th Floor, Tower A, Unitech Cyber Park 927 Gurgaon, Sector 39, 122001 928 India 930 Email: Hermant.Malik@airtel.in 932 Full Copyright Statement 934 Copyright (C) The IETF Trust (2007). 936 This document is subject to the rights, licenses and restrictions 937 contained in BCP 78, and except as set forth therein, the authors 938 retain all their rights. 940 This document and the information contained herein are provided on an 941 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 942 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 943 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 944 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 945 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 946 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 948 Intellectual Property 950 The IETF takes no position regarding the validity or scope of any 951 Intellectual Property Rights or other rights that might be claimed to 952 pertain to the implementation or use of the technology described in 953 this document or the extent to which any license under such rights 954 might or might not be available; nor does it represent that it has 955 made any independent effort to identify any such rights. Information 956 on the procedures with respect to rights in RFC documents can be 957 found in BCP 78 and BCP 79. 959 Copies of IPR disclosures made to the IETF Secretariat and any 960 assurances of licenses to be made available, or the result of an 961 attempt made to obtain a general license or permission for the use of 962 such proprietary rights by implementers or users of this 963 specification can be obtained from the IETF on-line IPR repository at 964 http://www.ietf.org/ipr. 966 The IETF invites any interested party to bring to its attention any 967 copyrights, patents or patent applications, or other proprietary 968 rights that may cover technology that may be required to implement 969 this standard. Please address the information to the IETF at 970 ietf-ipr@ietf.org. 972 Acknowledgment 974 Funding for the RFC Editor function is provided by the IETF 975 Administrative Support Activity (IASA).