idnits 2.17.1 draft-ietf-tsvwg-rsvp-proxy-proto-01.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 871. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 889. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 895. 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 (June 26, 2007) is 6149 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 766, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG F. Le Faucheur 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Manner 5 Expires: December 28, 2007 University of Helsinki 6 A. Narayanan 7 Cisco 8 A. Guillou 9 Neuf 10 H. Malik 11 Bharti 12 June 26, 2007 14 RSVP Extensions for Path-Triggered RSVP Receiver Proxy 15 draft-ietf-tsvwg-rsvp-proxy-proto-01.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 December 28, 2007. 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 . . . . . . . . . 9 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 . . . . . . . . . . 15 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 81 7.2. Informative References . . . . . . . . . . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 83 Intellectual Property and Copyright Statements . . . . . . . . . . 25 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, however it assumes that both the sender and the 92 receiver of the data flow support RSVP. There are environments where 93 it would be useful to be able to reserve resources for a flow on at 94 least a subset of the flow path even when the sender or the receiver 95 (or both) is not RSVP-capable. 97 Since either the data sender or receiver may be unaware of RSVP, 98 there are two distinct use 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, tear down the RSVP reservation to 112 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 as the cue for 117 establishing the RSVP reservation on behalf of the non-RSVP-capable 118 receiver. The RSVP Receiver Proxy is effectively acting as a slave 119 making reservations (on behalf of the receiver) under the sender's 120 control. This changes somewhat the usual RSVP reservation model 121 where reservations are normally controlled by receivers. Such a 122 change greatly facilitates operations in the scenario of interest 123 here, which is where the receiver is not RSVP-capable. Indeed it 124 allows the RSVP Receiver Proxy to remain application unaware by 125 taking advantage of the application awareness and RSVP awareness of 126 the sender. 128 Since the synchronisation between RSVP reservation and application 129 requirement is now effectively performed by the sender, it is 130 important that the sender is aware of the reservation state. 131 However, as conventional RSVP assumes that the reservation is to be 132 controlled by the receiver, some notifications about reservation 133 state (notably the error message sent in case of admission control 134 rejection of the reservation) are only sent to the receiver. This 135 document specifies extension to RSVP procedures allowing such 136 notifications to be also conveyed to the sender. This facilitates 137 synchronization by the sender between RSVP reservation and 138 application requirements in scenarios involving a Path-Triggered RSVP 139 receiver Proxy. 141 1.1. Conventions Used in This Document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 2. Terminology 149 RSVP-capable (or RSVP-aware): which supports the RSVP protocol as per 150 [RFC2205] 152 RSVP Receiver Proxy: an RSVP-capable router performing, on behalf of 153 a receiver, the RSVP operations which would normally be performed by 154 an RSVP-capable receiver if end-to-end RSVP signaling was used. Note 155 that while RSVP is used upstream of the RSVP Receiver Proxy, RSVP is 156 not used downstream of the RSVP Receiver Proxy. 158 RSVP Sender Proxy: an RSVP-capable router performing, on behalf of a 159 sender, the RSVP operations which would normally be performed by an 160 RSVP-capable sender if end-to-end RSVP signaling was used. Note that 161 while RSVP is used downstream of the RSVP Sender Proxy, RSVP is not 162 used upstream of the RSVP Sender Proxy. 164 Regular RSVP Router: an RSVP-capable router which is not behaving as 165 a RSVP Receiver Proxy nor as a RSVP Sender Proxy. 167 Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, 168 Regular RSVP Router are all relative to one unidirectional flow. A 169 given router may act as the RSVP Receiver Proxy for a flow, as the 170 RSVP Sender Proxy for another flow and as a Regular RSVP router for 171 yet another flow. 173 3. RSVP Extensions for Sender Notification 175 This section defines extensions to RSVP procedures allowing 176 notification of the sender of reservation failure. This facilitates 177 synchronization by the sender between RSVP reservation and 178 application requirements in scenarios involving a Path-Triggered RSVP 179 receiver Proxy. 181 As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], with the 182 Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be 183 configured to use receipt of a regular RSVP Path message as the 184 trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP 185 Path message, the RSVP Receiver Proxy: 187 1. establishes the RSVP Path state as per regular RSVP processing 189 2. identifies the downstream interface towards the receiver 191 3. sinks the Path message 193 4. behaves as if a Resv message (whose details are discussed below) 194 was received on the downstream interface. This includes 195 performing admission control on the downstream interface, 196 establishing a Resv state (in case of successful admission 197 control) and forwarding the Resv message upstream, sending 198 periodic refreshes of the Resv message and tearing down the 199 reservation if the Path state is torn down. 201 Operation of the Path-Triggered Receiver Proxy in the case of a 202 successful reservation is illustrated in Figure 1. 204 |----| *** *** |----------| |----| 205 | S |---------*r*----------*r*---------| RSVP |----------| R | 206 |----| *** *** | Receiver | |----| 207 | Proxy | 208 |----------| 210 *************************************************************> 212 ===================RSVP======================> 214 ---Path---> ----Path----> ---Path----> 216 <--Resv---> <---Resv----- <--Resv---- 218 |----| RSVP-capable |----| Non-RSVP-capable *** 219 | S | Sender | R | Receiver *r* regular RSVP 220 |----| |----| *** router 222 ***> media flow 224 ==> segment of flow path protected by RSVP reservation 226 Figure 1: Successful Reservation 228 We observe that, in the case of successful reservation, conventional 229 RSVP procedures ensure that the sender is notified of the successful 230 reservation establishment. Thus, no extensions are required in the 231 presence of a Path-Triggered RSVP Receiver Proxy in the case of 232 successful reservation establishment. 234 However, in case of reservation failure, conventional RSVP procedures 235 only ensure that the receiver (or the RSVP Receiver Proxy) is 236 notified of the reservation failure. Specifically, in case of an 237 admission control rejection on a regular RSVP router, a ResvErr 238 message is sent downstream towards the receiver. In the presence of 239 an RSVP Receiver Proxy, if we simply follow conventional RSVP 240 procedures, this means that the RSVP Receiver Proxy is notified of 241 the reservation failure, but the sender is not. Operation of the 242 Path-Triggered RSVP Receiver Proxy in the case of an admission 243 control failure, assuming conventional RSVP procedures, is 244 illustrated in Figure 2. 246 |----| *** *** |----------| |----| 247 | S |---------*r*----------*r*---------| RSVP |----------| R | 248 |----| *** *** | Receiver | |----| 249 | Proxy | 250 |----------| 252 *************************************************************> 254 ===================RSVP======================> 256 ---Path---> ----Path----> ---Path----> 258 <---Resv----- <--Resv------ 260 ---ResvErr---> --ResvErr---> 262 |----| |----| *** 263 | S | Sender | R | Receiver *r* regular RSVP 264 |----| |----| *** router 266 ***> media flow 268 ==> segment of flow path protected by RSVP reservation 270 Figure 2: Reservation Failure With Conventional RSVP 272 While the sender could infer reservation failure from the fact that 273 it has not received a Resv message after a certain time, there are 274 clear benefits in ensuring that the sender gets a prompt explicit 275 notification in case of reservation failure. 277 Section 3.1 defines a method which can be used to achieve sender 278 notification of reservation failure. An implementation of this 279 document MUST support the method defined in Section 3.1. 281 Section 3.2 defines another method which can be used to achieve 282 sender notification of reservation failure. An implementation of 283 this document MAY support the method defined in Section 3.2. 285 3.1. Sender Notification via PathErr Message 287 With this method, the RSVP Receiver Proxy MUST generate a PathErr 288 message whenever the two following conditions are met: 290 1. The reservation establishment has failed (or the previously 291 established reservation has been torn down) 293 2. The RSVP Receiver Proxy determines that it cannot re-establish 294 the reservation (e.g. by adapting its reservation request in 295 reaction to the error code provided in the received ResvErr in 296 accordance with local policy) 298 Note that this notion of generating a PathErr message upstream in 299 order to notify the sender about a reservation failure is not 300 completely new. It is borrowed from [RFC3209] where it has been 301 introduced in order to achieve a similar requirement, which is to 302 allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end 303 (i.e. the sender) of a failure to establish (or maintain) a TE Tunnel 304 Label Switch Path. 306 Operation of the Path-Triggered RSVP Receiver Proxy in the case of an 307 admission control failure, using sender notification via PathErr 308 Message, is illustrated in Figure 3. 310 |----| *** *** |----------| |----| 311 | S |---------*r*----------*r*---------| RSVP |----------| R | 312 |----| *** *** | Receiver | |----| 313 | Proxy | 314 |----------| 316 *************************************************************> 318 ===================RSVP======================> 320 ---Path---> ----Path----> ---Path----> 322 <---Resv----- <--Resv------ 324 ---ResvErr---> --ResvErr---> 326 <--PathErr- <--PathErr--- <--PathErr--- 328 |----| |----| *** 329 | S | Sender | R | Receiver *r* regular RSVP 330 |----| |----| *** router 332 ***> media flow 334 ==> segment of flow path protected by RSVP reservation 336 Figure 3: Reservation Failure With Sender Notification via PathErr 338 The role of this PathErr is to notify the sender that the reservation 339 was not established or was torn down. This may be in the case of 340 receipt of a ResvErr, or because of local failure on the Receiver 341 Proxy. On receipt of a ResvErr, in all situations where the 342 reservation cannot be installed, the Receiver Proxy MUST generate a 343 PathErr towards the sender. For local failures on the Receiver Proxy 344 node, if a similar failure on an RSVP midpoint would cause the 345 generation of a ResvErr (for example, CAC failure), the Receiver 346 Proxy MUST generate a PathErr towards the sender. The Receiver Proxy 347 MAY additionally generate a PathErr upon local failures which would 348 not ordinarily cause generation of a ResvErr message, such as 349 described in Appendix B of [RFC2205]. 351 The PathErr generated by the Receiver Proxy corresponds to the 352 sender(s) which triggered generation of Resv messages that failed. 353 For Fixed-Filter (FF) style reservations, the Receiver Proxy sends a 354 PathErr towards the (single) sender matching the failed reservation. 356 For Shared-Explicit (SE) style reservations, the Receiver Proxy sends 357 the PathErr(s) towards the set of senders which triggered 358 reservations that failed. This may be a subset of senders sharing 359 the same reservation, in which case the remaining senders would have 360 their reservation intact and would not receive a PathErr. In both 361 cases, the rules described in Section 3.1.8 of [RFC2205] for 362 generating flow descriptors in ResvErr messages, also apply for 363 generating sender descriptors in PathErr messages. 365 For Wildcard-Filter (WF) style reservations, it is not possible for 366 the receiver to know which sender caused the reservation failure. 367 Therefore, the procedures described in this section do not apply to 368 WF-style reservations. 370 The procedures described in this section apply to both unicast and 371 multicast sessions. However, for a multicast session, it is possible 372 that reservation failure (e.g. admission control failure) in a node 373 close to a sender may cause ResvErr messages to be sent to a large 374 group of receivers. These receivers would, in turn, all send PathErr 375 messages back to the same sender, which could cause a scalability 376 issue in some environments. From the perspective of the sender, 377 errors that prevent a reservation from being set up can be classified 378 in two ways: 380 1. Errors which the sender can attempt to correct. The error code 381 for those errors should explicitly be communicated back to the 382 sender. An examples of this is "Class 1: Admission Control 383 Failure", because the sender could potentially resend a Path with 384 smaller traffic parameters. 386 2. Errors which the sender has no control over. For these errors, 387 it is sufficient to notify the sender that the reservation was 388 not set up successfully. An example of this is "Class 13: 389 Unknown Object", because the sender has no control over the 390 objects inserted into the reservation by the Receiver Proxy. 392 The PathErr message generated by the Receiver Proxy has the same 393 format as regular PathErr messages defined in [RFC2205]. The 394 SESSION, ERROR_SPEC and sender descriptor are composed by the 395 Receiver Proxy as specified in the following subsections. The 396 Receiver Proxy MAY reflect back to the sender in the PathErr any 397 POLICY_DATA objects received in the ResvErr. 399 3.1.1. Composition of SESSION and 401 The Receiver Proxy MUST insert the SESSION object corresponding to 402 the failed reservation, into the PathErr. For Fixed-Filter (FF) 403 style reservations, the Receiver Proxy MUST insert a corresponding to the failed reservation, into the 405 PathErr. This is equal to the in the ResvErr 406 received by the Receiver Proxy. For Shared-Explicit (SE) style 407 reservations, the Receiver Proxy MUST insert a 408 corresponding to the sender triggering the failed reservation, into 409 the PathErr. This is equal to the in the ResvErr 410 received by the Receiver Proxy. If multiple could 411 not be admitted at a midpoint node, that node would generate multiple 412 ResvErrs messages towards the receiver as per Section 3.1.8 of 413 [RFC2205]. Each ResvErr would contain a that 414 matches a specific sender. The Receiver Proxy MUST generate a 415 PathErr for each ResvErr received, towards the corresponding sender. 417 3.1.2. Composition of ERROR_SPEC 419 The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into 420 the PathErr as follows: 422 1. If the Receiver Proxy receives a ResvErr with any of these error 423 codes: "Code 1 - Admission Control Failure" or "Code 2 - Policy 424 Control Failure" then the Receiver Proxy copies the error code 425 and value from the ERROR_SPEC in the ResvErr, into the ERROR_SPEC 426 of the PathErr message. The error node in the PathErr MUST be 427 set to the address of the Receiver Proxy. This procedure MUST 428 also be followed for a local error on the Receiver Proxy that 429 would ordinarily cause a midpoint to generate a ResvErr with one 430 of the above codes. 432 2. If the Receiver Proxy receives a ResvErr with any error code 433 other than the ones listed in 1 above, it composes a new 434 ERROR_SPEC with error code ": Unrecoverable Receiver Proxy Error". The error node in 436 the PathErr MUST be set to the address of the Receiver Proxy. 437 This procedure MUST also be followed for a local error on the 438 Receiver Proxy that would ordinarily cause a midpoint to generate 439 a ResvErr with any error code except than those listed in 1 440 above, or if the Receiver Proxy generates a PathErr for a local 441 error which ordinarily would not cause generation of a ResvErr. 442 In some cases it may be predetermined that the PathErr will not 443 reach the sender. For example, a node receiving a ResvErr with 444 "Code 3: No Path for Resv", knows a priori that the PathErr 445 message it generates cannot be forwarded by the same node which 446 could not process the Resv. Nevertheless, the procedures above 447 MUST be followed. For the error code ": Unrecoverable Receiver Proxy Error", the 449 16 bits of the Error Value field are: 451 * hhhh hhhh llll llll 453 where the bits are: 455 * hhhh hhhh = 0000 0000: then the low order 8 bits (llll llll) 456 MUST be set by Receiver Proxy to 0000 0000 and MUST be ignored 457 by the sender. 459 * hhhh hhhh = 0000 0001: then the low order 8 bits (llll llll) 460 MUST be set by the Receiver Proxy to the value of the error 461 code received in the ResvErr ERROR_SPEC (or, in case the 462 Receiver Proxy generated the PathErr without having received a 463 ResvErr, to the error code value that would have been included 464 by the Receiver Proxy in the ERROR_SPEC in similar conditions 465 if it was to generate a ResvErr). This error value MAY be 466 used by the sender to further interpret the reason of the 467 reservation failure. 469 * hhhh hhhh = any other value: reserved. 471 3. If the Receiver Proxy Receives a ResvErr with the InPlace flag 472 set in the ERROR_SPEC, it MUST also set the InPlace flag in the 473 ERROR_SPEC of the PathErr. 475 3.1.3. Use of Path_State_Removed Flag 477 [RFC3473] defines an optional behavior whereby a node forwarding a 478 PathErr message can remove the Path State associated with the PathErr 479 message and indicate so by including the Path_State_Removed flag in 480 the ERROR_SPEC object of the PathErr message. This can be used in 481 some situations to expedite release of resources and minimise 482 signaling load. 484 By default, the RSVP Receiver Proxy MUST not include the 485 Path_State_Removed flag in the ERROR_SPEC of the PathErr message. 486 This ensures predictable operations in all environments including 487 those where some RSVP routers do not understand the 488 Path_State_Removed flag. 490 Optionally, the RSVP Receiver Proxy MAY support a configurable mode 491 whereby the RSVP Receiver Proxy includes the Path_State_Removed flag 492 in the ERROR_SPEC of the PathErr message and removes its local Path 493 state. This can be used in environments where all RSVP routers are 494 known to support the Path_State_Removed flag thereby reliably 495 achieving expedited resource release. 497 3.1.4. Use of PathErr by Regular Receivers 499 Note that while this document specifies that an RSVP Receiver Proxy 500 generates a PathErr upstream in case of reservation failure, this 501 document does NOT propose that the same be done by regular receivers. 502 In other words, this document does NOT propose to modify the behavior 503 of regular receivers as currently specified in [RFC2205]. The 504 rationale for this includes the following: 506 o when the receiver is RSVP capable, the current receiver-driven 507 model of [RFC2205] is fully applicable because the receiver can 508 synchronise RSVP reservation state and application state (since it 509 participates in both). The sender(s) needs not be aware of the 510 RSVP reservation state. Thus, we can retain the benefits of 511 receiver-driven operations which were explicitly sought by 512 [RFC2205]. Quoting from it: " In order to efficiently accommodate 513 large groups, dynamic group membership, and heterogeneous receiver 514 requirements, RSVP makes receivers responsible for requesting a 515 specific QoS". But even for the most simple single_sender/ 516 single_receiver reservations, the current receiver-driven model 517 reduces signaling load and per-hop RSVP processing by not sending 518 any error message to the sender in case of CAC reject. 520 o the motivation for adding sender error notification in case of 521 receiver proxy lies in the fact that the actual receiver can no 522 lomger synchronize RSVP reservation with application state (since 523 the receiver does not participate in RSVP signaling), while the 524 sender can. This motivation does not apply in case of regular 525 receiver. 527 o there is a lot of existing code and deployed systems successfully 528 working under the current [RFC2205] model in the absence of proxy 529 today. The current behavior should not be changed for those 530 unless there were a very strong motivation. 532 3.2. Sender Notification via Notify Message 534 The optional method for sender notification of reservation failure 535 defined in this section aims at providing a more efficient method 536 than the one defined in Section 3.1. Its objectives include : 538 o allow the failure notification to be sent directly upstream to the 539 sender by the router where the failure occurs (as opposed to first 540 travelling downstream towards the Receiver Proxy and then 541 travelling upstream from the Receiver Proxy to the sender, as 542 effectively happens with the method defined in Section 3.1) 544 o allow the failure notification to travel directly to the sender 545 without hop-by-hop RSVP processing 547 o ensure that such a notification is only sent to senders which are 548 capable and willing to process it (i.e. to synchronize reservation 549 status with application) 551 o ensure that such a notification is only sent in case the receiver 552 is not itself capable and willing to do the synchronisation with 553 the application (i.e. because we are in the presence of a receiver 554 proxy so that RSVP signaling is not visible to the receiver) 556 Note, however, that such benefits come at the cost of more 557 sophistication and of a requirement for RSVP routers and senders to 558 support the Notify messages and procedures defined in [RFC3473]. 560 [RFC3473] defines (in section "4.3 Notify Messages") the Notify 561 message that provides a mechanism to inform non-adjacent nodes of 562 events related to the RSVP reservation. The Notify message differs 563 from the currently defined error messages (i.e., PathErr and ResvErr 564 messages) in that it can be "targeted" to a node other than the 565 immediate upstream or downstream neighbor and that it is a 566 generalized notification mechanism. Notify messages are normally 567 generated only after a Notify Request object has been received. 569 In order to achieve sender notification of reservation failure in the 570 context of the present document: 572 o an RSVP sender interested in being notified of reservation failure 573 MUST include a Notify Request object (containing the sender's IP 574 address) in the Path messages it generates 576 o Upon receiving a Path message with a Notify Request object, the 577 RSVP Receiver Proxy MUST include a Notify Request object in the 578 Resv messages it generates. This Notify Request object MUST 579 contain the address that was included in the Notify Request of the 580 received Path message- a.k.a. the sender's address- and not an 581 address of the Receiver Proxy. 583 As a result, as per existing Notify procedures, if an RSVP router 584 detects an error relating to a Resv state (e.g. Admission Control 585 rejection after IP reroute), the RSVP router will send a Notify 586 message (conveying the Resv Err code) to the IP address contained in 587 the Resv Notify Request object. Since this address has been set to 588 the sender's address by the Receiver Proxy, the Notify message is 589 sent directly to the sender. 591 Operation of the Path-Triggered RSVP Receiver Proxy in the case of an 592 admission control failure, using sender notification via Notify 593 Message, is illustrated in Figure 4. 595 |----| *** *** |----------| |----| 596 | S |---------*r*----------*r*---------| RSVP |----------| R | 597 |----| *** *** | Receiver | |----| 598 | Proxy | 599 |----------| 601 *************************************************************> 603 ===================RSVP======================> 605 ---Path*--> ----Path*---> ---Path*---> 607 <---Resv*--- <--Resv*---- 609 <--Notify-- 610 ---ResvErr---> --ResvErr---> 612 |----| |----| *** 613 | S | Sender | R | Receiver *r* regular RSVP 614 |----| |----| *** router 616 ***> media flow 618 ==> segment of flow path protected by RSVP reservation 620 Path* = Path message containing a Notify Request object 621 with sender IP Address 623 Resv* = Resv message containing a Notify Request object 624 with sender IP address 626 Figure 4: Reservation Failure With Sender Notification via Notify 628 For local failures on the Receiver Proxy node, if a similar failure 629 on an RSVP midpoint would cause the generation of a ResvErr (for 630 example, CAC failure), the Receiver Proxy MUST generate a Notify 631 towards the sender. The Receiver Proxy MAY additionally generate a 632 Notify upon local failures which would not ordinarily cause 633 generation of a ResvErr message, such as described in Appendix B of 634 [RFC2205]. 636 4. Security Considerations 638 To ensure the integrity of the associated reservation and admission 639 control mechanisms, the RSVP Authentication mechanisms defined in 640 [RFC2747] and [RFC3097] may be used. These protect RSVP message 641 integrity hop-by-hop and provide node authentication as well as 642 replay protection, thereby protecting against corruption and spoofing 643 of RSVP messages. These hop-by-hop integrity mechanisms can be used 644 to protect the RSVP reservations established using an RSVP receiver 645 proxy in accordance with the present document. 647 [RFC2747] discusses several approaches for key distribution. First, 648 the RSVP Authentication shared keys can be distributed manually. 649 This is the base option and its support is mandated for any 650 implementation. However, in some environments, this approach may 651 become a burden if keys frequently change over time. Alternatively, 652 a standard key management protocol for secure key distribution can be 653 used. However, existing key distribution protocols may not be 654 appropriate in all environments because of the complexity or 655 operational burden they involve. 657 The use of RSVP Authentication in parts of the network where there 658 may be one or more IP hops in between two RSVP neighbors raises an 659 additional challenge. This is because, with some RSVP messages such 660 as a Path message, an RSVP router does not know the RSVP next hop for 661 that message at the time of forwarding it. In fact, part of the role 662 of a Path message is precisely to discover the RSVP next hop (and to 663 dynamically re-discover it when it changes, say because of a routing 664 change). Hence, the RSVP router may not know which security 665 association to use when forwarding such a message. In that 666 situation, one approach is to share the same RSVP Authentication 667 shared key across all the RSVP routers of a part of the network where 668 there may be RSVP neighbors with IP hops in between. For example, 669 all the RSVP routers of an administrative domain (including the 670 receiver proxys) could share the same RSVP Authentication key, while 671 different per-neighbor keys could be used between any RSVP router 672 pair straddling the boundary between two administrative domains that 673 have agreed to use RSVP signaling. 675 When the same RSVP Authentication shared key is to be shared among 676 multiple RSVP neighbors, manual key distribution may be used. It 677 might also be possible, in the future, to adapt a multicast dynamic 678 group key distribution method (e.g. from IETF Multicast Security 679 Working Group) for dynamic key distribution among RSVP nodes. This 680 is discussed in [I-D.behringer-tsvwg-rsvp-security-groupkeying]. For 681 situations where RSVP is being used for unicast flows across domain 682 boundaries, it is not currently clear how one might provide automated 683 key management. 685 The RSVP Authentication mechanisms do not provide confidentiality. 686 If confidentiality is required, IPsec ESP ([RFC4303]) may be used, 687 although it imposes the burden of key distribution. It also faces 688 the additional issue discussed for key management above in the case 689 where there can be IP hops in between RSVP hops. In the future, 690 confidentiality solutions may be developed for the case where there 691 can be IP hops in between RSVP hops, perhaps again by adapting 692 confidentiality solutions developed by the IETF MSEC Working Group. 693 Such confidentiality solutions for RSVP are outside the scope of this 694 document. 696 When an RSVP receiver proxy is used, the RSVP reservation is no 697 longer controlled by the receiver, but rather is controlled by the 698 receiver proxy (using hints received from the sender in the Path 699 message) on behalf of the sender. Thus, the receiver proxy ought to 700 be trusted by the end-systems to control the RSVP reservation 701 appropriately. However, basic RSVP operation already assumes a trust 702 model where end-systems trust RSVP nodes to appropriately perform 703 RSVP reservations. So the use of RSVP receiver proxy is not seen as 704 introducing any significant additional security threat or as 705 modifying the RSVP trust model. 707 In fact, there are situations where the use of RSVP receiver proxy 708 reduces the security risks. One example is where a network operator 709 relies on RSVP to perform resource reservation and admission control 710 within a network and where RSVP senders and RSVP routers are located 711 in the operator premises while the many RSVP receivers are located in 712 the operator's customers premises. Such an environment is further 713 illustrated in "Annex A.1. RSVP-based VoD CAC in Broadband 714 Aggregation Networks" of [I-D.ietf-tsvwg-rsvp-proxy-approaches]. 715 From the operator's perspective, the RSVP routers and RSVP senders 716 are in physically secured locations and therefore exposed to a lower 717 risk of being tampered with; While the receivers are in locations 718 which are physically unsecured and therefore subject to a higher risk 719 of being tampered with. The use of an RSVP receiver proxy function 720 effectively increases the security of the operator's reservation and 721 admission control solution by completely excluding receivers from its 722 operation. Filters can be placed at the edge of the operator network 723 discarding any RSVP message received from end-users. This provides a 724 very simple and effective protection of the RSVP reservation and 725 admission control solution operating inside the operator's network. 727 5. IANA Considerations 729 Since, as discussed in Section 3.1.2, this document allows two Error 730 Codes to be used in PathErr messages while [RFC2205] only specified 731 their use in ResvErr messages, this document requires that IANA 732 updates the existing entries for these two Error Codes under the 733 "Error Codes and Globally-Defined Error Value Sub-Codes" registry. 734 Each entry should refer to this document, in addition to referring to 735 [RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2 736 should respectively read: 738 " 740 1 Admission Control Failure [RFC2205] [RFCXXX] 742 ... 744 2 Policy Control Failure [RFC2205] [RFCXXX] 746 ... 748 " 750 where [RFCXXX] refers to this document. 752 This document also requires that IANA allocates a new RSVP Error Code 753 ": Unrecoverable Receiver Proxy Error", as discussed in 754 Section 3.1.2. This Error Code is to be allocated under the "Error 755 Codes and Globally-Defined Error Value Sub-Codes" registry. The 756 entry for this error code should read: 758 " 760 TBD Unrecoverable Receiver Proxy Error [RFCXXX] 762 The sixteen bits of the Error Value field are defined in [RFCXXX] 764 " 766 where [RFCXXX] refers to this document and TBD is the value to be 767 allocated by IANA. 769 6. Acknowledgments 771 This document benefited from discussions with Carol Iturralde and 772 Amca Zamfir. 774 7. References 776 7.1. Normative References 778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 779 Requirement Levels", BCP 14, RFC 2119, March 1997. 781 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 782 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 783 Functional Specification", RFC 2205, September 1997. 785 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 786 Authentication", RFC 2747, January 2000. 788 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 789 Authentication -- Updated Message Type Value", RFC 3097, 790 April 2001. 792 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 793 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 794 Tunnels", RFC 3209, December 2001. 796 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 797 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 798 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 800 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 801 RFC 4303, December 2005. 803 7.2. Informative References 805 [I-D.behringer-tsvwg-rsvp-security-groupkeying] 806 Behringer, M., Le Faucheur, F., and F. Baker, "A Framework 807 for RSVP Security Using Dynamic Group Keying", July 2007. 809 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 810 Le Faucheur, F., Manner, J., Wing, D., and A. Guillou, 811 "RSVP Proxy Approaches", July 2007. 813 Authors' Addresses 815 Francois Le Faucheur 816 Cisco Systems 817 Greenside, 400 Avenue de Roumanille 818 Sophia Antipolis 06410 819 France 821 Phone: +33 4 97 23 26 19 822 Email: flefauch@cisco.com 824 Jukka Manner 825 University of Helsinki 826 P.O. Box 68 827 University of Helsinki FIN-00014 University of Helsinki 828 Finland 830 Phone: +358 9 191 51298 831 Email: jmanner@cs.helsinki.fi 832 URI: http://www.cs.helsinki.fi/u/jmanner/ 834 Ashok Narayanan 835 Cisco Systems 836 300 Beaver Brook Road 837 Boxborough, MAS 01719 838 United States 840 Email: ashokn@cisco.com 842 Allan Guillou 843 Neuf Cegetel 844 40-42 Quai du Point du Jour 845 Boulogne-Billancourt, 92659 846 France 848 Email: allan.guillou@neufcegetel.fr 849 Hemant Malik 850 Bharti Airtel Ltd. 851 4th Floor, Tower A, Unitech Cyber Park 852 Gurgaon, Sector 39, 122001 853 India 855 Email: Hermant.Malik@airtel.in 857 Full Copyright Statement 859 Copyright (C) The IETF Trust (2007). 861 This document is subject to the rights, licenses and restrictions 862 contained in BCP 78, and except as set forth therein, the authors 863 retain all their rights. 865 This document and the information contained herein are provided on an 866 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 867 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 868 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 869 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 870 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 871 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 873 Intellectual Property 875 The IETF takes no position regarding the validity or scope of any 876 Intellectual Property Rights or other rights that might be claimed to 877 pertain to the implementation or use of the technology described in 878 this document or the extent to which any license under such rights 879 might or might not be available; nor does it represent that it has 880 made any independent effort to identify any such rights. Information 881 on the procedures with respect to rights in RFC documents can be 882 found in BCP 78 and BCP 79. 884 Copies of IPR disclosures made to the IETF Secretariat and any 885 assurances of licenses to be made available, or the result of an 886 attempt made to obtain a general license or permission for the use of 887 such proprietary rights by implementers or users of this 888 specification can be obtained from the IETF on-line IPR repository at 889 http://www.ietf.org/ipr. 891 The IETF invites any interested party to bring to its attention any 892 copyrights, patents or patent applications, or other proprietary 893 rights that may cover technology that may be required to implement 894 this standard. Please address the information to the IETF at 895 ietf-ipr@ietf.org. 897 Acknowledgment 899 Funding for the RFC Editor function is provided by the IETF 900 Administrative Support Activity (IASA).