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