idnits 2.17.1 draft-ietf-tsvwg-rsvp-proxy-proto-04.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: By default, the RSVP Receiver Proxy MUST not include the Path_State_Removed flag in the ERROR_SPEC of the PathErr message. This ensures predictable operations in all environments including those where some RSVP routers do not understand the Path_State_Removed flag. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 14, 2007) is 5978 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 ** Downref: Normative reference to an Informational draft: draft-ietf-tsvwg-rsvp-proxy-approaches (ref. 'I-D.ietf-tsvwg-rsvp-proxy-approaches') Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG F. Le Faucheur 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Manner 5 Expires: June 16, 2008 University of Helsinki 6 A. Narayanan 7 Cisco 8 A. Guillou 9 Neuf 10 H. Malik 11 Bharti 12 December 14, 2007 14 RSVP Extensions for Path-Triggered RSVP Receiver Proxy 15 draft-ietf-tsvwg-rsvp-proxy-proto-04.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 June 16, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 RSVP signaling can be used to make end-to-end resource reservations 49 in an IP network in order to guarantee the QoS required by certain 50 flows. With conventional RSVP, both the data sender and receiver of 51 a given flow take part in RSVP signaling. Yet, there are many use 52 cases where resource reservation is required, but the receiver, the 53 sender, or both, is not RSVP-capable. Where the receiver is not 54 RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy 55 thereby performing RSVP signaling on behalf of the receiver. This 56 allows resource reservations to be established on the segment of the 57 end-to-end path from the sender to the RSVP Receiver Proxy. However, 58 as discussed in the companion document presenting RSVP Proxy 59 approaches, RSVP extensions are needed to facilitate operations with 60 an RSVP Receiver Proxy whose signaling is triggered by receipt of 61 RSVP Path messages from the sender. This document specifies these 62 extensions. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. RSVP Extensions for Sender Notification . . . . . . . . . . . 7 70 3.1. Sender Notification via PathErr Message . . . . . . . . . 10 71 3.1.1. Composition of SESSION and . . . . 12 72 3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 13 73 3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 14 74 3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 15 75 3.2. Sender Notification via Notify Message . . . . . . . . . . 16 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 80 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 81 7.2. Informative References . . . . . . . . . . . . . . . . . . 25 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 83 Intellectual Property and Copyright Statements . . . . . . . . . . 28 85 1. Introduction 87 Guaranteed QoS for some applications with tight Qos requirements may 88 be achieved by reserving resources in each node on the end-to-end 89 path. The main IETF protocol for these resource reservations is RSVP 90 specified in [RFC2205]. RSVP does not require that all intermediate 91 nodes support RSVP, but it assumes that both the sender and the 92 receiver of the data flow support RSVP. However, there are 93 environments where it would be useful to be able to reserve resources 94 for a flow (at least a subset of the flow path) even when the sender 95 or the receiver (or both) is not RSVP-capable. 97 Since both the data sender and receiver may be unaware of RSVP, there 98 are two distinct RSVP Proxy cases. In the first case, an entity in 99 the network must operate on behalf of the data sender, generate RSVP 100 Path messages, and eventually receive, process and sink Resv 101 messages. We refer to this entity as the RSVP Sender Proxy. In the 102 second case, an entity in the network must receive Path messages sent 103 by a data sender (or by an RSVP Sender Proxy), and reply to those 104 with Resv messages generated on behalf of the data receiver(s). We 105 refer to this entity as the RSVP Receiver Proxy. 107 RSVP Proxy approaches are presented in 108 [I-D.ietf-tsvwg-rsvp-proxy-approaches]. That document also 109 discusses, for each approach, how the reservations controlled by the 110 RSVP Proxy can be synchronised with the application requirements 111 (e.g. when to establish, maintain and tear down the RSVP reservation 112 to satisfy application requirements). 114 One RSVP Proxy approach is referred to as the Path-Triggered RSVP 115 Receiver Proxy approach. With this approach, the RSVP Receiver Proxy 116 uses the RSVP Path messages generated by the sender (or RSVP Sender 117 Proxy) as the cue for establishing the RSVP reservation on behalf of 118 the non-RSVP-capable receiver. The RSVP Receiver Proxy is 119 effectively acting as an intermediary making reservations (on behalf 120 of the receiver) under the sender's control (or RSVP Sender Proxy's 121 control). This changes somewhat the usual RSVP reservation model 122 where reservations are normally controlled by receivers. Such a 123 change greatly facilitates operations in the scenario of interest 124 here, which is where the receiver is not RSVP-capable. Indeed it 125 allows the RSVP Receiver Proxy to remain application unaware by 126 taking advantage of the application awareness and RSVP awareness of 127 the sender (or RSVP Sender Proxy). 129 Since the synchronisation between RSVP reservation and application 130 requirement is now effectively performed by the sender (or RSVP 131 Sender Proxy), it is important that the sender (or RSVP Sender Proxy) 132 is aware of the reservation state. However, as conventional RSVP 133 assumes that the reservation is to be controlled by the receiver, 134 some notifications about reservation state (notably the error message 135 sent in case of admission control rejection of the reservation) are 136 only sent towards the receiver and therefore, in our case, sunk by 137 the RSVP Receiver Proxy. This document specifies extension to RSVP 138 procedures allowing such notifications to be also conveyed towards 139 the sender. This facilitates synchronization by the sender (or RSVP 140 Sender Proxy) between RSVP reservation and application requirements 141 in scenarios involving a Path-Triggered RSVP receiver Proxy. 143 This document discusses extension to facilitate operations in the 144 presence of an RSVP Receiver Proxy. As explicitly pointed out in the 145 text above, those apply equally whether RSVP signaling is initiated 146 by a regular RSVP sender or by an RSVP Sender Proxy (with some means 147 to synchronize reservation state with application level requirements 148 that are outside the scope of this document). For readability, the 149 rest of this document discusses operation assuming a regular RSVP 150 sender; however, such operation is equally applicable where an RSVP 151 Sender Proxy is used to initiated RSVP signaling on behalf of a non- 152 RSVP-capable sender. 154 1.1. Conventions Used in This Document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 2. Terminology 162 The following terminology is borrowed from 163 [I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the 164 present document: 166 o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per 167 [RFC2205] 169 o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf 170 of a receiver, the RSVP operations which would normally be 171 performed by an RSVP-capable receiver if end-to-end RSVP signaling 172 was used. Note that while RSVP is used upstream of the RSVP 173 Receiver Proxy, RSVP is not used downstream of the RSVP Receiver 174 Proxy. 176 o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of 177 a sender, the RSVP operations which would normally be performed by 178 an RSVP-capable sender if end-to-end RSVP signaling was used. 179 Note that while RSVP is used downstream of the RSVP Sender Proxy, 180 RSVP is not used upstream of the RSVP Sender Proxy. 182 o Regular RSVP Router: an RSVP-capable router which is not behaving 183 as a RSVP Receiver Proxy nor as a RSVP Sender Proxy. 185 o Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, 186 Regular RSVP Router are all relative to one unidirectional flow. 187 A given router may act as the RSVP Receiver Proxy for a flow, as 188 the RSVP Sender Proxy for another flow and as a Regular RSVP 189 router for yet another flow. 191 The following terminology is also used in the present document: 193 o Regular RSVP Sender: an RSVP-capable host behaving as the sender 194 for the considered flow and participating in RSVP signaling in 195 accordance with the sender behavior specified in [RFC2205]. 197 o Regular RSVP Receiver: an RSVP-capable host behaving as the 198 receiver for the considered flow and participating in RSVP 199 signaling in accordance with the receiver behavior specified in 200 [RFC2205]. 202 3. RSVP Extensions for Sender Notification 204 This section defines extensions to RSVP procedures allowing sender 205 notification of reservation failure. This facilitates 206 synchronization by the sender between RSVP reservation and 207 application requirements in scenarios involving a Path-Triggered RSVP 208 Receiver Proxy. 210 As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], with the 211 Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be 212 configured to use receipt of a regular RSVP Path message as the 213 trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP 214 Path message, the RSVP Receiver Proxy: 216 1. establishes the RSVP Path state as per regular RSVP processing 218 2. identifies the downstream interface towards the receiver 220 3. sinks the Path message 222 4. behaves as if a Resv message (whose details are discussed below) 223 was received on the downstream interface. This includes 224 performing admission control on the downstream interface, 225 establishing a Resv state (in case of successful admission 226 control) and forwarding the Resv message upstream, sending 227 periodic refreshes of the Resv message and tearing down the 228 reservation if the Path state is torn down. 230 Operation of the Path-Triggered Receiver Proxy in the case of a 231 successful reservation is illustrated in Figure 1. 233 |----| *** *** *** |----------| |----| 234 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 235 |----| *** *** *** | Receiver | |----| 236 | Proxy | 237 |----------| 239 ************************************************************> 241 ===================RSVP===================> 243 --Path---> --Path---> --Path---> --Path---> 245 <---Resv-- <---Resv-- <---Resv-- <---Resv-- 247 |----| RSVP-capable |----| Non-RSVP-capable *** 248 | S | Sender | R | Receiver *r* regular RSVP 249 |----| |----| *** router 251 ***> media flow 253 ==> segment of flow path protected by RSVP reservation 255 Figure 1: Successful Reservation 257 We observe that, in the case of successful reservation, conventional 258 RSVP procedures ensure that the sender is notified of the successful 259 reservation establishment. Thus, no extensions are required in the 260 presence of a Path-Triggered RSVP Receiver Proxy in the case of 261 successful reservation establishment. 263 However, in case of reservation failure, conventional RSVP procedures 264 only ensure that the receiver (or the RSVP Receiver Proxy) is 265 notified of the reservation failure. Specifically, in case of an 266 admission control rejection on a regular RSVP router, a ResvErr 267 message is sent downstream towards the receiver. In the presence of 268 an RSVP Receiver Proxy, if we simply follow conventional RSVP 269 procedures, this means that the RSVP Receiver Proxy is notified of 270 the reservation failure, but the sender is not. Operation of the 271 Path-Triggered RSVP Receiver Proxy in the case of an admission 272 control failure, assuming conventional RSVP procedures, is 273 illustrated in Figure 2. 275 |----| *** *** *** |----------| |----| 276 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 277 |----| *** *** *** | Receiver | |----| 278 | Proxy | 279 |----------| 281 ************************************************************> 283 ===================RSVP===================> 285 --Path---> --Path---> --Path---> --Path---> 287 <---Resv-- <---Resv-- 289 -ResvErr-> -ResvErr-> 291 |----| |----| *** 292 | S | Sender | R | Receiver *r* regular RSVP 293 |----| |----| *** router 295 ***> media flow 297 ==> segment of flow path protected by RSVP reservation 299 Figure 2: Reservation Failure With Conventional RSVP 301 While the sender could infer reservation failure from the fact that 302 it has not received a Resv message after a certain time, there are 303 clear benefits in ensuring that the sender gets a prompt explicit 304 notification in case of reservation failure. This includes faster 305 end-user notification at application layer (e.g. busy signal), faster 306 application level reaction (e.g. application level rerouting), as 307 well as faster release of application-level resources. 309 Section 3.1 defines a method which can be used to achieve sender 310 notification of reservation failure. A router implementation 311 claiming compliance with this document MUST support the method 312 defined in Section 3.1. 314 Section 3.2 defines another method which can be used to achieve 315 sender notification of reservation failure. A router implementation 316 claiming compliance with this document MAY support the method defined 317 in Section 3.2. 319 In a given network environment, a network administrator may elect to 320 use the method defined in Section 3.1, or the method defined in 321 Section 3.2, or possibly combine the two. 323 3.1. Sender Notification via PathErr Message 325 With this method, the RSVP Receiver Proxy MUST generate a PathErr 326 message whenever the two following conditions are met: 328 1. The reservation establishment has failed (or the previously 329 established reservation has been torn down) 331 2. The RSVP Receiver Proxy determines that it cannot re-establish 332 the reservation (e.g. by adapting its reservation request in 333 reaction to the error code provided in the received ResvErr in 334 accordance with local policy) 336 Note that this notion of generating a PathErr message upstream in 337 order to notify the sender about a reservation failure is not 338 completely new. It is borrowed from [RFC3209] where it has been 339 introduced in order to achieve a similar requirement, which is to 340 allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end 341 (i.e. the sender) of a failure to establish (or maintain) a TE Tunnel 342 Label Switch Path. 344 Operation of the Path-Triggered RSVP Receiver Proxy in the case of an 345 admission control failure, using sender notification via PathErr 346 Message, is illustrated in Figure 3. 348 |----| *** *** *** |----------| |----| 349 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 350 |----| *** *** *** | Receiver | |----| 351 | Proxy | 352 |----------| 354 ************************************************************> 356 ===================RSVP===================> 358 --Path---> --Path---> --Path---> --Path---> 360 <---Resv-- <---Resv-- 362 -ResvErr-> -ResvErr-> 364 <-PathErr- <-PathErr- <-PathErr- <-PathErr- 366 |----| |----| *** 367 | S | Sender | R | Receiver *r* regular RSVP 368 |----| |----| *** router 370 ***> media flow 372 ==> segment of flow path protected by RSVP reservation 374 Figure 3: Reservation Failure With Sender Notification via PathErr 376 The role of this PathErr is to notify the sender that the reservation 377 was not established or was torn down. This may be in the case of 378 receipt of a ResvErr, or because of local failure on the Receiver 379 Proxy. On receipt of a ResvErr, in all situations where the 380 reservation cannot be installed, the Receiver Proxy MUST generate a 381 PathErr towards the sender. For local failures on the Receiver Proxy 382 node, if a similar failure on an RSVP midpoint would cause the 383 generation of a ResvErr (for example, CAC failure), the Receiver 384 Proxy MUST generate a PathErr towards the sender. The Receiver Proxy 385 MAY additionally generate a PathErr upon local failures which would 386 not ordinarily cause generation of a ResvErr message, such as 387 described in Appendix B of [RFC2205]. 389 The PathErr generated by the Receiver Proxy corresponds to the 390 sender(s) which triggered generation of Resv messages that failed. 391 For Fixed-Filter (FF) style reservations, the Receiver Proxy sends a 392 PathErr towards the (single) sender matching the failed reservation. 394 For Shared-Explicit (SE) style reservations, the Receiver Proxy sends 395 the PathErr(s) towards the set of senders which triggered 396 reservations that failed. This may be a subset of senders sharing 397 the same reservation, in which case the remaining senders would have 398 their reservation intact and would not receive a PathErr. In both 399 cases, the rules described in Section 3.1.8 of [RFC2205] for 400 generating flow descriptors in ResvErr messages, also apply for 401 generating sender descriptors in PathErr messages. 403 For Wildcard-Filter (WF) style reservations, it is not possible for 404 the receiver to know which sender caused the reservation failure. 405 Therefore, the procedures described in this section do not apply to 406 WF-style reservations. 408 The procedures described in this section apply to both unicast and 409 multicast sessions. However, for a multicast session, it is possible 410 that reservation failure (e.g. admission control failure) in a node 411 close to a sender may cause ResvErr messages to be sent to a large 412 group of receivers. These receivers would, in turn, all send PathErr 413 messages back to the same sender, which could cause a scalability 414 issue in some environments. From the perspective of the sender, 415 errors that prevent a reservation from being set up can be classified 416 in two ways: 418 1. Errors which the sender can attempt to correct. The error code 419 for those errors should explicitly be communicated back to the 420 sender. An examples of this is "Class 1: Admission Control 421 Failure", because the sender could potentially resend a Path with 422 smaller traffic parameters. 424 2. Errors which the sender has no control over. For these errors, 425 it is sufficient to notify the sender that the reservation was 426 not set up successfully. An example of this is "Class 13: 427 Unknown Object", because the sender has no control over the 428 objects inserted into the reservation by the Receiver Proxy. 430 The PathErr message generated by the Receiver Proxy has the same 431 format as regular PathErr messages defined in [RFC2205]. The 432 SESSION, ERROR_SPEC and sender descriptor are composed by the 433 Receiver Proxy as specified in the following subsections. The 434 Receiver Proxy MAY reflect back towards the sender in the PathErr any 435 POLICY_DATA objects received in the ResvErr. 437 3.1.1. Composition of SESSION and 439 The Receiver Proxy MUST insert the SESSION object corresponding to 440 the failed reservation, into the PathErr. For Fixed-Filter (FF) 441 style reservations, the Receiver Proxy MUST insert a corresponding to the failed reservation, into the 443 PathErr. This is equal to the in the ResvErr 444 received by the Receiver Proxy. For Shared-Explicit (SE) style 445 reservations, the Receiver Proxy MUST insert a 446 corresponding to the sender triggering the failed reservation, into 447 the PathErr. This is equal to the in the ResvErr 448 received by the Receiver Proxy. If multiple could 449 not be admitted at a midpoint node, that node would generate multiple 450 ResvErr messages towards the receiver as per Section 3.1.8 of 451 [RFC2205]. Each ResvErr would contain a that 452 matches a specific sender. The Receiver Proxy MUST generate a 453 PathErr for each ResvErr received, towards the corresponding sender. 455 3.1.2. Composition of ERROR_SPEC 457 The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into 458 the PathErr as follows: 460 1. If the Receiver Proxy receives a ResvErr with any of these error 461 codes: "Code 1 - Admission Control Failure" or "Code 2 - Policy 462 Control Failure" then the Receiver Proxy copies the error code 463 and value from the ERROR_SPEC in the ResvErr, into the ERROR_SPEC 464 of the PathErr message. The error node in the PathErr MUST be 465 set to the address of the Receiver Proxy. This procedure MUST 466 also be followed for a local error on the Receiver Proxy that 467 would ordinarily cause a midpoint to generate a ResvErr with one 468 of the above codes. 470 2. If the Receiver Proxy receives a ResvErr with any error code 471 other than the ones listed in 1 above, it composes a new 472 ERROR_SPEC with error code ": Unrecoverable Receiver Proxy Error". The error node in 474 the PathErr MUST be set to the address of the Receiver Proxy. 475 This procedure MUST also be followed for a local error on the 476 Receiver Proxy that would ordinarily cause a midpoint to generate 477 a ResvErr with any error code except than those listed in 1 478 above, or if the Receiver Proxy generates a PathErr for a local 479 error which ordinarily would not cause generation of a ResvErr. 480 In some cases it may be predetermined that the PathErr will not 481 reach the sender. For example, a node receiving a ResvErr with 482 "Code 3: No Path for Resv", knows a priori that the PathErr 483 message it generates cannot be forwarded by the same node which 484 could not process the Resv. Nevertheless, the procedures above 485 MUST be followed. For the error code ": Unrecoverable Receiver Proxy Error", the 487 16 bits of the Error Value field are: 489 * hhhh hhhh llll llll 491 where the bits are: 493 * hhhh hhhh = 0000 0000: then the low order 8 bits (llll llll) 494 MUST be set by Receiver Proxy to 0000 0000 and MUST be ignored 495 by the sender. 497 * hhhh hhhh = 0000 0001: then the low order 8 bits (llll llll) 498 MUST be set by the Receiver Proxy to the value of the error 499 code received in the ResvErr ERROR_SPEC (or, in case the 500 Receiver Proxy generated the PathErr without having received a 501 ResvErr, to the error code value that would have been included 502 by the Receiver Proxy in the ERROR_SPEC in similar conditions 503 if it was to generate a ResvErr). This error value MAY be 504 used by the sender to further interpret the reason of the 505 reservation failure. 507 * hhhh hhhh = any other value: reserved. 509 3. If the Receiver Proxy Receives a ResvErr with the InPlace flag 510 set in the ERROR_SPEC, it MUST also set the InPlace flag in the 511 ERROR_SPEC of the PathErr. 513 3.1.3. Use of Path_State_Removed Flag 515 [RFC3473] defines an optional behavior whereby a node forwarding a 516 PathErr message can remove the Path State associated with the PathErr 517 message and indicate so by including the Path_State_Removed flag in 518 the ERROR_SPEC object of the PathErr message. This can be used in 519 some situations to expedite release of resources and minimise 520 signaling load. 522 This section discusses aspects of the use of the Path_State_Removed 523 flag that are specific to the RSVP Receiver Proxy. In any other 524 aspects, the Path_State_Removed flag operates as per [RFC3473]. 526 By default, the RSVP Receiver Proxy MUST not include the 527 Path_State_Removed flag in the ERROR_SPEC of the PathErr message. 528 This ensures predictable operations in all environments including 529 those where some RSVP routers do not understand the 530 Path_State_Removed flag. 532 Optionally, the RSVP Receiver Proxy MAY support an optional mode that 533 can be activated by configuration whereby the RSVP Receiver Proxy 534 includes the Path_State_Removed flag in the ERROR_SPEC of the PathErr 535 message and removes its local Path state. Where all routers on the 536 path of a reservation support the Path_State_Removed flag, its use 537 will indeed result in expedited resource release and reduced 538 signaling. However, if there is one (or more) "old" router on the 539 path of the reservation that does not support the Path_State_Removed 540 flag, its use will actually result in slower resource release and 541 increased signaling. This is because the Path_State_Removed flag 542 will be propagated upstream by an "old" router (even if it does not 543 understand it and does not tear its Path state). Thus, the sender 544 will not send a Path Tear and the "old" router will only release its 545 Path state through refresh time-out. A network administrator needs 546 to keep these considerations in mind when deciding whether to 547 activate the use of the Path_State_Removed flag on the RSVP Receiver 548 Proxy. In a controlled environment where all routers are known to 549 support the Path_State_Removed flag, its use can be safely activated 550 on the RSVP Receiver Proxy. In other environments, the network 551 administrator needs to assess whether the improvement achieved with 552 some reservations outweighs the degradation experienced by other 553 reservations. 555 3.1.4. Use of PathErr by Regular Receivers 557 Note that while this document specifies that an RSVP Receiver Proxy 558 generates a PathErr upstream in case of reservation failure, this 559 document does NOT propose that the same be done by regular receivers. 560 In other words, this document does NOT propose to modify the behavior 561 of regular receivers as currently specified in [RFC2205]. The 562 rationale for this includes the following: 564 o when the receiver is RSVP capable, the current receiver-driven 565 model of [RFC2205] is fully applicable because the receiver can 566 synchronise RSVP reservation state and application state (since it 567 participates in both). The sender(s) needs not be aware of the 568 RSVP reservation state. Thus, we can retain the benefits of 569 receiver-driven operations which were explicitly sought by 570 [RFC2205]. Quoting from it: " In order to efficiently accommodate 571 large groups, dynamic group membership, and heterogeneous receiver 572 requirements, RSVP makes receivers responsible for requesting a 573 specific QoS". But even for the most simple single_sender/ 574 single_receiver reservations, the current receiver-driven model 575 reduces signaling load and per-hop RSVP processing by not sending 576 any error message to the sender in case of CAC reject. 578 o the motivation for adding sender error notification in case of 579 receiver proxy lies in the fact that the actual receiver can no 580 longer synchronize RSVP reservation with application state (since 581 the receiver does not participate in RSVP signaling), while the 582 sender can. This motivation does not apply in case of regular 583 receiver. 585 o there is a lot of existing code and deployed systems successfully 586 working under the current [RFC2205] model in the absence of proxy 587 today. The current behavior should not be changed for those 588 unless there were a very strong motivation. 590 3.2. Sender Notification via Notify Message 592 The OPTIONAL method for sender notification of reservation failure 593 defined in this section aims at providing a more efficient method 594 than the one defined in Section 3.1. Its objectives include : 596 o allow the failure notification to be sent directly upstream to the 597 sender by the router where the failure occurs (as opposed to first 598 travelling downstream towards the Receiver Proxy and then 599 travelling upstream from the Receiver Proxy to the sender, as 600 effectively happens with the method defined in Section 3.1) 602 o allow the failure notification to travel directly to the sender 603 without hop-by-hop RSVP processing 605 o ensure that such a notification is only sent to senders which are 606 capable and willing to process it (i.e. to synchronize reservation 607 status with application) 609 o ensure that such a notification is only sent in case the receiver 610 is not itself capable and willing to do the synchronisation with 611 the application (i.e. because we are in the presence of a receiver 612 proxy so that RSVP signaling is not visible to the receiver). 614 Note, however, that such benefits come at the cost of : 616 o a requirement for RSVP routers and senders to support the Notify 617 messages and procedures defined in [RFC3473] 619 o a requirement for senders to process Notify messages traveling 620 upstream but conveying a downstream notification. 622 [RFC3473] defines (in section "4.3 Notify Messages") the Notify 623 message that provides a mechanism to inform non-adjacent nodes of 624 events related to the RSVP reservation. The Notify message differs 625 from the error messages defined in [RFC2205] (i.e., PathErr and 626 ResvErr messages) in that it can be "targeted" to a node other than 627 the immediate upstream or downstream neighbor and that it is a 628 generalized notification mechanism. Notify messages are normally 629 generated only after a Notify Request object has been received. 631 This section discusses aspects of the use of the Notify message that 632 are specific to the RSVP Receiver Proxy. In any other aspects, the 633 Notify message operates as per [RFC3473]. 635 In order to achieve sender notification of reservation failure in the 636 context of the present document: 638 o an RSVP sender interested in being notified of reservation failure 639 MUST include a Notify Request object (containing the sender's IP 640 address) in the Path messages it generates 642 o Upon receiving a Path message with a Notify Request object, the 643 RSVP Receiver Proxy MUST include a Notify Request object in the 644 Resv messages it generates. This Notify Request object MUST 645 contain the address that was included in the Notify Request of the 646 received Path message- a.k.a. the sender's address- and not an 647 address of the Receiver Proxy. 649 As a result, as per existing Notify procedures, if an RSVP router 650 detects an error relating to a Resv state (e.g. Admission Control 651 rejection after IP reroute), the RSVP router will send a Notify 652 message (conveying the Resv Err code) to the IP address contained in 653 the Resv Notify Request object. Since this address has been set to 654 the sender's address by the Receiver Proxy, the Notify message is 655 sent to the sender. 657 Operation of the Path-Triggered RSVP Receiver Proxy in the case of an 658 admission control failure, using sender notification via Notify 659 Message, is illustrated in Figure 4. 661 |----| *** *** *** |----------| |----| 662 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 663 |----| *** *** *** | Receiver | |----| 664 | Proxy | 665 |----------| 667 ************************************************************> 669 ===================RSVP===================> 671 --Path*--> --Path*--> --Path*--> --Path*--> 673 <--Resv*-- <--Resv*-- 675 <------Notify------- 676 -ResvErr-> -ResvErr-> 678 |----| |----| *** 679 | S | Sender | R | Receiver *r* regular RSVP 680 |----| |----| *** router 682 ***> media flow 684 ==> segment of flow path protected by RSVP reservation 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 (2007). 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. 988 Acknowledgment 990 Funding for the RFC Editor function is provided by the IETF 991 Administrative Support Activity (IASA).