idnits 2.17.1 draft-ietf-tsvwg-rsvp-proxy-proto-05.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 962. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 980. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 986. 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 (April 25, 2008) is 5837 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 854, but not defined -- No information found for draft-ietf-tsvwg-rsvp-proxy-approaches - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-tsvwg-rsvp-proxy-approaches' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 9 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: October 27, 2008 University of Helsinki 6 A. Narayanan 7 Cisco 8 A. Guillou 9 Neuf 10 H. Malik 11 Bharti 12 April 25, 2008 14 RSVP Extensions for Path-Triggered RSVP Receiver Proxy 15 draft-ietf-tsvwg-rsvp-proxy-proto-05.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 October 27, 2008. 42 Abstract 44 RSVP signaling can be used to make end-to-end resource reservations 45 in an IP network in order to guarantee the QoS required by certain 46 flows. With conventional RSVP, both the data sender and receiver of 47 a given flow take part in RSVP signaling. Yet, there are many use 48 cases where resource reservation is required, but the receiver, the 49 sender, or both, is not RSVP-capable. Where the receiver is not 50 RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy 51 thereby performing RSVP signaling on behalf of the receiver. This 52 allows resource reservations to be established on the segment of the 53 end-to-end path from the sender to the RSVP Receiver Proxy. However, 54 as discussed in the companion document presenting RSVP Proxy 55 approaches, RSVP extensions are needed to facilitate operations with 56 an RSVP Receiver Proxy whose signaling is triggered by receipt of 57 RSVP Path messages from the sender. This document specifies these 58 extensions. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. RSVP Extensions for Sender Notification . . . . . . . . . . . 7 66 3.1. Sender Notification via PathErr Message . . . . . . . . . 10 67 3.1.1. Composition of SESSION and . . . . 12 68 3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 13 69 3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 14 70 3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 15 71 3.2. Sender Notification via Notify Message . . . . . . . . . . 16 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 74 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 77 7.2. Informative References . . . . . . . . . . . . . . . . . . 25 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 79 Intellectual Property and Copyright Statements . . . . . . . . . . 28 81 1. Introduction 83 Guaranteed QoS for some applications with tight Qos requirements may 84 be achieved by reserving resources in each node on the end-to-end 85 path. The main IETF protocol for these resource reservations is RSVP 86 specified in [RFC2205]. RSVP does not require that all intermediate 87 nodes support RSVP, but it assumes that both the sender and the 88 receiver of the data flow support RSVP. However, there are 89 environments where it would be useful to be able to reserve resources 90 for a flow (at least a subset of the flow path) even when the sender 91 or the receiver (or both) is not RSVP-capable. 93 Since both the data sender and receiver may be unaware of RSVP, there 94 are two types of RSVP Proxies. In the first case, an entity in the 95 network needs to operate RSVP on behalf of the data sender and thus 96 generate RSVP Path messages, and eventually receive, process and sink 97 Resv messages. We refer to this entity as the RSVP Sender Proxy. In 98 the second case, an entity in the network need to operate RSVP on 99 behalf of the receiver and thus receive Path messages sent by a data 100 sender (or by an RSVP Sender Proxy), and reply to those with Resv 101 messages generated on behalf of the data receiver(s). We refer to 102 this entity as the RSVP Receiver Proxy. 104 RSVP Proxy approaches are presented in 105 [I-D.ietf-tsvwg-rsvp-proxy-approaches]. That document also 106 discusses, for each approach, how the reservations controlled by the 107 RSVP Proxy can be synchronised with the application requirements 108 (e.g. when to establish, maintain and tear down the RSVP reservation 109 to satisfy application requirements). 111 One RSVP Proxy approach is referred to as the Path-Triggered RSVP 112 Receiver Proxy approach. With this approach, the RSVP Receiver Proxy 113 uses the RSVP Path messages generated by the sender (or RSVP Sender 114 Proxy) as the cue for establishing the RSVP reservation on behalf of 115 the non-RSVP-capable receiver. The RSVP Receiver Proxy is 116 effectively acting as an intermediary making reservations (on behalf 117 of the receiver) under the sender's control (or RSVP Sender Proxy's 118 control). This changes somewhat the usual RSVP reservation model 119 where reservations are normally controlled by receivers. Such a 120 change greatly facilitates operations in the scenario of interest 121 here, which is where the receiver is not RSVP-capable. Indeed it 122 allows the RSVP Receiver Proxy to remain application unaware by 123 taking advantage of the application awareness and RSVP awareness of 124 the sender (or RSVP Sender Proxy). 126 Since the synchronisation between RSVP reservation and application 127 requirement is now effectively performed by the sender (or RSVP 128 Sender Proxy), it is important that the sender (or RSVP Sender Proxy) 129 is aware of the reservation state. However, as conventional RSVP 130 assumes that the reservation is to be controlled by the receiver, 131 some notifications about reservation state (notably the error message 132 sent in case of admission control rejection of the reservation) are 133 only sent towards the receiver and therefore, in our case, sunk by 134 the RSVP Receiver Proxy. This document specifies extension to RSVP 135 procedures allowing such notifications to be also conveyed towards 136 the sender. This facilitates synchronization by the sender (or RSVP 137 Sender Proxy) between RSVP reservation and application requirements 138 in scenarios involving a Path-Triggered RSVP receiver Proxy. 140 This document discusses extension to facilitate operations in the 141 presence of a Path-triggered RSVP Receiver Proxy. As explicitly 142 pointed out in the text above, those apply equally whether RSVP 143 signaling is initiated by a regular RSVP sender or by an RSVP Sender 144 Proxy (with some means to synchronize reservation state with 145 application level requirements that are outside the scope of this 146 document). For readability, the rest of this document discusses 147 operation assuming a regular RSVP sender; however, such operation is 148 equally applicable where an RSVP Sender Proxy is used to initiated 149 RSVP signaling on behalf of a non-RSVP-capable sender. 151 1.1. Conventions Used in This Document 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 2. Terminology 159 The following terminology is borrowed from 160 [I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the 161 present document: 163 o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per 164 [RFC2205] 166 o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf 167 of a receiver, the RSVP operations which would normally be 168 performed by an RSVP-capable receiver if end-to-end RSVP signaling 169 was used. Note that while RSVP is used upstream of the RSVP 170 Receiver Proxy, RSVP is not used downstream of the RSVP Receiver 171 Proxy. 173 o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of 174 a sender, the RSVP operations which would normally be performed by 175 an RSVP-capable sender if end-to-end RSVP signaling was used. 176 Note that while RSVP is used downstream of the RSVP Sender Proxy, 177 RSVP is not used upstream of the RSVP Sender Proxy. 179 o Regular RSVP Router: an RSVP-capable router which is not behaving 180 as a RSVP Receiver Proxy nor as a RSVP Sender Proxy. 182 Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, 183 Regular RSVP Router are all relative to one unidirectional flow. A 184 given router may act as the RSVP Receiver Proxy for a flow, as the 185 RSVP Sender Proxy for another flow and as a Regular RSVP router for 186 yet another flow. 188 The following terminology is also used in the present document: 190 o Regular RSVP Sender: an RSVP-capable host behaving as the sender 191 for the considered flow and participating in RSVP signaling in 192 accordance with the sender behavior specified in [RFC2205]. 194 o Regular RSVP Receiver: an RSVP-capable host behaving as the 195 receiver for the considered flow and participating in RSVP 196 signaling in accordance with the receiver behavior specified in 197 [RFC2205]. 199 3. RSVP Extensions for Sender Notification 201 This section defines extensions to RSVP procedures allowing sender 202 notification of reservation failure. This facilitates 203 synchronization by the sender between RSVP reservation and 204 application requirements in scenarios involving a Path-Triggered RSVP 205 Receiver Proxy. 207 As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], with the 208 Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be 209 configured to use receipt of a regular RSVP Path message as the 210 trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP 211 Path message, the RSVP Receiver Proxy: 213 1. establishes the RSVP Path state as per regular RSVP processing 215 2. identifies the downstream interface towards the receiver 217 3. sinks the Path message 219 4. behaves as if a Resv message (whose details are discussed below) 220 was received on the downstream interface. This includes 221 performing admission control on the downstream interface, 222 establishing a Resv state (in case of successful admission 223 control) and forwarding the Resv message upstream, sending 224 periodic refreshes of the Resv message and tearing down the 225 reservation if the Path state is torn down. 227 Operation of the Path-Triggered Receiver Proxy in the case of a 228 successful reservation is illustrated in Figure 1. 230 |----| *** *** *** |----------| |----| 231 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 232 |----| *** *** *** | Receiver | |----| 233 | Proxy | 234 |----------| 236 --Path---> --Path---> --Path---> --Path---> 238 <---Resv-- <---Resv-- <---Resv-- <---Resv-- 240 ===================RSVP===================> 242 ************************************************************> 244 |----| RSVP-capable |----| Non-RSVP-capable *** 245 | S | Sender | R | Receiver *r* regular RSVP 246 |----| |----| *** router 248 ***> media flow 250 ==> segment of flow path protected by RSVP reservation 252 Figure 1: Successful Reservation 254 We observe that, in the case of successful reservation, conventional 255 RSVP procedures ensure that the sender is notified of the successful 256 reservation establishment. Thus, no extensions are required in the 257 presence of a Path-Triggered RSVP Receiver Proxy in the case of 258 successful reservation establishment. 260 However, in case of reservation failure, conventional RSVP procedures 261 only ensure that the receiver (or the RSVP Receiver Proxy) is 262 notified of the reservation failure. Specifically, in case of an 263 admission control rejection on a regular RSVP router, a ResvErr 264 message is sent downstream towards the receiver. In the presence of 265 an RSVP Receiver Proxy, if we simply follow conventional RSVP 266 procedures, this means that the RSVP Receiver Proxy is notified of 267 the reservation failure, but the sender is not. Operation of the 268 Path-Triggered RSVP Receiver Proxy in the case of an admission 269 control failure, assuming conventional RSVP procedures, is 270 illustrated in Figure 2. 272 |----| *** *** *** |----------| |----| 273 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 274 |----| *** *** *** | Receiver | |----| 275 | Proxy | 276 |----------| 278 --Path---> --Path---> --Path---> --Path---> 280 <---Resv-- <---Resv-- 282 -ResvErr-> -ResvErr-> 284 ===================RSVP===================> 286 ************************************************************> 288 |----| |----| *** 289 | S | Sender | R | Receiver *r* regular RSVP 290 |----| |----| *** router 292 ***> media flow 294 ==> segment of flow path protected by RSVP reservation 296 Figure 2: Reservation Failure With Conventional RSVP 298 While the sender could infer reservation failure from the fact that 299 it has not received a Resv message after a certain time, there are 300 clear benefits in ensuring that the sender gets a prompt explicit 301 notification in case of reservation failure. This includes faster 302 end-user notification at application layer (e.g. busy signal), faster 303 application level reaction (e.g. application level rerouting), as 304 well as faster release of application-level resources. 306 Section 3.1 defines a method which can be used to achieve sender 307 notification of reservation failure. A router implementation 308 claiming compliance with this document MUST support the method 309 defined in Section 3.1. 311 Section 3.2 defines another method which can be used to achieve 312 sender notification of reservation failure. A router implementation 313 claiming compliance with this document MAY support the method defined 314 in Section 3.2. 316 In a given network environment, a network administrator may elect to 317 use the method defined in Section 3.1, or the method defined in 318 Section 3.2, or possibly combine the two. 320 3.1. Sender Notification via PathErr Message 322 With this method, the RSVP Receiver Proxy MUST generate a PathErr 323 message whenever the two following conditions are met: 325 1. The reservation establishment has failed (or the previously 326 established reservation has been torn down) 328 2. The RSVP Receiver Proxy determines that it cannot re-establish 329 the reservation (e.g. by adapting its reservation request in 330 reaction to the error code provided in the received ResvErr in 331 accordance with local policy) 333 Note that this notion of generating a PathErr message upstream in 334 order to notify the sender about a reservation failure is not 335 completely new. It is borrowed from [RFC3209] where it has been 336 introduced in order to achieve a similar requirement, which is to 337 allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end 338 (i.e. the sender) of a failure to establish (or maintain) a TE Tunnel 339 Label Switch Path. 341 Operation of the Path-Triggered RSVP Receiver Proxy in the case of an 342 admission control failure, using sender notification via PathErr 343 Message, is illustrated in Figure 3. 345 |----| *** *** *** |----------| |----| 346 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 347 |----| *** *** *** | Receiver | |----| 348 | Proxy | 349 |----------| 351 --Path---> --Path---> --Path---> --Path---> 353 <---Resv-- <---Resv-- 355 -ResvErr-> -ResvErr-> 357 <-PathErr- <-PathErr- <-PathErr- <-PathErr- 359 ===================RSVP===================> 361 ************************************************************> 363 |----| |----| *** 364 | S | Sender | R | Receiver *r* regular RSVP 365 |----| |----| *** router 367 ***> media flow 369 ==> segment of flow path to be protected by RSVP reservation 370 (but not protected in this case since reservation failed) 372 Figure 3: Reservation Failure With Sender Notification via PathErr 374 The role of this PathErr is to notify the sender that the reservation 375 was not established or was torn down. This may be in the case of 376 receipt of a ResvErr, or because of local failure on the Receiver 377 Proxy. On receipt of a ResvErr, in all situations where the 378 reservation cannot be installed, the Receiver Proxy MUST generate a 379 PathErr towards the sender. For local failures on the Receiver Proxy 380 node, if a similar failure on an RSVP midpoint would cause the 381 generation of a ResvErr (for example, CAC failure), the Receiver 382 Proxy MUST generate a PathErr towards the sender. The Receiver Proxy 383 MAY additionally generate a PathErr upon local failures which would 384 not ordinarily cause generation of a ResvErr message, such as 385 described in Appendix B of [RFC2205]. 387 The PathErr generated by the Receiver Proxy corresponds to the 388 sender(s) which triggered generation of Resv messages that failed. 389 For Fixed-Filter (FF) style reservations, the Receiver Proxy sends a 390 PathErr towards the (single) sender matching the failed reservation. 392 For Shared-Explicit (SE) style reservations, the Receiver Proxy sends 393 the PathErr(s) towards the set of senders which triggered 394 reservations that failed. This may be a subset of senders sharing 395 the same reservation, in which case the remaining senders would have 396 their reservation intact and would not receive a PathErr. In both 397 cases, the rules described in Section 3.1.8 of [RFC2205] for 398 generating flow descriptors in ResvErr messages, also apply for 399 generating sender descriptors in PathErr messages. 401 For Wildcard-Filter (WF) style reservations, it is not possible for 402 the receiver to know which sender caused the reservation failure. 403 Therefore, the procedures described in this section do not apply to 404 WF-style reservations. 406 The procedures described in this section apply to both unicast and 407 multicast sessions. However, for a multicast session, it is possible 408 that reservation failure (e.g. admission control failure) in a node 409 close to a sender may cause ResvErr messages to be sent to a large 410 group of receivers. These receivers would, in turn, all send PathErr 411 messages back to the same sender, which could cause a scalability 412 issue in some environments. From the perspective of the sender, 413 errors that prevent a reservation from being set up can be classified 414 in two ways: 416 1. Errors which the sender can attempt to correct. The error code 417 for those errors should explicitly be communicated back to the 418 sender. An examples of this is "Class 1: Admission Control 419 Failure", because the sender could potentially resend a Path with 420 smaller traffic parameters. 422 2. Errors which the sender has no control over. For these errors, 423 it is sufficient to notify the sender that the reservation was 424 not set up successfully. An example of this is "Class 13: 425 Unknown Object", because the sender has no control over the 426 objects inserted into the reservation by the Receiver Proxy. 428 The PathErr message generated by the Receiver Proxy has the same 429 format as regular PathErr messages defined in [RFC2205]. The 430 SESSION, ERROR_SPEC and sender descriptor are composed by the 431 Receiver Proxy as specified in the following subsections. The 432 Receiver Proxy MAY reflect back towards the sender in the PathErr any 433 POLICY_DATA objects received in the ResvErr. 435 3.1.1. Composition of SESSION and 437 The Receiver Proxy MUST insert the SESSION object corresponding to 438 the failed reservation, into the PathErr. For Fixed-Filter (FF) 439 style reservations, the Receiver Proxy MUST insert a corresponding to the failed reservation, into the 441 PathErr. This is equal to the in the ResvErr 442 received by the Receiver Proxy. For Shared-Explicit (SE) style 443 reservations, the Receiver Proxy MUST insert a 444 corresponding to the sender triggering the failed reservation, into 445 the PathErr. This is equal to the in the ResvErr 446 received by the Receiver Proxy. If multiple could 447 not be admitted at a midpoint node, that node would generate multiple 448 ResvErr messages towards the receiver as per Section 3.1.8 of 449 [RFC2205]. Each ResvErr would contain a that 450 matches a specific sender. The Receiver Proxy MUST generate a 451 PathErr for each ResvErr received, towards the corresponding sender. 453 3.1.2. Composition of ERROR_SPEC 455 The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into 456 the PathErr as follows: 458 1. If the Receiver Proxy receives a ResvErr with any of these error 459 codes: "Code 1 - Admission Control Failure" or "Code 2 - Policy 460 Control Failure" then the Receiver Proxy copies the error code 461 and value from the ERROR_SPEC in the ResvErr, into the ERROR_SPEC 462 of the PathErr message. The error node in the PathErr MUST be 463 set to the address of the Receiver Proxy. This procedure MUST 464 also be followed for a local error on the Receiver Proxy that 465 would ordinarily cause a midpoint to generate a ResvErr with one 466 of the above codes. 468 2. If the Receiver Proxy receives a ResvErr with any error code 469 other than the ones listed in 1 above, it composes a new 470 ERROR_SPEC with error code ": Unrecoverable Receiver Proxy Error". The error node in 472 the PathErr MUST be set to the address of the Receiver Proxy. 473 This procedure MUST also be followed for a local error on the 474 Receiver Proxy that would ordinarily cause a midpoint to generate 475 a ResvErr with any error code except than those listed in 1 476 above, or if the Receiver Proxy generates a PathErr for a local 477 error which ordinarily would not cause generation of a ResvErr. 478 In some cases it may be predetermined that the PathErr will not 479 reach the sender. For example, a node receiving a ResvErr with 480 "Code 3: No Path for Resv", knows a priori that the PathErr 481 message it generates cannot be forwarded by the same node which 482 could not process the Resv. Nevertheless, the procedures above 483 MUST be followed. For the error code ": Unrecoverable Receiver Proxy Error", the 485 16 bits of the Error Value field are: 487 * hhhh hhhh llll llll 489 where the bits are: 491 * hhhh hhhh = 0000 0000: then the low order 8 bits (llll llll) 492 MUST be set by Receiver Proxy to 0000 0000 and MUST be ignored 493 by the sender. 495 * hhhh hhhh = 0000 0001: then the low order 8 bits (llll llll) 496 MUST be set by the Receiver Proxy to the value of the error 497 code received in the ResvErr ERROR_SPEC (or, in case the 498 Receiver Proxy generated the PathErr without having received a 499 ResvErr, to the error code value that would have been included 500 by the Receiver Proxy in the ERROR_SPEC in similar conditions 501 if it was to generate a ResvErr). This error value MAY be 502 used by the sender to further interpret the reason of the 503 reservation failure. 505 * hhhh hhhh = any other value: reserved. 507 3. If the Receiver Proxy Receives a ResvErr with the InPlace flag 508 set in the ERROR_SPEC, it MUST also set the InPlace flag in the 509 ERROR_SPEC of the PathErr. 511 3.1.3. Use of Path_State_Removed Flag 513 [RFC3473] defines an optional behavior whereby a node forwarding a 514 PathErr message can remove the Path State associated with the PathErr 515 message and indicate so by including the Path_State_Removed flag in 516 the ERROR_SPEC object of the PathErr message. This can be used in 517 some situations to expedite release of resources and minimise 518 signaling load. 520 This section discusses aspects of the use of the Path_State_Removed 521 flag that are specific to the RSVP Receiver Proxy. In any other 522 aspects, the Path_State_Removed flag operates as per [RFC3473]. 524 By default, the RSVP Receiver Proxy MUST NOT include the 525 Path_State_Removed flag in the ERROR_SPEC of the PathErr message. 526 This ensures predictable operations in all environments including 527 those where some RSVP routers do not understand the 528 Path_State_Removed flag. 530 The RSVP Receiver Proxy MAY support an OPTIONAL mode to be activated 531 by configuration whereby the RSVP Receiver Proxy includes the 532 Path_State_Removed flag in the ERROR_SPEC of the PathErr message and 533 removes its local Path state. Where all routers on the path of a 534 reservation support the Path_State_Removed flag, its use will indeed 535 result in expedited resource release and reduced signaling. However, 536 if there is one (or more) RSVP router on the path of the reservation 537 that does not support the Path_State_Removed flag (we refer to such a 538 router as an "old RSVP router"), the use of the Path_State_Removed 539 flag will actually result in slower resource release and increased 540 signaling. This is because the Path_State_Removed flag will be 541 propagated upstream by an old RSVP router (even if it does not 542 understand it and does not tear its Path state). Thus, the sender 543 will not send a Path Tear and the old RSVP router will only release 544 its Path state through refresh time-out. A network administrator 545 needs to keep these considerations in mind when deciding whether to 546 activate the use of the Path_State_Removed flag on the RSVP Receiver 547 Proxy. In a controlled environment where all routers are known to 548 support the Path_State_Removed flag, its use can be safely activated 549 on the RSVP Receiver Proxy. In other environments, the network 550 administrator needs to assess whether the improvement achieved with 551 some reservations outweighs the degradation experienced by other 552 reservations. 554 3.1.4. Use of PathErr by Regular Receivers 556 Note that while this document specifies that an RSVP Receiver Proxy 557 generates a PathErr upstream in case of reservation failure, this 558 document does NOT propose that the same be done by regular receivers. 559 In other words, this document does NOT propose to modify the behavior 560 of regular receivers as currently specified in [RFC2205]. The 561 rationale for this includes the following: 563 o when the receiver is RSVP capable, the current receiver-driven 564 model of [RFC2205] is fully applicable because the receiver can 565 synchronise RSVP reservation state and application state (since it 566 participates in both). The sender(s) needs not be aware of the 567 RSVP reservation state. Thus, we can retain the benefits of 568 receiver-driven operations which were explicitly sought by 569 [RFC2205]. Quoting from it: " In order to efficiently accommodate 570 large groups, dynamic group membership, and heterogeneous receiver 571 requirements, RSVP makes receivers responsible for requesting a 572 specific QoS". But even for the most simple single_sender/ 573 single_receiver reservations, the current receiver-driven model 574 reduces signaling load and per-hop RSVP processing by not sending 575 any error message to the sender in case of CAC reject. 577 o the motivation for adding sender error notification in case of 578 receiver proxy lies in the fact that the actual receiver can no 579 longer synchronize RSVP reservation with application state (since 580 the receiver does not participate in RSVP signaling), while the 581 sender can. This motivation does not apply in case of regular 582 receiver. 584 o there is a lot of existing code and deployed systems successfully 585 working under the current [RFC2205] model in the absence of proxy 586 today. The current behavior should not be changed for those 587 unless there were a very strong motivation. 589 3.2. Sender Notification via Notify Message 591 The OPTIONAL method for sender notification of reservation failure 592 defined in this section aims at providing a more efficient method 593 than the one defined in Section 3.1. Its objectives include : 595 o allow the failure notification to be sent directly upstream to the 596 sender by the router where the failure occurs (as opposed to first 597 travelling downstream towards the Receiver Proxy and then 598 travelling upstream from the Receiver Proxy to the sender, as 599 effectively happens with the method defined in Section 3.1) 601 o allow the failure notification to travel directly to the sender 602 without hop-by-hop RSVP processing 604 o ensure that such a notification is only sent to senders which are 605 capable and willing to process it (i.e. to synchronize reservation 606 status with application) 608 o ensure that such a notification is only sent in case the receiver 609 is not itself capable and willing to do the synchronisation with 610 the application (i.e. because we are in the presence of a receiver 611 proxy so that RSVP signaling is not visible to the receiver). 613 Note, however, that such benefits come at the cost of : 615 o a requirement for RSVP routers and senders to support the Notify 616 messages and procedures defined in [RFC3473] 618 o a requirement for senders to process Notify messages traveling 619 upstream but conveying a downstream notification. 621 [RFC3473] defines (in section "4.3 Notify Messages") the Notify 622 message that provides a mechanism to inform non-adjacent nodes of 623 events related to the RSVP reservation. The Notify message differs 624 from the error messages defined in [RFC2205] (i.e., PathErr and 625 ResvErr messages) in that it can be "targeted" to a node other than 626 the immediate upstream or downstream neighbor and that it is a 627 generalized notification mechanism. Notify messages are normally 628 generated only after a Notify Request object has been received. 630 This section discusses aspects of the use of the Notify message that 631 are specific to the RSVP Receiver Proxy. In any other aspects, the 632 Notify message operates as per [RFC3473]. 634 In order to achieve sender notification of reservation failure in the 635 context of the present document: 637 o an RSVP sender interested in being notified of reservation failure 638 MUST include a Notify Request object (containing the sender's IP 639 address) in the Path messages it generates 641 o Upon receiving a Path message with a Notify Request object, the 642 RSVP Receiver Proxy MUST include a Notify Request object in the 643 Resv messages it generates. This Notify Request object MUST 644 contain the address that was included in the Notify Request of the 645 received Path message- a.k.a. the sender's address- and not an 646 address of the Receiver Proxy. 648 As a result, as per existing Notify procedures, if an RSVP router 649 detects an error relating to a Resv state (e.g. Admission Control 650 rejection after IP reroute), the RSVP router will send a Notify 651 message (conveying the Resv Err code) to the IP address contained in 652 the Resv Notify Request object. Since this address has been set to 653 the sender's address by the Receiver Proxy, the Notify message is 654 sent to the sender. 656 Operation of the Path-Triggered RSVP Receiver Proxy in the case of an 657 admission control failure, using sender notification via Notify 658 Message, is illustrated in Figure 4. 660 |----| *** *** *** |----------| |----| 661 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 662 |----| *** *** *** | Receiver | |----| 663 | Proxy | 664 |----------| 666 --Path*--> --Path*--> --Path*--> --Path*--> 668 <--Resv*-- <--Resv*-- 670 <------Notify------- 671 -ResvErr-> -ResvErr-> 673 ===================RSVP===================> 675 ************************************************************> 677 |----| |----| *** 678 | S | Sender | R | Receiver *r* regular RSVP 679 |----| |----| *** router 681 ***> media flow 683 ==> segment of flow path to be protected by RSVP reservation 684 (but not protected in this case since reservation failed) 686 Path* = Path message containing a Notify Request object 687 with sender IP Address 689 Resv* = Resv message containing a Notify Request object 690 with sender IP address 692 Notify = Notify message 694 Figure 4: Reservation Failure With Sender Notification via Notify 696 For local failures on the Receiver Proxy node, if a similar failure 697 on an RSVP midpoint would cause the generation of a ResvErr (for 698 example, CAC failure), the Receiver Proxy MUST generate a Notify 699 towards the sender. The Receiver Proxy MAY additionally generate a 700 Notify upon local failures which would not ordinarily cause 701 generation of a ResvErr message, such as described in Appendix B of 702 [RFC2205]. 704 When the method of sender notification via Notify message is used, it 705 is RECOMMENDED that the RSVP Receiver Proxy also issues sender 706 notification via a PathErr message. This maximizes the chances that 707 the notification reaches the sender in all situations (e.g. even if 708 some RSVP routers do not support the Notify procedure, or if a Notify 709 message gets dropped). However, for controlled environments (e.g. 710 where all RSVP routers are known to support Notify procedures) and 711 where it is desirable to minimize the volume of signaling, the RSVP 712 Receiver Proxy MAY rely exclusively on sender notification via Notify 713 message and thus not issue sender notification via PathErr message. 715 4. Security Considerations 717 To ensure the integrity of the associated reservation and admission 718 control mechanisms, the RSVP Authentication mechanisms defined in 719 [RFC2747] and [RFC3097] may be used. Those protect RSVP message 720 integrity hop-by-hop and provide node authentication as well as 721 replay protection, thereby protecting against corruption and spoofing 722 of RSVP messages. These hop-by-hop integrity mechanisms can be used 723 to protect the RSVP reservations established using an RSVP receiver 724 proxy in accordance with the present document. 726 [RFC2747] discusses several approaches for key distribution. First, 727 the RSVP Authentication shared keys can be distributed manually. 728 This is the base option and its support is mandated for any 729 implementation. However, in some environments, this approach may 730 become a burden if keys frequently change over time. Alternatively, 731 a standard key management protocol for secure key distribution can be 732 used. However, existing key distribution protocols may not be 733 appropriate in all environments because of the complexity or 734 operational burden they involve. 736 The use of RSVP Authentication in parts of the network where there 737 may be one or more IP hops in between two RSVP neighbors raises an 738 additional challenge. This is because, with some RSVP messages such 739 as a Path message, an RSVP router does not know the RSVP next hop for 740 that message at the time of forwarding it. In fact, part of the role 741 of a Path message is precisely to discover the RSVP next hop (and to 742 dynamically re-discover it when it changes, say because of a routing 743 change). Hence, the RSVP router may not know which security 744 association to use when forwarding such a message. In that 745 situation, one approach is to share the same RSVP Authentication 746 shared key across all the RSVP routers of a part of the network where 747 there may be RSVP neighbors with IP hops in between. For example, 748 all the RSVP routers of an administrative domain (including the 749 receiver proxys) could share the same RSVP Authentication key, while 750 different per-neighbor keys could be used between any RSVP router 751 pair straddling the boundary between two administrative domains that 752 have agreed to use RSVP signaling. 754 When the same RSVP Authentication shared key is to be shared among 755 multiple RSVP neighbors, manual key distribution may be used. 756 [I-D.behringer-tsvwg-rsvp-security-groupkeying] also discusses 757 applicability of dynamic group key distribution method for dynamic 758 update of such shared keys among RSVP routers. 760 The RSVP Authentication mechanisms do not provide confidentiality. 761 If confidentiality is required, IPsec ESP ([RFC4303]) may be used, 762 although it imposes the burden of key distribution. It also faces 763 the additional issue discussed for key management above in the case 764 where there can be IP hops in between RSVP hops. 765 [I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses 766 applicability of various keying methods for applying IPsec encryption 767 and authentication to RSVP, including use of group keys and dynamic 768 group key distribution. 770 When an RSVP receiver proxy is used, the RSVP reservation is no 771 longer controlled by the receiver, but rather is controlled by the 772 receiver proxy (using hints received from the sender in the Path 773 message) on behalf of the sender. Thus, the receiver proxy ought to 774 be trusted by the end-systems to control the RSVP reservation 775 appropriately. However, basic RSVP operation already assumes a trust 776 model where end-systems trust RSVP nodes to appropriately perform 777 RSVP reservations. So the use of RSVP receiver proxy is not seen as 778 introducing any significant additional security threat or as 779 modifying the RSVP trust model. 781 In fact, there are situations where the use of RSVP receiver proxy 782 reduces the security risks. One example is where a network operator 783 relies on RSVP to perform resource reservation and admission control 784 within a network and where RSVP senders and RSVP routers are located 785 in the operator premises while the many RSVP receivers are located in 786 the operator's customers premises. Such an environment is further 787 illustrated in "Annex A.1. RSVP-based VoD CAC in Broadband 788 Aggregation Networks" of [I-D.ietf-tsvwg-rsvp-proxy-approaches]. 789 From the operator's perspective, the RSVP routers and RSVP senders 790 are in physically secured locations and therefore exposed to a lower 791 risk of being tampered with; While the receivers are in locations 792 which are physically unsecured and therefore subject to a higher risk 793 of being tampered with. The use of an RSVP receiver proxy function 794 effectively increases the security of the operator's reservation and 795 admission control solution by completely excluding receivers from its 796 operation. Filters can be placed at the edge of the operator network 797 discarding any RSVP message received from end-users. This provides a 798 very simple and effective protection of the RSVP reservation and 799 admission control solution operating inside the operator's network. 801 This document defines in Section 3.2 an optional method relying on 802 the use of the Notify message specified in [RFC3473]. The Notify 803 message can be sent in a non-hop-by-hop fashion that precludes RSVP's 804 hop-by-hop integrity and authentication model. The approaches and 805 considerations for addressing this issue presented in the Security 806 Considerations section of [RFC3473] apply. In particular, where the 807 Notify messages are transmitted non-hop-by-hop and the same level of 808 security provided by [RFC2747] is desired, the standard IPsec based 809 integrity and authentication can be used. Alternatively, the sending 810 of non-hop-by-hop Notify messages can be disabled. Finally, 812 [I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses 813 applicability of group keying for non-hop-by-hop Notify messages. 815 5. IANA Considerations 817 Since, as discussed in Section 3.1.2, this document allows two Error 818 Codes to be used in PathErr messages while [RFC2205] only specified 819 their use in ResvErr messages, this document requires that IANA 820 updates the existing entries for these two Error Codes under the 821 "Error Codes and Globally-Defined Error Value Sub-Codes" registry. 822 Each entry should refer to this document, in addition to referring to 823 [RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2 824 should respectively read: 826 " 828 1 Admission Control Failure [RFC2205] [RFCXXX] 830 ... 832 2 Policy Control Failure [RFC2205] [RFCXXX] 834 ... 836 " 838 where [RFCXXX] refers to this document. 840 This document also requires that IANA allocates a new RSVP Error Code 841 ": Unrecoverable Receiver Proxy Error", as discussed in 842 Section 3.1.2. This Error Code is to be allocated under the "Error 843 Codes and Globally-Defined Error Value Sub-Codes" registry. The 844 entry for this error code should read: 846 " 848 TBD Unrecoverable Receiver Proxy Error [RFCXXX] 850 The sixteen bits of the Error Value field are defined in [RFCXXX] 852 " 854 where [RFCXXX] refers to this document and TBD is the value to be 855 allocated by IANA. 857 6. Acknowledgments 859 This document benefited from discussions with Carol Iturralde and 860 Anca Zamfir. Lou Berger, Adrian Farrel and John Drake provided 861 review and guidance, in particular on the usage of the 862 Path_State_Removed flag and of the Notify message, both borrowed from 863 [RFC3473]. We also thank Ken Carlberg for his valuable input. 865 7. References 867 7.1. Normative References 869 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 870 Le Faucheur, F., Manner, J., Wing, D., and A. Guillou, 871 "RSVP Proxy Approaches", December 2007. 873 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 874 Requirement Levels", BCP 14, RFC 2119, March 1997. 876 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 877 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 878 Functional Specification", RFC 2205, September 1997. 880 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 881 Authentication", RFC 2747, January 2000. 883 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 884 Authentication -- Updated Message Type Value", RFC 3097, 885 April 2001. 887 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 888 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 889 Tunnels", RFC 3209, December 2001. 891 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 892 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 893 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 895 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 896 RFC 4303, December 2005. 898 7.2. Informative References 900 [I-D.behringer-tsvwg-rsvp-security-groupkeying] 901 Behringer, M. and F. Le Faucheur, "Applicability of Keying 902 Methods for RSVP Security", November 2007. 904 Authors' Addresses 906 Francois Le Faucheur 907 Cisco Systems 908 Greenside, 400 Avenue de Roumanille 909 Sophia Antipolis 06410 910 France 912 Phone: +33 4 97 23 26 19 913 Email: flefauch@cisco.com 915 Jukka Manner 916 University of Helsinki 917 P.O. Box 68 918 University of Helsinki FIN-00014 University of Helsinki 919 Finland 921 Phone: +358 9 191 51298 922 Email: jmanner@cs.helsinki.fi 923 URI: http://www.cs.helsinki.fi/u/jmanner/ 925 Ashok Narayanan 926 Cisco Systems 927 300 Beaver Brook Road 928 Boxborough, MAS 01719 929 United States 931 Email: ashokn@cisco.com 933 Allan Guillou 934 Neuf Cegetel 935 40-42 Quai du Point du Jour 936 Boulogne-Billancourt, 92659 937 France 939 Email: allan.guillou@neufcegetel.fr 940 Hemant Malik 941 Bharti Airtel Ltd. 942 4th Floor, Tower A, Unitech Cyber Park 943 Gurgaon, Sector 39, 122001 944 India 946 Email: Hemant.Malik@airtel.in 948 Full Copyright Statement 950 Copyright (C) The IETF Trust (2008). 952 This document is subject to the rights, licenses and restrictions 953 contained in BCP 78, and except as set forth therein, the authors 954 retain all their rights. 956 This document and the information contained herein are provided on an 957 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 958 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 959 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 960 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 961 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 962 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 964 Intellectual Property 966 The IETF takes no position regarding the validity or scope of any 967 Intellectual Property Rights or other rights that might be claimed to 968 pertain to the implementation or use of the technology described in 969 this document or the extent to which any license under such rights 970 might or might not be available; nor does it represent that it has 971 made any independent effort to identify any such rights. Information 972 on the procedures with respect to rights in RFC documents can be 973 found in BCP 78 and BCP 79. 975 Copies of IPR disclosures made to the IETF Secretariat and any 976 assurances of licenses to be made available, or the result of an 977 attempt made to obtain a general license or permission for the use of 978 such proprietary rights by implementers or users of this 979 specification can be obtained from the IETF on-line IPR repository at 980 http://www.ietf.org/ipr. 982 The IETF invites any interested party to bring to its attention any 983 copyrights, patents or patent applications, or other proprietary 984 rights that may cover technology that may be required to implement 985 this standard. Please address the information to the IETF at 986 ietf-ipr@ietf.org.