idnits 2.17.1 draft-ietf-tsvwg-rsvp-proxy-proto-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2009) is 5527 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 1081, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-rsvp-proxy-approaches-06 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 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: September 3, 2009 University of Helsinki 6 A. Narayanan 7 Cisco 8 A. Guillou 9 Neuf 10 H. Malik 11 Bharti 12 March 2, 2009 14 RSVP Extensions for Path-Triggered RSVP Receiver Proxy 15 draft-ietf-tsvwg-rsvp-proxy-proto-08.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may contain material 21 from IETF Documents or IETF Contributions published or made publicly 22 available before November 10, 2008. The person(s) controlling the 23 copyright in some of this material may not have granted the IETF 24 Trust the right to allow modifications of such material outside the 25 IETF Standards Process. Without obtaining an adequate license from 26 the person(s) controlling the copyright in such materials, this 27 document may not be modified outside the IETF Standards Process, and 28 derivative works of it may not be created outside the IETF Standards 29 Process, except to format it for publication as an RFC or to 30 translate it into languages other than English. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on September 3, 2009. 50 Copyright Notice 52 Copyright (c) 2009 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents in effect on the date of 57 publication of this document (http://trustee.ietf.org/license-info). 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. 61 Abstract 63 RSVP signaling can be used to make end-to-end resource reservations 64 in an IP network in order to guarantee the QoS required by certain 65 flows. With conventional RSVP, both the data sender and receiver of 66 a given flow take part in RSVP signaling. Yet, there are many use 67 cases where resource reservation is required, but the receiver, the 68 sender, or both, is not RSVP-capable. Where the receiver is not 69 RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy 70 thereby performing RSVP signaling on behalf of the receiver. This 71 allows resource reservations to be established on the segment of the 72 end-to-end path from the sender to the RSVP Receiver Proxy. However, 73 as discussed in the companion document presenting RSVP Proxy 74 approaches, RSVP extensions are needed to facilitate operations with 75 an RSVP Receiver Proxy whose signaling is triggered by receipt of 76 RSVP Path messages from the sender. This document specifies these 77 extensions. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 1.1. Conventions Used in This Document . . . . . . . . . . . . 7 83 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 3. RSVP Extensions for Sender Notification . . . . . . . . . . . 9 85 3.1. Sender Notification via PathErr Message . . . . . . . . . 12 86 3.1.1. Composition of SESSION and Sender Descriptor . . . . . 15 87 3.1.2. Composition of ERROR_SPEC . . . . . . . . . . . . . . 15 88 3.1.3. Use of Path_State_Removed Flag . . . . . . . . . . . . 16 89 3.1.4. Use of PathErr by Regular Receivers . . . . . . . . . 17 90 3.2. Sender Notification via Notify Message . . . . . . . . . . 18 91 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 92 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 93 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 94 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 95 7.1. Normative References . . . . . . . . . . . . . . . . . . . 30 96 7.2. Informative References . . . . . . . . . . . . . . . . . . 30 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 99 1. Introduction 101 Guaranteed QoS for some applications with tight Qos requirements may 102 be achieved by reserving resources in each node on the end-to-end 103 path. The main IETF protocol for these resource reservations is RSVP 104 specified in [RFC2205]. RSVP does not require that all intermediate 105 nodes support RSVP, but it assumes that both the sender and the 106 receiver of the data flow support RSVP. However, there are 107 environments where it would be useful to be able to reserve resources 108 for a flow (at least a subset of the flow path) even when the sender 109 or the receiver (or both) is not RSVP-capable. 111 Since both the data sender and receiver may be unaware of RSVP, there 112 are two types of RSVP Proxies. In the first case, an entity in the 113 network needs to invoke RSVP on behalf of the data sender and thus 114 generate RSVP Path messages, and eventually receive, process and sink 115 Resv messages. We refer to this entity as the RSVP Sender Proxy. In 116 the second case, an entity in the network need to operate RSVP on 117 behalf of the receiver and thus receive Path messages sent by a data 118 sender (or by an RSVP Sender Proxy), and reply to those with Resv 119 messages generated on behalf of the data receiver(s). We refer to 120 this entity as the RSVP Receiver Proxy. 122 RSVP Proxy approaches are presented in 123 [I-D.ietf-tsvwg-rsvp-proxy-approaches]. That document also 124 discusses, for each approach, how the reservations controlled by the 125 RSVP Proxy can be synchronized with the application requirements 126 (e.g., when to establish, maintain and tear down the RSVP reservation 127 to satisfy application requirements). 129 One RSVP Proxy approach is referred to as the Path-Triggered RSVP 130 Receiver Proxy approach. With this approach, the RSVP Receiver Proxy 131 uses the RSVP Path messages generated by the sender (or RSVP Sender 132 Proxy) as the cue for establishing the RSVP reservation on behalf of 133 the non-RSVP-capable receiver(s). The RSVP Receiver Proxy is 134 effectively acting as an intermediary making reservations (on behalf 135 of the receiver) under the sender's control (or RSVP Sender Proxy's 136 control). This changes somewhat the usual RSVP reservation model 137 where reservations are normally controlled by receivers. Such a 138 change greatly facilitates operations in the scenario of interest 139 here, which is where the receiver is not RSVP-capable. Indeed it 140 allows the RSVP Receiver Proxy to remain application unaware by 141 taking advantage of the application awareness and RSVP awareness of 142 the sender (or RSVP Sender Proxy). 144 Since the synchronization between an RSVP reservation and an 145 application is now effectively performed by the sender (or RSVP 146 Sender Proxy), it is important that the sender (or RSVP Sender Proxy) 147 is aware of the reservation state. However, as conventional RSVP 148 assumes that the reservation is to be controlled by the receiver, 149 some notifications about reservation state (notably the error message 150 sent in case of admission control rejection of the reservation) are 151 only sent towards the receiver and therefore, in our case, sunk by 152 the RSVP Receiver Proxy. This document specifies extension to RSVP 153 procedures allowing such notifications also to be conveyed towards 154 the sender. This facilitates synchronization by the sender (or RSVP 155 Sender Proxy) between the RSVP reservation and the application 156 requirements and facilitates sender-driven control of reservation in 157 scenarios involving a Path-Triggered RSVP receiver Proxy. 159 With unicast applications in the presence of RSVP Receiver Proxies, 160 if the sender is notified about the state of the reservation towards 161 the receiver (as enabled by the present document), the sender is 162 generally in a good position to synchronize the reservation with the 163 application and to perform efficient sender-driven reservation: the 164 sender can control establishment (respectively removal) of the 165 reservation towards the receiver by sending Path (respectively 166 PathTear) messages. For example, if the sender is notified that the 167 reservation for a point to point audio session towards the receiver 168 is rejected, the sender may trigger rejection of the session at the 169 application layer and may issue a PathTear message to remove any 170 corresponding RSVP state (e.g. Path states) previously established. 172 However, we note that multicast applications do not always mesh well 173 with RSVP Receiver Proxies, since sender notification about 174 reservation state towards each RSVP Receiver Proxy may not be 175 sufficient to achieve tight application level synchronization by 176 multicast senders. These limitations stem from the fact that 177 multicast operation is receiver-driven and, while end-to-end RSVP is 178 also receiver-driven (precisely to deal with multicast efficiently), 179 the use of RSVP Receiver Proxies only allows sender-driven 180 reservation. For example, a sender generally is not aware of which 181 receivers have joined downstream of a given RSVP Receiver Proxy, or 182 even which RSVP Receiver Proxies have joined downstream of a given 183 failure point. Therefore, it may not be possible to support a mode 184 of operation whereby a given receiver only joins a group if that 185 receiver can be protected by a reservation. Additionally, a sender 186 may have no recourse if only a subset of RSVP Receiver Proxies return 187 successful reservations (even if application-level signalling runs 188 between the sender and receivers), since the sender may not be able 189 to correctly identify the set of receivers who do not have 190 reservations. However, it is possible to support a mode of operation 191 whereby multicast traffic is transmitted if and only if all receivers 192 are protected by a reservation (from sender to their respective RSVP 193 Receiver Proxy): the sender can ensure this by sending a PathTear 194 message and stopping transmission whenever it gets a notification for 195 reservation reject for one or more RSVP Receiver Proxy. It is also 196 possible to support a mode of operation whereby receivers join 197 independently of whether they can be protected by a reservation (to 198 their respective RSVP Receiver Proxy) or not, but do benefit from a 199 reservation whenever the corresponding resources are reservable on 200 the relevant path. 202 This document discusses extensions to facilitate operations in the 203 presence of a Path-triggered RSVP Receiver Proxy. As pointed out 204 previously, those apply equally whether RSVP signaling is initiated 205 by a regular RSVP sender or by an RSVP Sender Proxy (with some means 206 to synchronize reservation state with application level requirements 207 that are outside the scope of this document). For readability, the 208 rest of this document discusses operation assuming a regular RSVP 209 sender; however, such operation is equally applicable where an RSVP 210 Sender Proxy is used to initiated RSVP signaling on behalf of a non- 211 RSVP-capable sender. 213 1.1. Conventions Used in This Document 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in [RFC2119]. 219 2. Terminology 221 The following terminology is borrowed from 222 [I-D.ietf-tsvwg-rsvp-proxy-approaches] and is used extensively in the 223 present document: 225 o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per 226 [RFC2205] 228 o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf 229 of a receiver, the RSVP operations which would normally be 230 performed by an RSVP-capable receiver if end-to-end RSVP signaling 231 was used. Note that while RSVP is used upstream of the RSVP 232 Receiver Proxy, RSVP is not used downstream of the RSVP Receiver 233 Proxy. 235 o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of 236 a sender, the RSVP operations that normally would be performed by 237 an RSVP-capable sender if end-to-end RSVP signaling was used. 238 Note that while RSVP is used downstream of the RSVP Sender Proxy, 239 RSVP is not used upstream of the RSVP Sender Proxy. 241 o Regular RSVP Router: an RSVP-capable router which is not behaving 242 as a RSVP Receiver Proxy nor as a RSVP Sender Proxy. 244 Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, 245 Regular RSVP Router are all relative to one unidirectional flow. A 246 given router may act as the RSVP Receiver Proxy for a flow, as the 247 RSVP Sender Proxy for another flow and as a Regular RSVP router for 248 yet another flow. 250 The following terminology is also used in the present document: 252 o Regular RSVP Sender: an RSVP-capable host behaving as the sender 253 for the considered flow and participating in RSVP signaling in 254 accordance with the sender behavior specified in [RFC2205]. 256 o Regular RSVP Receiver: an RSVP-capable host behaving as the 257 receiver for the considered flow and participating in RSVP 258 signaling in accordance with the receiver behavior specified in 259 [RFC2205]. 261 3. RSVP Extensions for Sender Notification 263 This section defines extensions to RSVP procedures allowing sender 264 notification of reservation failure. This facilitates 265 synchronization by the sender between RSVP reservation and 266 application requirements in scenarios involving a Path-Triggered RSVP 267 Receiver Proxy. 269 As discussed in [I-D.ietf-tsvwg-rsvp-proxy-approaches], with the 270 Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be 271 configured to use receipt of a regular RSVP Path message as the 272 trigger for RSVP Receiver Proxy behavior. On receipt of the RSVP 273 Path message, the RSVP Receiver Proxy: 275 1. establishes the RSVP Path state as per regular RSVP processing 277 2. identifies the downstream interface towards the receiver 279 3. sinks the Path message 281 4. behaves as if a corresponding Resv message (on its way upstream 282 from the receiver) was received on the downstream interface. 283 This includes performing admission control on the downstream 284 interface, establishing a Resv state (in case of successful 285 admission control) and forwarding the Resv message upstream, 286 sending periodic refreshes of the Resv message and tearing down 287 the reservation if the Path state is torn down. 289 Operation of the Path-Triggered Receiver Proxy in the case of a 290 successful reservation is illustrated in Figure 1. 292 |----| *** *** *** |----------| |----| 293 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 294 |----| *** *** *** | Receiver | |----| 295 | Proxy | 296 |----------| 298 --Path---> --Path---> --Path---> --Path---> 300 <---Resv-- <---Resv-- <---Resv-- <---Resv-- 302 ===================RSVP===================> 304 ************************************************************> 306 |----| RSVP-capable |----| Non-RSVP-capable *** 307 | S | Sender | R | Receiver *r* regular RSVP 308 |----| |----| *** router 310 ***> media flow 312 ==> segment of flow path protected by RSVP reservation 314 Figure 1: Successful Reservation 316 We observe that, in the case of successful reservation, conventional 317 RSVP procedures ensure that the sender is notified of the successful 318 reservation establishment. Thus, no extensions are required in the 319 presence of a Path-Triggered RSVP Receiver Proxy in the case of 320 successful reservation establishment. 322 However, in case of reservation failure, conventional RSVP procedures 323 ensure only that the receiver (or the RSVP Receiver Proxy) is 324 notified of the reservation failure. Specifically, in case of an 325 admission control rejection on a regular RSVP router, a ResvErr 326 message is sent downstream towards the receiver. In the presence of 327 an RSVP Receiver Proxy, if we simply follow conventional RSVP 328 procedures, this means that the RSVP Receiver Proxy is notified of 329 the reservation failure, but the sender is not. Operation of the 330 Path-Triggered RSVP Receiver Proxy in the case of an admission 331 control failure, assuming conventional RSVP procedures, is 332 illustrated in Figure 2. 334 |----| *** *** *** |----------| |----| 335 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 336 |----| *** *** *** | Receiver | |----| 337 | Proxy | 338 |----------| 340 --Path---> --Path---> --Path---> --Path---> 342 <---Resv-- <---Resv-- 344 -ResvErr-> -ResvErr-> 346 ===================RSVP===================> 348 ************************************************************> 350 |----| |----| *** 351 | S | Sender | R | Receiver *r* regular RSVP 352 |----| |----| *** router 354 ***> media flow 356 ==> segment of flow path protected by RSVP reservation 358 Figure 2: Reservation Failure With Conventional RSVP 360 While the sender could infer reservation failure from the fact that 361 it has not received a Resv message after a certain time, there are 362 clear benefits in ensuring that the sender gets a prompt, explicit 363 notification in case of reservation failure. This includes faster 364 end-user notification at application layer (e.g., busy signal), 365 faster application level reaction (e.g., application level 366 rerouting), as well as faster release of application-level resources. 368 Section 3.1 defines a method that can be used to achieve sender 369 notification of reservation failure. A router implementation 370 claiming compliance with this document MUST support the method 371 defined in Section 3.1. 373 Section 3.2 defines another method that can be used to achieve sender 374 notification of reservation failure. A router implementation 375 claiming compliance with this document MAY support the method defined 376 in Section 3.2. 378 In a given network environment, a network administrator may elect to 379 use the method defined in Section 3.1, or the method defined in 380 Section 3.2, or possibly combine the two. 382 3.1. Sender Notification via PathErr Message 384 With this method, the RSVP Receiver Proxy MUST generate a PathErr 385 message whenever the two following conditions are met: 387 1. The reservation establishment has failed (or the previously 388 established reservation has been torn down) 390 2. The RSVP Receiver Proxy determines that it cannot re-establish 391 the reservation (e.g., by adapting its reservation request in 392 reaction to the error code provided in the received ResvErr in 393 accordance with local policy) 395 Note that this notion of generating a PathErr message upstream in 396 order to notify the sender about a reservation failure is not 397 completely new. It is borrowed from [RFC3209] where it has been 398 introduced in order to achieve a similar requirement, which is to 399 allow an MPLS TE Label Switch Router to notify the TE Tunnel Head-end 400 (i.e., the sender) of a failure to establish (or maintain) a TE 401 Tunnel Label Switch Path. 403 Operation of the Path-Triggered RSVP Receiver Proxy in the case of an 404 admission control failure, using sender notification via PathErr 405 Message, is illustrated in Figure 3. 407 |----| *** *** *** |----------| |----| 408 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 409 |----| *** *** *** | Receiver | |----| 410 | Proxy | 411 |----------| 413 --Path---> --Path---> --Path---> --Path---> 415 <---Resv-- <---Resv-- 417 -ResvErr-> -ResvErr-> 419 <-PathErr- <-PathErr- <-PathErr- <-PathErr- 421 ===================RSVP===================> 423 ************************************************************> 425 |----| |----| *** 426 | S | Sender | R | Receiver *r* regular RSVP 427 |----| |----| *** router 429 ***> media flow 431 ==> segment of flow path to be protected by RSVP reservation 432 (but not protected in this case since reservation failed) 434 Figure 3: Reservation Failure With Sender Notification via PathErr 436 The role of this PathErr is to notify the sender that the reservation 437 was not established or was torn down. This may be in the case of 438 receipt of a ResvErr, or because of local failure on the Receiver 439 Proxy. On receipt of a ResvErr, in all situations where the 440 reservation cannot be installed, the Receiver Proxy MUST generate a 441 PathErr towards the sender. For local failures on the Receiver Proxy 442 node, if a similar failure on an RSVP midpoint would cause the 443 generation of a ResvErr (for example, admission control failure), the 444 Receiver Proxy MUST generate a PathErr towards the sender. The 445 Receiver Proxy MAY additionally generate a PathErr upon local 446 failures which would not ordinarily cause generation of a ResvErr 447 message, such as described in Appendix B of [RFC2205]. 449 The PathErr generated by the Receiver Proxy corresponds to the 450 sender(s) that triggered generation of Resv messages that failed. 451 For Fixed-Filter (FF) style reservations, the Receiver Proxy MUST 452 send a PathErr towards the (single) sender matching the failed 453 reservation. For Shared-Explicit (SE) style reservations, the 454 Receiver Proxy MUST send the PathErr(s) towards the set of senders 455 that triggered reservations that failed. This may be a subset of 456 senders sharing the same reservation, in which case the remaining 457 senders would have their reservation intact and would not receive a 458 PathErr. In both cases, the rules described in Section 3.1.8 of 459 [RFC2205] for generating flow descriptors in ResvErr messages, also 460 apply when generating sender descriptors in PathErr messages. 462 For Wildcard-Filter (WF) style reservations, it is not always 463 possible for the Receiver Proxy to reliably know which sender caused 464 the reservation failure. Therefore, the Receiver Proxy SHOULD send a 465 PathErr towards each sender. This means that all the senders will 466 receive a notification that the reservation is not established, 467 including senders that did not cause the reservation failure. 468 Therefore, the method of sender notification via PathErr message is 469 somewhat over-conservative (i.e., in some cases rejecting 470 reservations from some senders when those could have actually been 471 established) when used in combination with Wildcard-Filter style (and 472 when there is more than one sender). 474 The sender notification via PathErr method applies to both unicast 475 and multicast sessions. However, for a multicast session, it is 476 possible that reservation failure (e.g., admission control failure) 477 in a node close to a sender may cause ResvErr messages to be sent to 478 a large group of Receiver Proxies. These Receiver Proxies would, in 479 turn, all send PathErr messages back to the same sender, which could 480 cause a scalability issue in some environments. 482 From the perspective of the sender, errors that prevent a reservation 483 from being set up can be classified in two ways: 485 1. Errors that the sender can attempt to correct. The error code 486 for those errors should explicitly be communicated back to the 487 sender. An examples of this is "Class 1: Admission Control 488 Failure", because the sender could potentially resend a Path with 489 smaller traffic parameters. 491 2. Errors over which the sender has no control. For these errors, 492 it is sufficient to notify the sender that the reservation was 493 not set up successfully. An example of this is "Class 13: 494 Unknown Object", because the sender has no control over the 495 objects inserted into the reservation by the Receiver Proxy. 497 The PathErr message generated by the Receiver Proxy has the same 498 format as regular PathErr messages defined in [RFC2205]. The 499 SESSION, ERROR_SPEC and sender descriptor are composed by the 500 Receiver Proxy as specified in the following subsections. The 501 Receiver Proxy MAY reflect back towards the sender in the PathErr any 502 POLICY_DATA objects received in the ResvErr. 504 3.1.1. Composition of SESSION and Sender Descriptor 506 The Receiver Proxy MUST insert the SESSION object corresponding to 507 the failed reservation, into the PathErr. For Fixed-Filter (FF) 508 style reservations, the Receiver Proxy MUST insert a sender 509 descriptor corresponding to the failed reservation, into the PathErr. 510 This is equal to the error flow descriptor in the ResvErr received by 511 the Receiver Proxy. For Shared-Explicit (SE) style reservations, the 512 Receiver Proxy MUST insert a sender descriptor corresponding to the 513 sender triggering the failed reservation, into the PathErr. This is 514 equal to the error flow descriptor in the ResvErr received by the 515 Receiver Proxy. If multiple flow descriptors could not be admitted 516 at a midpoint node, that node would generate multiple ResvErr 517 messages towards the receiver as per Section 3.1.8 of [RFC2205]. 518 Each ResvErr would contain an error flow descriptor that matches a 519 specific sender. The Receiver Proxy MUST generate a PathErr for each 520 ResvErr received, towards the corresponding sender. As specified 521 earlier, for Wildcard-Filter style reservations, the Receiver Proxy 522 SHOULD send a PathErr to each sender. 524 3.1.2. Composition of ERROR_SPEC 526 The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into 527 the PathErr as follows: 529 1. If the Receiver Proxy receives a ResvErr with any of these error 530 codes: "Code 1 - Admission Control Failure" or "Code 2 - Policy 531 Control Failure" then the Receiver Proxy copies the error code 532 and value from the ERROR_SPEC in the ResvErr, into the ERROR_SPEC 533 of the PathErr message. The error node in the PathErr MUST be 534 set to the address of the Receiver Proxy. This procedure MUST 535 also be followed for a local error on the Receiver Proxy that 536 would ordinarily cause a midpoint to generate a ResvErr with one 537 of the above codes. 539 2. If the Receiver Proxy receives a ResvErr with any error code 540 other than the ones listed in 1 above, it composes a new 541 ERROR_SPEC with error code ": Unrecoverable Receiver Proxy Error". The error node in 543 the PathErr MUST be set to the address of the Receiver Proxy. 544 This procedure MUST also be followed for a local error on the 545 Receiver Proxy that would ordinarily cause a midpoint to generate 546 a ResvErr with any error code except than those listed in 1 547 above, or if the Receiver Proxy generates a PathErr for a local 548 error which ordinarily would not cause generation of a ResvErr. 550 In some cases it may be predetermined that the PathErr will not 551 reach the sender. For example, a node receiving a ResvErr with 552 "Code 3: No Path for Resv", knows a priori that the PathErr 553 message it generates cannot be forwarded by the same node which 554 could not process the Resv. Nevertheless, the procedures above 555 MUST be followed. For the error code ": Unrecoverable Receiver Proxy Error", the 557 16 bits of the Error Value field are: 559 * hhhh hhhh llll llll 561 where the bits are: 563 * hhhh hhhh = 0000 0000: then the low order 8 bits (llll llll) 564 MUST be set by Receiver Proxy to 0000 0000 and MUST be ignored 565 by the sender. 567 * hhhh hhhh = 0000 0001: then the low order 8 bits (llll llll) 568 MUST be set by the Receiver Proxy to the value of the error 569 code received in the ResvErr ERROR_SPEC (or, in case the 570 Receiver Proxy generated the PathErr without having received a 571 ResvErr, to the error code value that would have been included 572 by the Receiver Proxy in the ERROR_SPEC in similar conditions 573 if it was to generate a ResvErr). This error value MAY be 574 used by the sender to further interpret the reason of the 575 reservation failure. 577 * hhhh hhhh = any other value: reserved. 579 3. If the Receiver Proxy Receives a ResvErr with the InPlace flag 580 set in the ERROR_SPEC, it MUST also set the InPlace flag in the 581 ERROR_SPEC of the PathErr. 583 3.1.3. Use of Path_State_Removed Flag 585 [RFC3473] defines an optional behavior whereby a node forwarding a 586 PathErr message can remove the Path State associated with the PathErr 587 message and indicate so by including the Path_State_Removed flag in 588 the ERROR_SPEC object of the PathErr message. This can be used in 589 some situations to expedite release of resources and minimize 590 signaling load. 592 This section discusses aspects of the use of the Path_State_Removed 593 flag that are specific to the RSVP Receiver Proxy. In any other 594 aspects, the Path_State_Removed flag operates as per [RFC3473]. 596 By default, the RSVP Receiver Proxy MUST NOT include the 597 Path_State_Removed flag in the ERROR_SPEC of the PathErr message. 599 This ensures predictable operations in all environments including 600 those where some RSVP routers do not understand the 601 Path_State_Removed flag. 603 The RSVP Receiver Proxy MAY support an OPTIONAL mode (to be activated 604 by configuration) whereby the RSVP Receiver Proxy includes the 605 Path_State_Removed flag in the ERROR_SPEC of the PathErr message and 606 removes its local Path state. When all routers on the path of a 607 reservation support the Path_State_Removed flag, its use will indeed 608 result in expedited resource release and reduced signaling. However, 609 if there are one or more RSVP router on the path of the reservation 610 that do not support the Path_State_Removed flag (we refer to such 611 routers as "old RSVP routers"), the use of the Path_State_Removed 612 flag will actually result in slower resource release and increased 613 signaling. This is because the Path_State_Removed flag will be 614 propagated upstream by an old RSVP router (even if it does not 615 understand it and does not tear its Path state). Thus, the sender 616 will not send a Path Tear and the old RSVP router will release its 617 Path state only through refresh time-out. A network administrator 618 needs to keep these considerations in mind when deciding whether to 619 activate the use of the Path_State_Removed flag on the RSVP Receiver 620 Proxy. In a controlled environment where all routers are known to 621 support the Path_State_Removed flag, its use can be safely activated 622 on the RSVP Receiver Proxy. In other environments, the network 623 administrator needs to assess whether the improvement achieved with 624 some reservations outweighs the degradation experienced by other 625 reservations. 627 3.1.4. Use of PathErr by Regular Receivers 629 Note that while this document specifies that an RSVP Receiver Proxy 630 generates a PathErr upstream in case of reservation failure, this 631 document does NOT propose that the same be done by regular receivers. 632 In other words, this document does NOT propose to modify the behavior 633 of regular receivers as currently specified in [RFC2205]. The 634 rationale for this includes the following: 636 o When the receiver is RSVP capable, the current receiver-driven 637 model of [RFC2205] is fully applicable because the receiver can 638 synchronise RSVP reservation state and application state (since it 639 participates in both). The sender(s) needs not be aware of the 640 RSVP reservation state. Thus, we can retain the benefits of 641 receiver-driven operations which were explicitly sought by 642 [RFC2205]. Quoting from it: " In order to efficiently accommodate 643 large groups, dynamic group membership, and heterogeneous receiver 644 requirements, RSVP makes receivers responsible for requesting a 645 specific QoS". But even for the simplest single_sender/ 646 single_receiver reservations, the current receiver-driven model 647 reduces signaling load and per-hop RSVP processing by not sending 648 any error message to the sender in case of admission control 649 reject. 651 o The motivation for adding sender error notification in case of 652 receiver proxy lies in the fact that the actual receiver can no 653 longer synchronize the RSVP reservation with application state 654 (since the receiver does not participate in RSVP signaling), while 655 the sender can. This motivation does not apply in case of regular 656 receiver. 658 o There is a lot of existing code and deployed systems successfully 659 working under the current [RFC2205] model in the absence of proxy 660 today. The current behavior should not be changed for those 661 unless there were a very strong motivation. 663 3.2. Sender Notification via Notify Message 665 The OPTIONAL method for sender notification of reservation failure 666 defined in this section aims to provide a more efficient method than 667 the one defined in Section 3.1. Its objectives include: 669 o allow the failure notification to be sent directly upstream to the 670 sender by the router where the failure occurs (as opposed to first 671 travelling downstream towards the Receiver Proxy and then 672 travelling upstream from the Receiver Proxy to the sender, as 673 effectively happens with the method defined in Section 3.1) 675 o allow the failure notification to travel without hop-by-hop RSVP 676 processing 678 o ensure that such a notification is sent to senders that are 679 capable and willing to process it (i.e., to synchronize 680 reservation status with application) 682 o ensure that such a notification is only sent in case the receiver 683 is not itself capable and willing to do the synchronization with 684 the application (i.e., because we are in the presence of a 685 Receiver Proxy so that RSVP signaling is not visible to the 686 receiver). 688 Note, however, that such benefits come at the cost of: 690 o a requirement for RSVP routers and senders to support the Notify 691 messages and procedures defined in [RFC3473] 693 o a requirement for senders to process Notify messages traveling 694 upstream but conveying a downstream notification. 696 [RFC3473] defines (in section "4.3 Notify Messages") the Notify 697 message that provides a mechanism to inform non-adjacent nodes of 698 events related to the RSVP reservation. The Notify message differs 699 from the error messages defined in [RFC2205] (i.e., PathErr and 700 ResvErr messages) in that it can be "targeted" to a node other than 701 the immediate upstream or downstream neighbor and that it is a 702 generalized notification mechanism. Notify messages are normally 703 generated only after a Notify Request object has been received. 705 This section discusses aspects of the use of the Notify message that 706 are specific to the RSVP Receiver Proxy. In any other aspects, the 707 Notify message operates as per [RFC3473]. 709 In order to achieve sender notification of reservation failure in the 710 context of the present document: 712 o An RSVP sender interested in being notified of reservation failure 713 MUST include a Notify Request object (containing the sender's IP 714 address) in the Path messages it generates. 716 o Upon receiving a Path message with a Notify Request object, the 717 RSVP Receiver Proxy MUST include a Notify Request object in the 718 Resv messages it generates. This Notify Request object MUST 719 contain: 721 * either the address that was included in the Notify Request of 722 the received Path message- a.k.a. the sender's address-. We 723 refer to this approach as the "Direct Notify". 725 * or an address of the Receiver Proxy. We refer to this approach 726 as the "Indirect Notify". 728 o Upon receiving a downstream error notification (whether in the 729 form of a Notify or a ResvErr or both), the RSVP Receiver Proxy: 731 * MUST generate a Notify message with upstream notification to 732 the corresponding sender, if the sender included a Notify 733 Request object in its Path messages and if Indirect 734 Notification is used. 736 * SHOULD generate a Notify message with upstream notification to 737 the corresponding sender, if the sender included a Notify 738 Request object in its Path messages and if Direct Notification 739 is used. The reason for this recommendation is that the 740 failure node may not support Notify, so that even if Direct 741 Notification was requested by the RSVP Receiver Proxy, the 742 sender may not actually have received a Notify from the failure 743 node: generating a Notify from the Receiver Proxy will 744 accelerate sender notification, as compared to simply relying 745 on PathErr, in this situation. In controlled environments 746 where all the nodes are known to support Notify, the Receiver 747 Proxy MAY be configured to not generate the Notify with 748 upstream notification when Direct Notification is used, in 749 order to avoid duplication of Notify messages (i.e. the sender 750 receiving both a Notify from the failure node and from the 751 Receiver Proxy) 753 As a result of these sender and Receiver Proxy behaviors, as per 754 existing Notify procedures, if an RSVP router detects an error 755 relating to a Resv state (e.g., admission control rejection after IP 756 reroute), the RSVP router will send a Notify message (conveying the 757 downstream notification with the ResvErr error code) to the IP 758 address contained in the Resv Notify Request object. If this address 759 has been set by the RSVP Receiver Proxy to the sender's address 760 (Direct Notify), the Notify message is sent directly to the sender. 761 If this address has been set by the RSVP Receiver Proxy to one of its 762 address (Indirect Notify), the Notify message is sent to the RSVP 763 Receiver Proxy that, in turn, will generate a Notify message directly 764 addressed to the sender. 766 Operation of the Path-Triggered RSVP Receiver Proxy in the case of an 767 admission control failure, using sender notification via Direct 768 Notify, is illustrated in Figure 4. 770 |----| *** *** *** |----------| |----| 771 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 772 |----| *** *** *** | Receiver | |----| 773 | Proxy | 774 |----------| 776 --Path*--> --Path*--> --Path*--> --Path*--> 778 <--Resv*-- <--Resv*-- 780 <------NotifyD-------- 782 -ResvErr-> -ResvErr-> 784 <------------------NotifyU------------------ 786 <-PathErr- <-PathErr- <-PathErr- <-PathErr- 788 ===================RSVP===================> 790 ************************************************************> 792 |----| |----| *** 793 | S | Sender | R | Receiver *r* regular RSVP 794 |----| |----| *** router 796 ***> media flow 798 ==> segment of flow path to be protected by RSVP reservation 799 (but not protected in this case since reservation failed) 801 Path* = Path message containing a Notify Request object 802 with sender IP Address 804 Resv* = Resv message containing a Notify Request object 805 with sender IP address 807 NotifyD = Notify message containing a downstream notification 809 Figure 4: Reservation Failure With Sender Notification via Direct 810 Notify 812 Operation of the Path-Triggered RSVP Receiver Proxy in the case of an 813 admission control failure, using sender notification via Indirect 814 Notify, is illustrated in Figure 5. 816 |----| *** *** *** |----------| |----| 817 | S |--------*r*--------*r*--------*r*--------| RSVP |------| R | 818 |----| *** *** *** | Receiver | |----| 819 | Proxy | 820 |----------| 822 --Path*--> --Path*--> --Path*--> --Path*--> 824 <--Resv*-- <--Resv*-- 826 -------NotifyD-------> 828 <------------------NotifyU------------------ 830 -ResvErr-> -ResvErr-> 832 <-PathErr- <-PathErr- <-PathErr- <-PathErr- 834 ===================RSVP===================> 836 ************************************************************> 838 |----| |----| *** 839 | S | Sender | R | Receiver *r* regular RSVP 840 |----| |----| *** router 842 ***> media flow 844 ==> segment of flow path to be protected by RSVP reservation 845 (but not protected in this case since reservation failed) 847 Path* = Path message containing a Notify Request object 848 with sender IP Address 850 Resv* = Resv message containing a Notify Request object 851 with RSVP Receiver Proxy IP address 853 NotifyD = Notify message containing a downstream notification 855 NotifyU = Notify message containing an upstream notification 857 Figure 5: Reservation Failure With Sender Notification via Indirect 858 Notify 860 For local failures on the Receiver Proxy node, if a similar failure 861 on an RSVP midpoint would cause the generation of a ResvErr (for 862 example, admission control failure), the Receiver Proxy MUST generate 863 a Notify towards the sender. The Receiver Proxy MAY additionally 864 generate a Notify upon local failures that would not ordinarily cause 865 generation of a ResvErr message, such as described in Appendix B of 866 [RFC2205]. 868 When the method of sender notification via Notify message is used, it 869 is RECOMMENDED that the RSVP Receiver Proxy also issue a sender 870 notification via a PathErr message. This maximizes the chances that 871 the notification will reach the sender in all situations (e.g., even 872 if some RSVP routers do not support the Notify procedure, or if a 873 Notify message gets dropped). However, for controlled environments 874 (e.g., where all RSVP routers are known to support Notify procedures) 875 and where it is desirable to minimize the volume of signaling, the 876 RSVP Receiver Proxy MAY rely exclusively on sender notification via 877 Notify message and thus not issue sender notification via PathErr 878 message. 880 In environments where there are both RSVP-capable receivers and RSVP 881 Receiver Proxies acting on behalf of non RSVP-capable receivers, a 882 sender does not know whether a given reservation is established with 883 an RSVP-capable receiver or with an RSVP Receiver Proxy. Thus, a 884 sender that supports the procedures defined in this section may 885 include a Notify Request object in Path messages for a reservation 886 that happens to be controlled by an RSVP-capable receiver. This 887 document does not define, nor expect, any change in existing receiver 888 behavior. As a result, in this case, the sender will not receive 889 Notify messages conveying downstream notifications. However, this is 890 perfectly fine because the synchronization between the RSVP 891 reservation state and the application requirement can be performed by 892 the actual receiver in this case as per the regular end-to-end RSVP 893 model, so that in this case, the sender need not care about 894 downstream notifications. 896 A sender that does not support the procedures defined in this section 897 might include a Notify Request object in Path messages for a 898 reservation simply because it is interested in getting upstream 899 notifications faster. If the reservation is controlled by an RSVP 900 Receiver Proxy supporting the procedures defined in this section, the 901 sender will also receive unexpected Notify messages containing 902 downstream notifications. It is expected that such a sender will 903 simply naturally drop such downstream notifications as invalid. 904 Because it is RECOMMENDED above that the RSVP Receiver Proxy also 905 issues sender notification via a PathErr message even when sender 906 notification is effected via a Notify message, the sender will still 907 be notified of a reservation failure in accordance with the "sender 908 notification via PathErr" method. In summary, activating the 909 OPTIONAL "sender notification via Notify" method on a Receiver Proxy, 910 does not prevent a sender that does not support this method, to rely 911 on the MANDATORY "sender notification via PathErr" method. It would, 912 however, allow a sender supporting the "sender notification via 913 Notify" method to take advantage of this OPTIONAL method. 915 With Direct Notification, the downstream notification generated by 916 the RSVP router where the failure occurs is sent to the IP address 917 contained in the Notification Request Object of the corresponding 918 Resv message. In the presence of multiple senders towards the same 919 session, it cannot be generally assumed that a separate Resv message 920 is used for each sender (in fact with WF and SE there is a single 921 Resv message for all senders, and with FF the downstream router has 922 the choice of generating separate Resv messages or a single one). 923 Hence, in the presence of multiple senders, Direct Notification 924 cannot guarantee notification of all affected senders. Therefore, 925 Direct Notification is better suited to single sender applications. 927 With Indirect Notification, the RSVP Receiver Proxy can generate 928 Notify messages with the same logic that is used to generate PathErr 929 messages in the "Sender Notification via PathErr" method (in fact 930 those are conveying the same error information, only the Notify is 931 directly addressed to the sender while the PathErr travels hop-by- 932 hop). Therefore, operations of Indirect Notify method in the 933 presence of multiple senders is similar to that of the PathErr method 934 as discussed in Section 3.1: with FF (respectively, SE) a Notify MUST 935 be sent to the sender (respectively, the set of affected senders). 936 With WF, the RSVP Receiver Proxy SHOULD send a Notify to each sender, 937 again resulting in a somewhat over-conservative behavior in the 938 presence of multiple senders. 940 4. Security Considerations 942 To ensure the integrity and authenticity of the associated 943 reservation and admission control mechanisms, the RSVP Authentication 944 mechanisms defined in [RFC2747] and [RFC3097] can be used. Those 945 protect RSVP message integrity hop-by-hop and provide node 946 authentication as well as replay protection, thereby protecting 947 against corruption and spoofing of RSVP messages. These hop-by-hop 948 integrity mechanisms can be used to protect RSVP reservations 949 established using an RSVP receiver proxy in accordance with the 950 present document. 952 [RFC2747] discusses several approaches to key distribution. First, 953 the RSVP Authentication shared keys can be distributed manually. 954 This is the base option and its support is mandated for every 955 implementation. However, in some environments, this approach may 956 become a burden if keys change frequently over time. Alternatively, 957 a standard key management protocol for secure key distribution can be 958 used. 960 The use of RSVP Authentication in parts of the network where there 961 may be one or more IP hops in between two RSVP neighbors raises an 962 additional challenge. This is because, with some RSVP messages such 963 as a Path message, an RSVP router does not know the RSVP next hop for 964 that message at the time of forwarding it. In fact, part of the role 965 of a Path message is precisely to discover the RSVP next hop (and to 966 dynamically re-discover it when it changes, say because of a routing 967 change). Hence, the RSVP router may not know which security 968 association to use when forwarding such a message (see [RFC2747] for 969 definition of RSVP security association). In that situation, one 970 approach is to share the same RSVP Authentication key across all the 971 RSVP routers in a part of the network where there may be RSVP 972 neighbors with IP hops in between. For example, all the RSVP routers 973 of an administrative domain (including the receiver proxies) could 974 share the same RSVP Authentication key, while different per-neighbor 975 keys could be used between any RSVP router pair straddling the 976 boundary between two administrative domains that have agreed to use 977 RSVP signaling. 979 When the same RSVP Authentication key is to be shared among multiple 980 RSVP neighbors, manual key distribution may be used. 981 [I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses 982 applicability of dynamic group key distribution method for dynamic 983 update of such shared keys among RSVP routers. 985 The RSVP Authentication mechanisms do not provide confidentiality. 986 If confidentiality is required, IPsec ESP ([RFC4303]) may be used, 987 although it imposes the burden of key distribution. It also faces 988 the additional issue discussed for key management above in the case 989 where there can be IP hops in between RSVP hops. 990 [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of 991 various keying methods for applying IPsec encryption and 992 authentication to RSVP, including use of group keys and dynamic group 993 key distribution. 995 When an RSVP receiver proxy is used, the RSVP reservation is no 996 longer controlled by the receiver, but rather is controlled by the 997 receiver proxy (using hints received from the sender in the Path 998 message) on behalf of the sender. Thus, the receiver proxy ought to 999 be trusted by the end-systems to control the RSVP reservation 1000 appropriately. However, basic RSVP operation already assumes a trust 1001 model where end-systems trust RSVP nodes to appropriately perform 1002 RSVP reservations. So the use of RSVP receiver proxy is not seen as 1003 introducing any significant additional security threat or as 1004 modifying the RSVP trust model. 1006 In fact, there are situations where the use of RSVP receiver proxy 1007 reduces the security risks. One example is where a network operator 1008 relies on RSVP to perform resource reservation and admission control 1009 within a network and where RSVP senders and RSVP routers are located 1010 in the operator premises while the many RSVP receivers are located in 1011 the operator's customers premises. Such an environment is further 1012 illustrated in "Annex A.1. RSVP-based VoD Admission Control in 1013 Broadband Aggregation Networks" of 1014 [I-D.ietf-tsvwg-rsvp-proxy-approaches]. From the operator's 1015 perspective, the RSVP routers and RSVP senders are in physically 1016 secured locations and therefore exposed to a lower risk of being 1017 tampered with; While the receivers are in locations that are 1018 physically unsecured and therefore subject to a higher risk of being 1019 tampered with. The use of an RSVP receiver proxy function 1020 effectively increases the security of the operator's reservation and 1021 admission control solution by completely excluding receivers from its 1022 operation. Filters can be placed at the edge of the operator network 1023 discarding any RSVP message received from end-users. This provides a 1024 very simple and effective protection of the RSVP reservation and 1025 admission control solution operating inside the operator's network. 1027 This document defines in Section 3.2 an optional method relying on 1028 the use of the Notify message specified in [RFC3473]. The Notify 1029 message can be sent in a non-hop-by-hop fashion that precludes use of 1030 RSVP hop-by-hop integrity and authentication model. The approaches 1031 and considerations for addressing this issue presented in the 1032 Security Considerations section of [RFC3473] apply. In particular, 1033 where the Notify messages are transmitted non-hop-by-hop and the same 1034 level of security provided by [RFC2747] is desired, IPsec-based 1035 integrity and authentication can be used ([RFC4302] or [RFC4303]). 1037 Alternatively, the sending of non-hop-by-hop Notify messages can be 1038 disabled. Finally, [I-D.ietf-tsvwg-rsvp-security-groupkeying] 1039 discusses applicability of group keying for non-hop-by-hop Notify 1040 messages. 1042 5. IANA Considerations 1044 Since, as discussed in Section 3.1.2, this document allows two Error 1045 Codes to be used in PathErr messages while [RFC2205] only specified 1046 their use in ResvErr messages, this document requires that IANA 1047 updates the existing entries for these two Error Codes under the 1048 "Error Codes and Globally-Defined Error Value Sub-Codes" registry. 1049 Each entry should refer to this document, in addition to referring to 1050 [RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2 1051 should respectively read: 1053 " 1055 1 Admission Control Failure [RFC2205] [RFCXXX] 1057 ... 1059 2 Policy Control Failure [RFC2205] [RFCXXX] 1061 ... 1063 " 1065 where [RFCXXX] refers to this document. 1067 This document also requires that IANA allocates a new RSVP Error Code 1068 ": Unrecoverable Receiver Proxy Error", as discussed in 1069 Section 3.1.2. This Error Code is to be allocated under the "Error 1070 Codes and Globally-Defined Error Value Sub-Codes" registry. The 1071 entry for this error code should read: 1073 " 1075 TBD Unrecoverable Receiver Proxy Error [RFCXXX] 1077 The sixteen bits of the Error Value field are defined in [RFCXXX] 1079 " 1081 where [RFCXXX] refers to this document and TBD is the value to be 1082 allocated by IANA. 1084 6. Acknowledgments 1086 This document benefited from discussions with Carol Iturralde and 1087 Anca Zamfir. Lou Berger, Adrian Farrel and John Drake provided 1088 review and guidance, in particular on the usage of the 1089 Path_State_Removed flag and of the Notify message, both borrowed from 1090 [RFC3473]. We also thank Ken Carlberg for his valuable input. 1092 7. References 1094 7.1. Normative References 1096 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1097 Requirement Levels", BCP 14, RFC 2119, March 1997. 1099 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1100 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1101 Functional Specification", RFC 2205, September 1997. 1103 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1104 Authentication", RFC 2747, January 2000. 1106 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 1107 Authentication -- Updated Message Type Value", RFC 3097, 1108 April 2001. 1110 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1111 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1112 Tunnels", RFC 3209, December 2001. 1114 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1115 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1116 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1118 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1119 December 2005. 1121 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1122 RFC 4303, December 2005. 1124 7.2. Informative References 1126 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 1127 Faucheur, F., Manner, J., Wing, D., and A. Guillou, "RSVP 1128 Proxy Approaches", 1129 draft-ietf-tsvwg-rsvp-proxy-approaches-06 (work in 1130 progress), October 2008. 1132 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 1133 Behringer, M. and F. Faucheur, "Applicability of Keying 1134 Methods for RSVP Security", 1135 draft-ietf-tsvwg-rsvp-security-groupkeying-02 (work in 1136 progress), November 2008. 1138 Authors' Addresses 1140 Francois Le Faucheur 1141 Cisco Systems 1142 Greenside, 400 Avenue de Roumanille 1143 Sophia Antipolis 06410 1144 France 1146 Phone: +33 4 97 23 26 19 1147 Email: flefauch@cisco.com 1149 Jukka Manner 1150 University of Helsinki 1151 P.O. Box 68 1152 University of Helsinki FIN-00014 University of Helsinki 1153 Finland 1155 Phone: +358 9 191 51298 1156 Email: jmanner@cs.helsinki.fi 1157 URI: http://www.cs.helsinki.fi/u/jmanner/ 1159 Ashok Narayanan 1160 Cisco Systems 1161 300 Beaver Brook Road 1162 Boxborough, MAS 01719 1163 United States 1165 Email: ashokn@cisco.com 1167 Allan Guillou 1168 Neuf Cegetel 1169 40-42 Quai du Point du Jour 1170 Boulogne-Billancourt, 92659 1171 France 1173 Email: allan.guillou@sfr.com 1174 Hemant Malik 1175 Bharti Airtel Ltd. 1176 4th Floor, Tower A, Unitech Cyber Park 1177 Gurgaon, Sector 39, 122001 1178 India 1180 Email: Hemant.Malik@airtel.in