idnits 2.17.1 draft-ietf-tsvwg-rsvp-proxy-approaches-02.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1751. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1762. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1775. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 12, 2007) is 6072 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3525' is defined on line 1221, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-09 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-17 -- No information found for draft-manner-tsvwg-rsvp-proxy-sig - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3525 (Obsoleted by RFC 5125) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG F. Le Faucheur 3 Internet-Draft Cisco 4 Intended status: Informational J. Manner 5 Expires: March 15, 2008 University of Helsinki 6 D. Wing 7 Cisco 8 A. Guillou 9 Neuf 10 September 12, 2007 12 RSVP Proxy Approaches 13 draft-ietf-tsvwg-rsvp-proxy-approaches-02.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 15, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 RSVP signaling can be used to make end-to-end resource reservations 47 in an IP network in order to guarantee the Quality of Service 48 required by certain flows. With conventional RSVP, both the data 49 sender and receiver of a given flow take part in RSVP signaling. 50 Yet, there are many use cases where resource reservation is required, 51 but the receiver, the sender, or both, is not RSVP-capable. This 52 document presents RSVP Proxy behaviors allowing RSVP routers to 53 perform RSVP signaling on behalf of a receiver or a sender that is 54 not RSVP-capable. This allows resource reservations to be 55 established on critical parts of the end-to-end path. This document 56 reviews conceptual approaches for deploying RSVP Proxies and 57 discusses how RSVP reservations can be synchronized with application 58 requirements, despite the sender, receiver, or both not participating 59 in RSVP. This document also points out where extensions to RSVP (or 60 to other protocols) may be needed for deployment of a given RSVP 61 Proxy approach. However, such extensions are outside the scope of 62 this document. Finally, practical use cases for RSVP Proxy are 63 described. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 5 70 2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 6 71 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4. RSVP Proxy Approaches . . . . . . . . . . . . . . . . . . . . 8 73 4.1. Path-Triggered Receiver Proxy . . . . . . . . . . . . . . 8 74 4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 10 75 4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 13 76 4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 15 77 4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 17 78 4.5.1. Application_Entity-Controlled Sender Proxy using 79 "RSVP over GRE" . . . . . . . . . . . . . . . . . . . 19 80 4.5.2. Application_Entity-Controlled Proxy via Co-Location . 21 81 4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 22 82 4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 25 83 4.8. Endsystem-Controlled Proxy . . . . . . . . . . . . . . . . 26 84 4.9. Reachability Considerations . . . . . . . . . . . . . . . 26 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 87 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 88 8. Informative References . . . . . . . . . . . . . . . . . . . . 28 89 Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 30 90 A.1. RSVP-based VoD CAC in Broadband Aggregation Networks . . . 30 91 A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 34 92 A.3. RSVP-based Voice CAC in Telephony Service Provider Core . 35 93 A.4. RSVP Proxies for Mobile Access Networks . . . . . . . . . 37 94 A.5. RSVP Proxies for Reservations in the presence of IPsec 95 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 39 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 98 Intellectual Property and Copyright Statements . . . . . . . . . . 44 100 1. Introduction 102 Guaranteed Quality of Service (QoS) for some applications with tight 103 requirements (such as voice or video) may be achieved by reserving 104 resources in each node on the end-to-end path. The main IETF 105 protocol for these resource reservations is RSVP, specified in 106 [RFC2205]. RSVP does not require that all intermediate nodes support 107 RSVP, however it assumes that both the sender and the receiver of the 108 data flow support RSVP. There are environments where it would be 109 useful to be able to reserve resources for a flow on at least a 110 subset of the flow path even when the sender or the receiver (or 111 both) is not RSVP capable. 113 Since the data sender or receiver may be unaware of RSVP, there are 114 two scenarios. In the first case, an entity in the network must 115 operate on behalf of the data sender, and in particular, generate 116 RSVP Path messages, and eventually receive, process and sink Resv 117 messages. We refer to this entity as the RSVP Sender Proxy. In the 118 latter case, an entity in the network must receive Path messages sent 119 by a data sender (or by an RSVP Sender Proxy), sink those, and return 120 Resv messages on behalf of the data receiver(s). We refer to this 121 entity as the RSVP Receiver Proxy. 123 The flow sender and receiver generally have at least some (if not 124 full) awareness of the application producing or consuming that flow. 125 Hence, the sender and receiver are in a natural position to 126 synchronize the establishment, maintenance and tear down of the RSVP 127 reservation with the application requirements. Similarly they are in 128 a natural position to determine the characteristics of the 129 reservation (bandwidth, QoS service,...) which best match the 130 application requirements. For example, before completing the 131 establishment of a multimedia session, the endpoints may decide to 132 establish RSVP reservations for the corresponding flows. Similarly, 133 when the multimedia session is torn down, the endpoints may decide to 134 tear down the corresponding RSVP reservations. For instance, 135 [RFC3312] discusses how RSVP reservations can be very tightly 136 synchronized by SIP endpoints with SIP session control and SIP 137 signaling. 139 When RSVP reservation establishment, maintenance and tearing down is 140 to be handled by RSVP Proxies on behalf of an RSVP sender or 141 receiver, a key challenge for the RSVP Proxy is to determine when the 142 RSVP reservations need to be established, maintained and torn down 143 and to determine what are the characteristics (bandwidth, QoS 144 Service,...) of the required RSVP reservations matching the 145 application requirements. We refer to this problem as the 146 synchronization of RSVP reservations with application level 147 requirements. 149 The IETF Next Steps in Signaling (NSIS) working group is designing, 150 as one their charter items, a new QoS signaling protocol. This 151 scheme already includes the notion of proxy operation, and 152 terminating QoS signaling on nodes that are not the actual data 153 senders or receivers. This is the same concept as the proxy 154 operation for RSVP discussed in this document. One difference though 155 is that the NSIS framework does not consider multicast resource 156 reservations, which RSVP provides today. 158 The next section introduces the notion of RSVP Sender Proxy and RSVP 159 Receiver Proxy. The following section defines useful terminology. 160 The subsequent section then presents several fundamental RSVP Proxy 161 approaches insisting on how they achieve the necessary 162 synchronization of RSVP reservations with application level 163 requirements. Appendix A includes more detailed use cases for the 164 proxies in various real life deployment environments. 166 2. RSVP Proxy Behaviors 168 This section discusses the two types of proxies; the RSVP Sender 169 Proxy operating on behalf of data senders, and the RSVP Receiver 170 Proxy operating for data receivers. The concepts presented in this 171 document are not meant to replace the standard RSVP and end-to-end 172 RSVP reservations are still expected to be used whenever possible. 173 However, RSVP Proxies are intended to facilitate RSVP deployment 174 where end-to-end RSVP signaling is not possible. 176 2.1. RSVP Receiver Proxy 178 With conventional RSVP operations, RSVP reservations are controlled 179 by receivers of data. After a data sender has sent an RSVP Path 180 message towards the intended recipient(s), each recipient that 181 requires a reservation generates a Resv message. If, however, a data 182 receiver is not running the RSVP protocol, the last hop RSVP router 183 will still send the Path message to the data receiver, which will 184 silently drop this message as an IP packet with an unknown protocol 185 number. 187 In order for reservations to be made in such a scenario, one of the 188 RSVP routers on the data path must somehow know that the data 189 receiver will not be participating in the resource reservation 190 signaling. This RSVP router should, thus, perform RSVP Receiver 191 Proxy functionality on behalf of the data receiver. This is 192 illustrated in Figure 1. Various mechanisms by which the RSVP proxy 193 router can gain the required information are discussed later in the 194 document. 196 |----| *** *** |----------| |----| 197 | S |---------*r*----------*r*---------| RSVP |----------| R | 198 |----| *** *** | Receiver | |----| 199 | Proxy | 200 |----------| 202 ===================RSVP==============> 204 ***********************************************************> 206 |----| RSVP-capable |----| non-RSVP-capable *** 207 | S | Sender | R | Receiver *r* regular RSVP 208 |----| |----| *** router 210 ***> unidirectional media flow 212 ==> segment of flow path protected by RSVP reservation 214 Figure 1: RSVP Receiver Proxy 216 2.2. RSVP Sender Proxy 218 With conventional RSVP operations, if a data sender is not running 219 the RSVP protocol, a resource reservation can not be set up; a data 220 receiver can not alone reserve resources without Path messages first 221 being received. Thus, even if the data receiver is running RSVP, it 222 still needs some node on the data path to send a Path message towards 223 the data receiver. 225 In that case, an RSVP node on the data path must somehow know that it 226 should generate Path messages to allow the receiver to set up the 227 resource reservation. This node is referred to as the RSVP Sender 228 Proxy and is illustrated in Figure 2. This case is more complex than 229 the Receiver Proxy case, since the RSVP Sender Proxy must be able to 230 generate all the information in the Path message (such as the Sender 231 TSpec) without the benefit of having previously received any RSVP 232 message. An RSVP Receiver Proxy, by contrast only needs to formulate 233 an appropriate Resv message in response to an incoming Path message. 234 Mechanisms to operate an RSVP Sender Proxy are discussed later in 235 this document. 237 |----| |----------| *** *** |----| 238 | S |---------| RSVP |---------*r*----------*r*----------| R | 239 |----| | Sender | *** *** |----| 240 | Proxy | 241 |----------| 243 ================RSVP==================> 245 ***********************************************************> 247 |----| non-RSVP-capable |----| RSVP-capable *** 248 | S | Sender | R | Receiver *r* regular RSVP 249 |----| |----| *** router 251 ***> unidirectional media flow 253 ==> segment of flow path protected by RSVP reservation 255 Figure 2: RSVP Sender Proxy 257 3. Terminology 259 On-Path: located on the datapath of the actual flow of application 260 data (regardless of where it is located with respect to the 261 application level signaling path). 263 Off-Path: not On-Path. 265 RSVP-capable (or RSVP-aware): which supports the RSVP protocol as per 266 [RFC2205]. 268 RSVP Receiver Proxy: an RSVP capable router performing, on behalf of 269 a receiver, the RSVP operations which would normally be performed by 270 an RSVP-capable receiver if end-to-end RSVP signaling was used. Note 271 that while RSVP is used upstream of the RSVP Receiver Proxy, RSVP is 272 not used downstream of the RSVP Receiver Proxy. 274 RSVP Sender Proxy: an RSVP capable router performing, on behalf of a 275 sender, the RSVP operations which would normally be performed by an 276 RSVP-capable sender if end-to-end RSVP signaling was used. Note that 277 while RSVP is used downstream of the RSVP Sender Proxy, RSVP is not 278 used upstream of the RSVP Sender Proxy. 280 Regular RSVP Router: an RSVP-capable router which is not behaving as 281 a RSVP Receiver Proxy nor as a RSVP Sender Proxy. 283 Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, 284 Regular RSVP Router are all relative to one unidirectional flow. A 285 given router may act as the RSVP Receiver Proxy for a flow, as the 286 RSVP Sender Proxy for another flow and as a Regular RSVP router for 287 yet another flow. 289 Application level signaling: signaling between entities operating 290 above the IP layer and which are aware of the QoS requirements for 291 actual media flows. SIP and RTSP are examples of application level 292 signaling protocol. RSVP is clearly not an application level 293 signaling. 295 4. RSVP Proxy Approaches 297 This section discusses fundamental RSVP Proxy approaches. 299 4.1. Path-Triggered Receiver Proxy 301 In this approach, it is assumed that the sender is RSVP capable and 302 takes full care of the synchronization between application 303 requirements and RSVP reservations. With this approach, the RSVP 304 Receiver Proxy uses the RSVP Path messages generated by the sender as 305 the cue for establishing the RSVP reservation on behalf of the 306 receiver. The RSVP Receiver Proxy is effectively acting as a slave 307 making reservations (on behalf of the receiver) under the sender's 308 control. This changes somewhat the usual RSVP reservation model 309 where reservations are normally controlled by receivers. Such a 310 change greatly facilitates operations in the scenario of interest 311 here, which is where the receiver is not RSVP capable. Indeed it 312 allows the RSVP Receiver Proxy to remain application unaware by 313 taking advantage of the application awareness and RSVP awareness of 314 the sender. 316 With the Path-Triggered RSVP Receiver Proxy approach, the RSVP router 317 may be configured to use receipt of a regular RSVP Path message as 318 the trigger for RSVP Receiver Proxy behavior. 320 On receipt of the RSVP Path message, the RSVP Receiver Proxy: 322 1. establishes the RSVP Path state as per regular RSVP processing 324 2. identifies the downstream interface towards the receiver 326 3. sinks the Path message 328 4. behaves as if a Resv message (whose details are discussed below) 329 was received on the downstream interface. This includes 330 performing admission control on the downstream interface, 331 establishing a Resv state (in case of successful admission 332 control) and forwarding the Resv message upstream, sending 333 periodic refreshes of the Resv message and tearing down the 334 reservation if the Path state is torn down. 336 In order to build the Resv message, the RSVP Receiver Proxy can take 337 into account information received in the Path message. For example, 338 the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv 339 message which mirrors the SENDER_TSPEC object in the received Path 340 message. 342 Operation of the Path-Triggered Receiver Proxy in the case of a 343 successful reservation is illustrated in Figure 3. 345 |----| *** *** |----------| |----| 346 | S |---------*r*----------*r*---------| RSVP |----------| R | 347 |----| *** *** | Receiver | |----| 348 | Proxy | 349 |----------| 351 ---Path---> ----Path----> ---Path----> 353 <--Resv---> <---Resv----- <--Resv---- 355 ==================RSVP===============> 357 **********************************************************> 359 |----| RSVP-capable |----| Non-RSVP-capable *** 360 | S | Sender | R | Receiver *r* regular RSVP 361 |----| |----| *** router 363 ***> media flow 365 ==> segment of flow path protected by RSVP reservation 367 Figure 3: Path-Triggered RSVP Receiver Proxy 369 In case the reservation establishment is rejected (for example 370 because of an admission control failure on a regular RSVP router on 371 the path between the RSVP-capable sender and the RSVP Receiver 372 Proxy), a ResvErr message will be generated as per conventional RSVP 373 operations and will travel downstream towards the RSVP Receiver 374 Proxy. While this ensures that the RSVP Receiver Proxy is aware of 375 the reservation failure, conventional RSVP procedures do not cater 376 for notification of the sender of the reservation failure. Operation 377 of the Path-Triggered RSVP Receiver Proxy in the case of an admission 378 control failure is illustrated in Figure 4. 380 |----| *** *** |----------| |----| 381 | S |---------*r*----------*r*---------| RSVP |----------| R | 382 |----| *** *** | Receiver | |----| 383 | Proxy | 384 |----------| 386 ---Path---> ----Path----> ---Path----> 388 <---Resv----- <--Resv------ 390 ---ResvErr---> --ResvErr---> 392 ===================RSVP===============> 394 **********************************************************> 396 |----| RSVP-capable |----| Non-RSVP-capable *** 397 | S | Sender | R | Receiver *r* regular RSVP 398 |----| |----| *** router 400 ***> media flow 402 ==> segment of flow path protected by RSVP reservation 404 Figure 4: Path-Triggered RSVP Receiver Proxy with Failure 406 Since, as explained above, in this scenario involving the RSVP 407 Receiver Proxy, synchronization between application and RSVP 408 reservation is generally performed by the sender, notifying the 409 sender of reservation failure is needed. 410 [I-D.ietf-tsvwg-rsvp-proxy-proto] specifies RSVP extensions allowing 411 such sender notification in case of reservation failure in the 412 presence of a Path-Triggered RSVP Receiver Proxy. 414 4.2. Path-Triggered Sender Proxy for Reverse Direction 416 In this approach, it is assumed that one endpoint is RSVP capable and 417 takes full care of the synchronization between application 418 requirements and RSVP reservations. This endpoint is the sender for 419 one flow direction (which we refer to as the "forward" direction) and 420 is the receiver for the flow in the opposite direction (which we 421 refer to as the "reverse" direction). 423 With the Path-Triggered Sender Proxy for Reverse Direction approach, 424 the RSVP Proxy uses the RSVP signaling generated by the sender as the 425 cue for initiating RSVP signaling for the reservation in the reverse 426 direction. Thus, the RSVP Proxy is effectively acting as a Sender 427 Proxy for the reverse direction under the control of the sender for 428 the forward direction. Note that this assumes a degree of symmetry 429 for the two directions of the flow (as is currently typical for IP 430 telephony, for example). This is illustrated in Figure 5. 432 |----| *** *** |----------| |----| 433 | R |---------*r*----------*r*---------| RSVP |----------| S | 434 |----| *** *** | Sender | |----| 435 | Proxy | 436 |----------| 438 ---Path---> ----Path----> ---Path----> 440 <--Path---> <---Path----- <--Path---- 442 ---Resv---> ----Resv----> ---Resv----> 444 <================RSVP================== 446 <********************************************************** 448 |----| RSVP-capable |----| Non-RSVP-capable *** 449 | R | Receiver | S | Sender *r* regular RSVP 450 |----| |----| *** router 452 ***> media flow 454 ==> segment of flow path protected by RSVP reservation 455 in reverse direction 457 Figure 5: Path-Triggered Sender Proxy for Reverse Direction 459 Of course, the RSVP Proxy may simultaneously (and typically will) 460 also act as the Path-Triggered Receiver Proxy for the forward 461 direction, as defined in Section 4.1. Such an approach is most 462 useful in situations involving RSVP reservations in both directions 463 for symmetric flows. This is illustrated in Figure 6. 465 |----| *** *** |----------| |----| 466 |S/R |---------*r*----------*r*---------| RSVP |----------|S/R&| 467 |----| *** *** | Receiver | |----| 468 | & Sender | 469 | Proxy | 470 |----------| 472 ---Path---> ----Path----> ---Path----> 474 <--Resv---> <---Resv----- <--Resv---- 476 <--Path---> <---Path----- <--Path---- 478 ---Resv---> ----Resv----> ---Resv----> 480 ================RSVP==================> 481 <================RSVP================== 483 **********************************************************> 484 <********************************************************** 486 |----| RSVP-capable |----| Non-RSVP-capable *** 487 |S/R | Sender and |S/R&| Sender and *r* regular RSVP 488 |----| Receiver |----| Receiver *** router 490 ***> media flow 492 ==> segment of flow path protected by RSVP reservation 493 in forward and in reverse direction 495 Figure 6: Path Triggered Receiver & Sender Proxy 497 With the Path-Triggered Sender Proxy for Reverse Direction approach, 498 the RSVP router may be configurable to use receipt of a regular RSVP 499 Path message as the trigger for Sender Proxy for Reverse Direction 500 behavior. 502 On receipt of the RSVP Path message for the forward direction, the 503 RSVP Sender Receiver Proxy : 505 1. sinks the Path message 507 2. behaves as if a Path message for reverse direction (whose details 508 are discussed below) had been received by the Sender Proxy. This 509 includes establishing the corresponding Path state, forwarding 510 the Path message downstream, sending periodic refreshes of the 511 Path message and tearing down the Path in reverse direction when 512 the Path state in forward direction is torn down. 514 In order to build the Path message for the reverse direction, the 515 RSVP Sender Proxy can take into account information in the received 516 Path message for the forward direction. For example, the RSVP Sender 517 Proxy may mirror the SENDER_TSPEC object in the received Path 518 message. 520 We observe that this approach does not require any extensions to the 521 existing RSVP protocol. 523 4.3. Inspection-Triggered Proxy 525 In this approach, it is assumed that the RSVP Proxy is on the 526 datapath of "packets of interest", that it can inspect such packets 527 on the fly as they transit through it, and that it can infer 528 information from these packets of interest to determine what RSVP 529 reservations need to be established, when and with what 530 characteristics (possibly also using some configured information). 532 One example of "packets of interest" could be application level 533 signaling. An RSVP Proxy capable of inspecting SIP signaling for 534 multimedia session or RTSP signaling for Video streaming, can obtain 535 from such signaling information about when a multimedia session is up 536 or when a Video is going to be streamed. It can also identify the 537 addresses and ports of senders and receivers and can determine the 538 bandwidth of the corresponding flows. Thus, such an RSVP Proxy can 539 determine all necessary information to synchronize RSVP reservations 540 to application requirements. This is illustrated in Figure 7. 542 |-------------| 543 | Application | 544 | Signaling | 545 | Entity | 546 |-------------| 547 / \ 548 / \ 549 / \ 550 552 |----| |--------| *** |--------| |----| 553 | S |--------| RSVP |------*r*--------| RSVP |----------| R | 554 |----| | Proxy | *** | Proxy | |----| 555 |--------| |--------| 557 =======RSVP=======> 559 ********************************************************> 561 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 562 | S | Sender | R | Receiver *r* regular RSVP 563 |----| |----| *** router 565 application level signaling 567 ***> media flow 569 ==> segment of flow path protected by RSVP reservation 571 Figure 7: Inspection-Triggered RSVP Proxy 573 Another example of "packets of interest" could be packets belonging 574 to the application flow itself (e.g. media packets). An RSVP Proxy 575 capable of detecting the transit of packets from a particular flow, 576 can attempt to establish a reservation corresponding to that flow. 577 Characteristics of the reservation may be derived from configuration, 578 flow measurement or a combination of those. 580 Note however, that in case of reservation failure, the inspection- 581 triggered RSVP Proxy does not have a direct mechanism for notifying 582 the application (since it is not participating itself actively in 583 application signaling) so that the application takes appropriate 584 action (for example terminate the corresponding session). To 585 mitigate this problem, the inspection-triggered RSVP Proxy may mark 586 differently the DSCP of flows for which an RSVP reservation has been 587 successfully proxied from the flows for which a reservation is not in 588 place. In some situations, the Inspection-Triggered Proxy might be 589 able to modify the "packets of interest" (e.g. application signaling 590 messages) to convey some hint to applications that the corresponding 591 flows cannot be guaranteed by RSVP reservations. 593 With the inspection-triggered Proxy approach, the RSVP Receiver Proxy 594 is effectively required to attempt to build application awareness by 595 traffic inspection and then is somewhat limited in the actions in can 596 take in case of reservation failure. However, this may be a useful 597 approach in some environments. Note also that this approach does not 598 require any change to the RSVP protocol. 600 With the "Inspection-Triggered" RSVP Proxy approach, the RSVP router 601 may be configurable to use and interpret some specific "packets of 602 interest" as the trigger for RSVP Receiver Proxy behavior. 604 4.4. STUN-Triggered Proxy 606 In this approach, the RSVP Proxy takes advantage of the application 607 awareness provided by the STUN signaling to synchronize RSVP 608 reservations with application requirements. The STUN signaling is 609 sent from endpoint to endpoint. This is illustrated in Figure 8. 611 |----| |--------| *** |--------| |----| 612 | S |--------| RSVP |------*r*--------| RSVP |----------| R | 613 |----| | Proxy | *** | Proxy | |----| 614 |--------| |--------| 616 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^> 618 =======RSVP=======> 620 ********************************************************> 622 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 623 | S | Sender | R | Receiver *r* regular RSVP 624 |----| |----| *** router 626 ^^^> STUN message flow (over same UDP ports as media flow) 628 ==> segment of flow path protected by RSVP reservation 630 ***> RTP media flow 632 Figure 8: STUN-Triggered Proxy 634 In this approach, a STUN [I-D.ietf-behave-rfc3489bis] message 635 triggers the RSVP Proxy. The STUN message could also include (yet- 636 to-be-specified) STUN attributes to indicate information such as the 637 bandwidth and application requesting the flow, which would allow the 638 RSVP proxy agent to create an appropriately-sized reservation for 639 each flow. 641 For unicast flows, [I-D.ietf-mmusic-ice] is an already widely-adopted 642 emerging standard for NAT traversal. For our purposes of triggering 643 RSVP Proxy behavior, we rely on ICE's connectivity check -- the 644 exchange of STUN Binding Request messages between hosts to verify 645 connectivity (see section 2.2 of [I-D.ietf-mmusic-ice]). By 646 including new STUN attributes in those connectivity check messages, 647 an RSVP Proxy agent could perform its functions more effectively. 648 Additionally, the RSVP Proxy agent can inform endpoints of an RSVP 649 reservation failure by dropping the ICE connectivity check message or 650 sending ICMP messages back to the endpoint. This provides very RSVP- 651 like call admission control and signaling to the endpoints, without 652 implementing RSVP on the endpoints, and also operates through NATs. 654 For multicast flows (or certain kinds of unicast flows that don't or 655 can't use ICE), a STUN Indication message 656 [I-D.ietf-behave-rfc3489bis] could indicate the flow's bandwidth, 657 providing a benefit similar to the ICE connectivity check. STUN 658 Indication messages are not acknowledged by the receiver and have the 659 same scalability as the underlying multicast flow. 661 The corresponding extensions to ICE and STUN for such a STUN- 662 triggered RSVP Proxy approach are beyond the scope of this document. 663 They may be defined in the future in a separate document. 665 4.5. Application_Entity-Controlled Proxy 667 In this approach, it is assumed that an entity involved in the 668 application level signaling controls an RSVP Proxy which is located 669 in the datapath of the application flows (i.e. "on-path"). With this 670 approach, the RSVP Proxy does not attempt to determine itself the 671 application reservation requirements. Instead the RSVP Proxy is 672 instructed by the entity participating in application level signaling 673 to establish, maintain and tear down reservations as needed by the 674 application flows. In other words, with this approach, the solution 675 for synchronizing RSVP signaling with application level requirements 676 is to rely on an application-level signaling entity that controls an 677 RSVP Proxy function that sits in the flow datapath. This approach 678 allows control of an RSVP Sender Proxy, an RSVP Receiver Proxy or 679 both. 681 Operation of the Application_Entity-Controlled Proxy is illustrated 682 in Figure 9. 684 |---------| |---------| 685 /////////| App |////\\\\| App |\\\\\\\\ 686 / | Entity | | Entity | \ 687 / |---------| |---------| \ 688 / // \\ \ 689 / // \\ \ 690 / // \\ \ 691 / // \\ \ 692 / // \\ \ 693 |----| |--------| *** |---------| |----| 694 | S |----------| |------*r*-------| |---------| R | 695 |----| | RSVP | *** | RSVP | |----| 696 | Sender | | Receiver| 697 | Proxy | | Proxy | 698 |--------| |---------| 700 =======RSVP=======> 702 ********************************************************> 704 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 705 | S | Sender | R | Receiver *r* regular RSVP 706 |----| |----| *** router 708 ***> media flow 710 ==> segment of flow path protected by RSVP reservation 712 /\ Application signaling (e.g. SIP) 714 // RSVP Proxy control interface 716 Figure 9: Application_Entity-Controlled Proxy 718 As an example, the Application_Entity-Controlled Proxy may be used in 719 the context of Session Border Controllers (SBCs) (see 720 [I-D.ietf-sipping-sbc-funcs] for description of SBCs) to establish 721 RSVP reservations for multimedia sessions. In that case, the 722 Application Entity may be the signaling component of the SBC. 724 This RSVP Proxy approach does not require any extension to the RSVP 725 protocol. However, it relies on an RSVP Proxy control interface 726 allowing control of the RSVP Proxy by an application signaling 727 entity. This RSVP Proxy control interface is beyond the scope of the 728 present document. Candidate protocols for realizing such interface 729 include SNMP, COPS-PR, QPIM, XML and DIAMETER. This interface may 730 rely on soft states or hard states. Clearly, when hard states are 731 used, those need to be converted appropriately by the RSVP Proxy 732 entities into the corresponding RSVP soft states. 734 In general, the Application Entity is not expected to maintain 735 awareness of which RSVP Receiver Proxy is on the path to which 736 destination. However, in the particular cases where it does so 737 reliably, we observe that the Application Entity could control the 738 RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP 739 reservations are used between those, instead of one reservation per 740 flow. For example, these aggregate reservations could be of RSVP- 741 AGGREGATE type as specified in [RFC3175] or of GENERIC-AGGREGATE type 742 as specified in [RFC4860]. Such aggregate reservations could be used 743 so that a single reservation can be used for multiple (possibly all) 744 application flows transiting via the same RSVP Sender Proxy and the 745 same RSVP Receiver Proxy. 747 For situations where only the RSVP Sender Proxy has to be controlled 748 by this interface, the interface may be realized through the simple 749 use of RSVP itself, over a GRE tunnel from the application entity to 750 the RSVP Sender Proxy. This particular case is further discussed in 751 Section 4.5.1. Another particular case of interest is where the 752 application signaling entity resides on the same device as the RSVP 753 Proxy. In that case, this interface may be trivially realized as an 754 internal API. An example environment based on this particular case 755 is illustrated in Section 4.5.2. 757 4.5.1. Application_Entity-Controlled Sender Proxy using "RSVP over GRE" 759 This approach is simply a particular case of the more general 760 Application_Entity-Controlled Proxy, but where only RSVP Sender 761 Proxies need to be controlled by the application, and where RSVP is 762 effectively used as the control protocol between the application 763 signaling entity and the RSVP Sender Proxy. 765 In this approach, the RSVP messages (e.g. RSVP Path message) are 766 effectively generated by the application entity and logically 767 "tunnelled" to the RSVP Sender Proxy via GRE tunneling. This is to 768 ensure that the RSVP messages follow the exact same path as the flow 769 they protect (as required by RSVP operations) on the segment of the 770 end-to-end path which is to be subject to RSVP reservations. 772 Figure 10 illustrates such an environment. 774 |-------------| 775 ////////////| Application |\\\\\\\\\ 776 / | Entity | \ 777 / |-------------| \ 778 / /=/ \ 779 / /=/ \ 780 / /=/ \ 781 / /=/ \ 782 / /=/ \ 783 / /=/ \ 784 / /=/ \ 785 / /=/ \ 786 |----| |--------| *** |----| 787 | S |-----------| RSVP |-----------*r*-----------------| R | 788 |----| | Sender | *** |----| 789 | Proxy | 790 |--------| 792 =========RSVP====================> 794 *****************************************************> 796 |----| non-RSVP-capable |----| RSVP-capable *** 797 | S | Sender | R | Receiver *r* regular RSVP 798 |----| |----| *** router 800 ***> media flow 802 ==> segment of flow path protected by RSVP reservation 804 /\ Application level signaling 806 /=/ GRE-tunnelled RSVP (Path messages) 808 Figure 10: Application-Entity-Controlled Sender Proxy via "RSVP over 809 GRE" 811 With the Application_Entity-Controlled Sender Proxy using "RSVP Over 812 GRE", the application entity : 814 o generates a Path message on behalf of the sender, corresponding to 815 the reservation needed by the application and maintains the 816 corresponding Path state. The Path message built by the 817 application entity is exactly the same as would be built by the 818 actual sender (if it was RSVP-capable), with one single exception 819 which is that the Application Entity puts its own IP address as 820 the RSVP Previous Hop. In particular, it is recommended that the 821 source address of the Path message built by the application entity 822 be set to the IP address of the sender (not of the application 823 entity). This helps ensuring that, in the presence of non-RSVP 824 routers and of load-balancing in the network where the load- 825 balancing algorithm takes into account the source IP address, the 826 Path message generated by the application entity follows the exact 827 same path that the actual stream sourced by the sender. 829 o encapsulates the Path message into a GRE tunnel whose destination 830 address is the RSVP Sender Proxy i.e. an RSVP Router sitting on 831 the datapath for the flow (and upstream of the segment which 832 requires QoS guarantees via RSVP reservation). 834 o processes the corresponding received RSVP messages (including Resv 835 messages) as per regular RSVP. 837 o synchronizes the RSVP reservation state with application level 838 requirements and signaling. 840 Note that since the application entity encodes its own IP address as 841 the RSVP PHOP in the Path message, the RSVP Router terminating the 842 GRE tunnel naturally addresses all the RSVP messages travelling 843 upstream hop-by-hop (such as Resv messages) to the application entity 844 (without having to encapsulate those in a reverse-direction GRE 845 tunnel towards the application entity). 847 4.5.2. Application_Entity-Controlled Proxy via Co-Location 849 This approach is simply a particular case of the more general 850 Application_Entity-Controlled Proxy, but where the application entity 851 is co-located with the RSVP Proxy. As an example, Session Border 852 Controllers (SBC) with on-board SIP agents could implement RSVP Proxy 853 functions and make use of such an approach to achieve session 854 admission control over the SBC-to-SBC segment using RSVP signaling. 856 Figure 11 illustrates operations of the Application_Entity-Controlled 857 RSVP Proxy via Co-location. 859 |---------| |---------| 860 ////////| App |////////\\\\\\\| App |\\\\\\\\\ 861 / | Entity | | Entity | \ 862 / | | | | \ 863 |----| |---------| *** |---------| |----| 864 | S |--------| RSVP |------*r*------| RSVP |---------| R | 865 |----| | Sender | *** | Receiver| |----| 866 | Proxy | | Proxy | 867 |---------| |---------| 869 =======RSVP======> 871 *******************************************************> 873 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 874 | S | Sender | R | Receiver *r* regular RSVP 875 |----| |----| *** router 877 ***> media flow 879 ==> segment of flow path protected by RSVP reservation 881 /\ Application level signaling 883 Figure 11: Application_Entity-Controlled Proxy via Co-Location 885 This RSVP Proxy approach does not require any protocol extensions. 886 We also observe that when multiple sessions are to be established on 887 paths sharing the same RSVP Sender Proxy and the same RSVP Receiver 888 Proxy, the RSVP Proxies have the option to establish aggregate RSVP 889 reservations (as defined in ([RFC3175] or [RFC4860]) for a group of 890 sessions, instead of establishing one RSVP reservation per session. 892 4.6. Policy_Server-Controlled Proxy 894 In this approach, it is assumed that a Policy Server, which is 895 located in the control plane of the network, controls an RSVP Proxy 896 which is located in the datapath of the application flows (i.e. "on- 897 path"). In turn, the Policy server is triggered by an entity 898 involved in the application level signaling. With this approach, the 899 RSVP Proxy does not attempt to determine itself the application 900 reservation requirements, but instead is instructed by the Policy 901 Server to establish, maintain and tear down reservations as needed by 902 the application flows. Moreover, the entity participating in 903 application level signaling does not attempt to understand the 904 specific reservation mechanism (i.e. RSVP) or the topology of the 905 network layer, but instead it simply asks the policy server to 906 perform (or teardown) a reservation. In other words, with this 907 approach, the solution for synchronizing RSVP signaling with 908 application level requirements is to rely on an application level 909 entity that controls a policy server that, in turn, controls an RSVP 910 Proxy function that sits in the flow datapath. This approach allows 911 control of an RSVP Sender Proxy, an RSVP Receiver Proxy or both. 913 Operation of the Policy_Server-Controlled Proxy is illustrated 914 Figure 12. 916 |---------| 917 /////////////| App |\\\\\\\\\\\\\\ 918 / | Entity | \ 919 / |---------| \ 920 / I \ 921 / I \ 922 / |----------| \ 923 / | Policy | \ 924 / | Server | \ 925 / |----------| \ 926 / // \\ \ 927 / // \\ \ 928 / // \\ \ 929 |----| |--------| *** |---------| |----| 930 | S |-----------| |------*r*-----| |----------| R | 931 |----| | RSVP | *** | RSVP | |----| 932 | Sender | | Receiver| 933 | Proxy | | Proxy | 934 |--------| |---------| 936 =====RSVP========> 938 **********************************************************> 940 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 941 | S | Sender | R | Receiver *r* regular RSVP 942 |----| |----| *** router 944 ***> media flow 946 ==> segment of flow path protected by RSVP reservation 948 /\ Application signaling (e.g. SIP) 950 // RSVP Proxy control interface 952 I Interface between Application Entity and Policy Server 954 Figure 12: Policy_Server-Controlled Proxy 956 This RSVP Proxy approach does not require any extension to the RSVP 957 protocol. However, as with the Application_Entity-Controlled Proxy 958 approach presented in Figure 9, this approach relies on an RSVP Proxy 959 control interface allowing control of the RSVP Proxy (by the Policy 960 Server in this case). This RSVP Proxy control interface is beyond 961 the scope of the present document. Considerations about candidate 962 protocols for realizing such interface can be found in Section 4.5. 964 Again, for situations where only the RSVP Sender Proxy has to be 965 controlled by this interface, the interface may be realized through 966 the simple use of RSVP Itself, over a GRE tunnel from the Policy 967 Server to the RSVP Sender Proxy. This is similar to what is 968 presented in Section 4.5.1 except that the "RSVP over GRE" interface 969 is used in this case by the Policy Server (instead of the application 970 entity). 972 The interface between the Application Entity and the Policy Server is 973 beyond the scope of this document. 975 4.7. RSVP-Signaling-Triggered Proxy 977 An RSVP Proxy can also be triggered and controlled through extended 978 RSVP signaling from the remote end that is RSVP-capable (and supports 979 these RSVP extensions for Proxy control). For example, an RSVP 980 capable sender could send a new or extended RSVP message explicitly 981 requesting an RSVP Proxy on the path towards the receiver to behave 982 as an RSVP Receiver Proxy and also to trigger a reverse direction 983 reservation thus also behaving as a RSVP Sender Proxy. The new or 984 extended RSVP message sent by the sender could also include 985 attributes (e.g. bandwidth) for the reservations to be signaled by 986 the RSVP Proxy. 988 The challenges in these explicit signaling schemes include: 990 o How can the nodes determine when a reservation request ought to be 991 proxied and when it should not, and accordingly invoke appropriate 992 signaling procedures? 994 o How does the node sending the messages explicitly triggering the 995 Proxy know where the Proxy is located, e.g., determine an IP 996 address of the proxy that should reply to the signaling? 998 o How is all the information needed by a Sender Proxy to generate a 999 Path message actually communicated to the Proxy? 1001 An example of such a mechanism is presented in 1002 [I-D.manner-tsvwg-rsvp-proxy-sig]. This scheme is primarily targeted 1003 to local access network reservations whereby an end host can request 1004 resource reservations for both incoming and outgoing flows only over 1005 the access network. This may be useful in environments where the 1006 access network is typically the bottleneck while the core is 1007 comparatively over-provisioned, as may be the case with a number of 1008 radio access technologies. In this proposal, messages targeted to 1009 the Proxy are flagged with one bit in all RSVP messages. Similarly, 1010 all RSVP messages sent back by the Proxy are also flagged. The use 1011 of such a flag allows differentiating between proxied and end-to-end 1012 reservations. For triggering an RSVP Receiver Proxy, the sender of 1013 the data sends a Path message which is marked with the mentioned 1014 flag. The Receiver Proxy is located on the signaling and data path, 1015 eventually gets the Path message, and replies back with a Resv 1016 message. A node triggers an RSVP Sender Proxy with a newly defined 1017 Path_Request message, which instructs the proxy to send Path messages 1018 towards the triggering node. The node then replies back with a Resv. 1019 More details can be found in [I-D.manner-tsvwg-rsvp-proxy-sig]. 1021 Such an RSVP-Signaling-Triggered Proxy approach would require RSVP 1022 signaling extensions (that are outside the scope of the present 1023 document). However it could provide more flexibility in the control 1024 of the Proxy behavior (e.g. control of reverse reservation 1025 parameters) than provided by the Path-Triggered approaches defined in 1026 Section 4.1 and Section 4.2. 1028 4.8. Endsystem-Controlled Proxy 1030 In some cases, having a full RSVP implementation running on an end 1031 host can be seen to produce excessive overhead. In end-hosts that 1032 are low in processing power and functionality, having an RSVP daemon 1033 run and take care of the signaling may introduce unnecessary 1034 overhead. One article [Kars01] proposes to create a remote API so 1035 that the daemon would in fact run on the end-host's default router 1036 and the end-host application would send its requests to that daemon. 1037 Thus, we can have deployments, where an end host uses some 1038 lightweight protocol to communicate with its pre-defined RSVP router 1039 - a form of RSVP proxy. Such a lightweight protocol is outside the 1040 scope of the present document. 1042 4.9. Reachability Considerations 1044 There may be situations where the RSVP Receiver Proxy is reachable by 1045 the sender, while the receiver itself is not. In such situations, it 1046 is possible that the RSVP Receiver Proxy is not always aware that the 1047 receiver is unreachable, and consequently may accept to establish an 1048 RSVP reservation on behalf of that receiver. This would result in 1049 unnecessary reservation establishment and unnecessary network 1050 resource consumption. 1052 This is not considered a significant practical concern for a number 1053 of reasons. First, in many cases, if the receiver is not reachable 1054 from the sender, it will not be reachable either for application 1055 signaling so that application level session establishment will not be 1056 possible in the first place. Secondly, where the receiver is 1057 unreachable from the sender but is reachable for application level 1058 signaling (say because session establishment is performed through an 1059 off-path SIP agent that uses a different logical topology to 1060 communicate with the receiver), then the sender may detect that the 1061 receiver is unreachable before attempting reservation establishment. 1062 This may be achieved through mechanisms such as ICE's connectivity 1063 check ( [I-D.ietf-mmusic-ice]). Finally, even if the sender does not 1064 detect that the receiver is unreachable before triggering the RSVP 1065 reservation establishment, it is very likely that the application 1066 will quickly realise this lack of connectivity (e.g. the human 1067 accepting the phone call on the receiver side will not hear the 1068 human's voice on the sender side) and therefore tear down the session 1069 (e.g. hang up the phone) which in turn will trigger RSVP reservation 1070 release. 1072 Nonetheless, it is recommended that network administrators consider 1073 the above in light of their particular environment when deploying 1074 RSVP Proxys. 1076 The mirror considerations apply for situations involving an RSVP 1077 Sender Proxy and where the sender cannot reach the destination while 1078 the RSVP Sender Proxy can. 1080 5. Security Considerations 1082 In the environments of concern for this document, RSVP messages are 1083 used to control resource reservations on a segment of the end-to-end 1084 path of flows. To ensure the integrity of the associated reservation 1085 and admission control mechanisms, the cryptographic authentication 1086 mechanisms defined in [RFC2747]] and [RFC3097] can be used. Those 1087 protect RSVP messages integrity hop-by-hop and provide node 1088 authentication, thereby protecting against corruption, spoofing of 1089 RSVP messages and replay. 1090 [I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses key types, 1091 key provisioning methods as well as their respective applicability. 1093 A number of additional security considerations apply to the use of 1094 RSVP proxies and are discussed below. 1096 With some RSVP Proxy approaches, the RSVP proxy operates autonomously 1097 inside an RSVP router. This is the case for the Path-Triggered Proxy 1098 approaches defined in Section 4.1 and in Section 4.2, for the 1099 Inspection-Triggered Proxy approach defined in Section 4.3, for the 1100 STUN-Triggered Proxy approach defined in Section 4.4 and for the 1101 RSVP-Signaling-Triggered approach defined in Section 4.7. Proper 1102 reservation operation assumes that the RSVP proxy can be trusted to 1103 behave correctly in order to control the RSVP reservation as required 1104 and expected by the end systems. Since, the basic RSVP operation 1105 already assumes a trust model where end-systems trust RSVP nodes to 1106 appropriately perform RSVP reservations, the use of RSVP proxy that 1107 behave autonomously within an RSVP router is not seen as introducing 1108 any significant additional security threat or as fundamentally 1109 modifying the RSVP trust model. 1111 With some RSVP Proxy approaches, the RSVP proxy operate under the 1112 control of another entity. This is the case for the 1113 Application_Entity-Controlled Proxy approach defined in Section 4.5 1114 and for the Policy_Server-Controlled Proxy approach defined in 1115 Section 4.6. This introduces additional security risks since the 1116 entity controlling the RSVP Proxy needs to be trusted for proper 1117 reservation operation. The exact mechanisms to establish such trust 1118 are beyond the scope of this document, but they may include security 1119 mechanisms inside the protocol used as the control interface between 1120 the RSVP Proxy and the entity controlling it, as well as security 1121 mechanisms for all the interfaces involved in the reservation control 1122 chain (e.g. inside the application signaling protocol between the end 1123 systems and the application entity, and, in the case of the 1124 Policy_Server-Controlled Proxy approach, in the protocol between the 1125 application entity and the policy server). 1127 In some situations, the use of RSVP Proxy to control reservations on 1128 behalf of end-systems may actually reduce the security risk (at least 1129 from the network operator viewpoint). This could be the case, for 1130 example, because the routers where the RSVP Proxy functionality runs 1131 are less exposed to tampering than end-systems. Such a case is 1132 further discussed in section 4 of [I-D.ietf-tsvwg-rsvp-proxy-proto]. 1134 6. IANA Considerations 1136 This document does not make any request to IANA registration. 1138 7. Acknowledgments 1140 This document benefited from earlier work on the concept of RSVP 1141 Proxy including the one documented by Silvano Gai, Dinesh Dutt, 1142 Nitsan Elfassy and Yoram Bernet. It also benefited from discussions 1143 with Pratik Bose, Chris Christou and Michael Davenport. Tullio 1144 Loffredo and Massimo Sassi provided the base material for 1145 Section 4.6. 1147 8. Informative References 1149 [I-D.behringer-tsvwg-rsvp-security-groupkeying] 1150 Behringer, M. and F. Le Faucheur, "A Framework for RSVP 1151 Security Using Dynamic Group Keying", July 2007. 1153 [I-D.ietf-behave-rfc3489bis] 1154 Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. 1155 Wing, "Session Traversal Utilities for (NAT) (STUN)", 1156 draft-ietf-behave-rfc3489bis-09 (work in progress), 1157 August 2007. 1159 [I-D.ietf-mmusic-ice] 1160 Rosenberg, J., "Interactive Connectivity Establishment 1161 (ICE): A Protocol for Network Address Translator (NAT) 1162 Traversal for Offer/Answer Protocols", 1163 draft-ietf-mmusic-ice-17 (work in progress), July 2007. 1165 [I-D.ietf-sipping-sbc-funcs] 1166 Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 1167 A., and M. Bhatia, "Requirements from SIP (Session 1168 Initiation Protocol) Session Border Control Deployments", 1169 April 2007. 1171 [I-D.ietf-tsvwg-rsvp-proxy-proto] 1172 Le Faucheur, L., "RSVP Extensions For Path-Triggered RSVP 1173 Receiver Proxy", February 2007. 1175 [I-D.ietf-tsvwg-vpn-signaled-preemption] 1176 Baker, F. and P. Bose, "QoS Signaling in a Nested Virtual 1177 Private Network", February 2007. 1179 [I-D.manner-tsvwg-rsvp-proxy-sig] 1180 Manner, J., "Localized RSVP for Controlling RSVP Proxies", 1181 October 2006. 1183 [Kars01] Karsten, M., "Experimental Extensions to RSVP -- Remote 1184 Client and One-Pass Signalling", IWQoS Karlsruhe, Germany, 1185 2006. 1187 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1188 Services in the Internet Architecture: an Overview", 1189 RFC 1633, June 1994. 1191 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1192 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1193 Functional Specification", RFC 2205, September 1997. 1195 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1196 Services", RFC 2210, September 1997. 1198 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1199 and W. Weiss, "An Architecture for Differentiated 1200 Services", RFC 2475, December 1998. 1202 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1203 Authentication", RFC 2747, January 2000. 1205 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1206 and S. Molendini, "RSVP Refresh Overhead Reduction 1207 Extensions", RFC 2961, April 2001. 1209 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 1210 Authentication -- Updated Message Type Value", RFC 3097, 1211 April 2001. 1213 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1214 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 1215 RFC 3175, September 2001. 1217 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 1218 "Integration of Resource Management and Session Initiation 1219 Protocol (SIP)", RFC 3312, October 2002. 1221 [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, 1222 "Gateway Control Protocol Version 1", RFC 3525, June 2003. 1224 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1225 Internet Protocol", RFC 4301, December 2005. 1227 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 1228 Davenport, "Generic Aggregate Resource ReSerVation 1229 Protocol (RSVP) Reservations", RFC 4860, May 2007. 1231 Appendix A. Use Cases for RSVP Proxies 1233 A.1. RSVP-based VoD CAC in Broadband Aggregation Networks 1235 As broadband services for residential are becoming more and more 1236 prevalent, next generation aggregation networks are being deployed in 1237 order to aggregate traffic from broadband users (whether attached via 1238 Digital Subscriber Line technology aka DSL, Fiber To The Home/Curb 1239 aka FTTx, Cable or other broadband access technology). Video on 1240 Demand (VoD) services which may be offered to broadband users present 1241 significant capacity planning challenges for the aggregation network 1242 for a number of reasons. First each VoD stream requires significant 1243 dedicated sustained bandwidth (typically 2-4 Mb/s in Standard 1244 Definition TV and 6-12 Mb/s in High Definition TV). Secondly, the 1245 VoD codec algorithms are very sensitive to packet loss. Finally, the 1246 load resulting from such services is very hard to predict (e.g. it 1247 can vary very suddenly with block-buster titles made available as 1248 well as with promotional offerings). As a result, transport of VoD 1249 streams on the aggregation network usually translate into a strong 1250 requirement for admission control. The admission control solution 1251 protects the quality of established VoD sessions by rejecting the 1252 additional excessive session attempts during unpredictable peaks, 1253 during link or node failures, or combination of those factors. 1255 RSVP can be used in the aggregation network for admission control of 1256 the VoD sessions. However, since Customer Premises equipment such as 1257 Set Top Boxes (which behave as the receiver for VoD streams) often do 1258 not support RSVP, the last IP hop in the aggregation network can 1259 behave as an RSVP Receiver Proxy. This way, RSVP can be used between 1260 VoD Pumps and the last IP hop in the Aggregation network to perform 1261 accurate admission control of VoD streams over the resources set 1262 aside for VoD in the aggregation network (typically a certain 1263 percentage of the bandwidth of any link). As VoD streams are 1264 unidirectional, a simple "Path-Triggered" RSVP Receiver Proxy (as 1265 described in Section 4.1) is all that is required in this use case. 1267 The Figure below illustrates operation of RSVP-based admission 1268 control of VoD sessions in an Aggregation network involving RSVP 1269 support on the VoD Pump (the senders) and RSVP Receiver Proxy on the 1270 last IP hop of the aggregation network. All the customer premises 1271 equipment remain RSVP unaware. 1273 |-------------| 1274 | VoD SRM | 1275 | | 1276 ////////| |\\\\\\\\\\\\\\\ 1277 / |-------------| \ 1278 / \ 1279 / \ 1280 / \ 1281 / \ 1282 / \ 1283 |----| |------| *** *** |--------| |-----| |---| 1284 | VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV 1285 |Pump| |Router| *** *** |Receiver| |-----| |---| 1286 |----| |------| |Proxy | 1287 |--------| 1289 <---Aggregation Net-------------> 1291 ******************************************************> 1293 ============RSVP====================> 1295 SRM Session Resource Manager 1297 *** |---| 1298 *r* regular RSVP |STB| Set Top Box 1299 *** router |---| 1301 ***> VoD media flow 1303 ==> segment of flow path protected by RSVP reservation 1305 /\ VoD Application level signaling (e.g. RTSP) 1307 Figure 13: VoD Use Case with Receiver Proxy 1309 In the case where the VoD Pumps are not RSVP-capable, an 1310 Application_Entity-Controlled Sender Proxy via "RSVP over GRE" 1311 approach (as described in Section 4.5.1) can also be implemented on 1312 the VoD Controller or Session Resource Manager (SRM) devices 1313 typically involved in VoD deployments. Figure 14 illustrates 1314 operation of RSVP-based admission control of VoD sessions in an 1315 Aggregation network involving such Application_Entity-Controlled 1316 Source Proxy combined with an RSVP Receiver Proxy on the last IP hop 1317 of the aggregation network. All the customer premises equipment, as 1318 well as the VoD pumps, remain RSVP unaware. 1320 |-------------| 1321 ////| VoD SRM |\\\\\\\\\\\ 1322 / | | \ 1323 / | + | \ 1324 / | RSVP Sender | \ 1325 / |Proxy Control| \ 1326 / |-------------| \ 1327 / /=/ \ 1328 / /=/ \ 1329 / /=/ \ 1330 / /=/ \ 1331 / /=/ \ 1332 |----| |------| *** *** |--------| |-----| |---| 1333 | VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV 1334 |Pump| |Sender| *** *** |Receiver| |-----| |---| 1335 |----| |Proxy | |Proxy | 1336 |------| |--------| 1338 <---Aggregation Net-------------> 1340 ******************************************************> 1342 =========RSVP==============> 1344 SRM Systems Resource Manager 1346 *** |---| 1347 *r* regular RSVP |STB| Set Top Box 1348 *** router |---| 1350 ***> VoD media flow 1352 ==> segment of flow path protected by RSVP reservation 1354 / VoD Application level signaling (e.g. RTSP) 1356 /=/ GRE-tunnelled RSVP (Path messages) 1358 Figure 14: VoD Use Case with Receiver Proxy and SRM-based Sender 1359 Proxy 1361 The RSVP Proxy entities specified in this document play a significant 1362 role here since they allow immediate deployment of an RSVP-based 1363 admission control solution for VoD without requiring any upgrade to 1364 the huge installed base of non-RSVP-capable customer premises 1365 equipment. In one mode described above, they also avoid upgrade of 1366 non-RSVP-capable VoD pumps. In turn, this means that the benefits of 1367 on-path admission control can be offered to VoD services over 1368 broadband aggregation networks without network or VoD Pump upgrade. 1369 Those include accurate bandwidth accounting regardless of topology 1370 (hub-and-spoke, ring, mesh, star, arbitrary combinations) and dynamic 1371 adjustment to any change in topology (such as failure, routing 1372 change, additional links...). 1374 A.2. RSVP-based Voice/Video CAC in Enterprise WAN 1376 More and more enterprises are migrating their telephony and 1377 videoconferencing applications onto IP. When doing so, there is a 1378 need for retaining admission control capabilities of existing TDM- 1379 based systems to ensure the QoS of these applications is maintained 1380 even when transiting through the enterprise's Wide Area Network 1381 (WAN). Since many of the endpoints already deployed (such as IP 1382 Phones or Videoconferencing terminals) are not RSVP capable, RSVP 1383 Proxy approaches are very useful: they allow deployment of an RSVP- 1384 based admission control solution over the WAN without requiring 1385 upgrade of the existing terminals. 1387 A common deployment architecture for such environments relies on the 1388 Application_Entity-Controlled Proxy approach as defined in 1389 Section 4.5. Routers sitting at the edges of the WAN network and 1390 naturally "on-path" for all inter-campus calls (or sessions) and 1391 behave as RSVP Proxies. The RSVP Proxies establish, maintain and 1392 tear-down RSVP reservations over the WAN segment for the calls (or 1393 sessions) under the control of the SIP Server/Proxy. The SIP Server/ 1394 Proxy synchronizes the RSVP reservation status with the status of 1395 end-to-end calls. For example, the called IP phone will only be 1396 instructed to play a ring tone if the RSVP reservations over the 1397 corresponding WAN segment has been successfully established. 1399 This architecture allowing RSVP-based admission control of voice and 1400 video on the Enterprise WAN is illustrated in Figure 15. 1402 |---------| 1403 //////////////| SIP |\\\\\\\\\\\\ 1404 / | Server/ | \ 1405 / | Proxy | \ 1406 / |---------| \ 1407 / // \\ \ 1408 / // \\ \ 1409 / // \\ \ 1410 / // \\ \ 1411 / // \\ \ 1412 |-----| |--------| *** *** |--------| |-----| 1413 | IP |------| Media |---*r*---*r*---| Media |-------|IP | 1414 |Phone| | Relay | *** *** | Relay | |Phone| 1415 |-----| | + | | + | |-----| 1416 | RSVP | | RSVP | 1417 | Proxy | | Proxy | 1418 |--------| |--------| 1420 <--campus--> <--campus--> 1421 network network 1423 <---------WAN-----------> 1425 <*************> <***********************> <**************> 1427 <=========RSVP===========> 1429 *** 1430 *r* Regular RSVP router 1431 *** 1433 <***> media flow 1435 <==> segment of flow path protected by RSVP reservation 1437 /\ SIP signaling 1439 // control interface between the SIP Server/Proxy and 1440 RSVP Proxy 1442 Figure 15: CAC on Enterprise WAN Use Case 1444 A.3. RSVP-based Voice CAC in Telephony Service Provider Core 1446 Let us consider an environment involving a Telephony Service Provider 1447 (TSP). Let us further assume that end-users are attached to the TSP 1448 via Session Border Controllers (SBCs). The SBCs may be remotely 1449 controlled by a SIP Server. The SIP Server may control establishment 1450 of RSVP reservations between the SBCs for admission control of 1451 sessions over the core. This relies on the Application_Entity- 1452 Controlled RSVP Proxy approach presented in Section 4.5. This is 1453 illustrated in the Figure below. 1455 |---------| 1456 //////////////| SIP |\\\\\\\\\\\\ 1457 / | Server/ | \ 1458 / | Proxy | \ 1459 / |---------| \ 1460 / // \\ \ 1461 / // \\ \ 1462 / // \\ \ 1463 / // \\ \ 1464 / // \\ \ 1465 |-----| |--------| *** *** |--------| |-----| 1466 | IP |------| |---*r*---*r*---| |-------|IP | 1467 |Phone| | SBC | *** *** | SBC | |Phone| 1468 |-----| | + | | + | |-----| 1469 | RSVP | | RSVP | 1470 | Proxy | | Proxy | 1471 |--------| |--------| 1473 <---Access----> <---Access-----> 1474 <---------Core----------> 1476 <*************> <***********************> <**************> 1478 <=========RSVP==========> 1480 *** 1481 *r* Regular RSVP router 1482 *** 1484 <***> media flow 1486 <==> segment of flow path protected by RSVP reservation 1488 /\ SIP signaling 1490 // control interface between the SIP Server/Proxy and 1491 SBC/RSVP Proxy 1493 Figure 16: Voice CAC in TSP Domain 1495 A.4. RSVP Proxies for Mobile Access Networks 1497 Mobile access networks are increasingly based on IP technology. This 1498 implies that, on the network layer, all traffic, both traditional 1499 data and streamed data like audio or video, is transmitted as 1500 packets. Increasingly popular multimedia applications would benefit 1501 from better than best-effort service from the network, a forwarding 1502 service with strict Quality of Service (QoS) with guaranteed minimum 1503 bandwidth and bounded delay. Other applications, such as electronic 1504 commerce, network control and management, and remote login 1505 applications, would also benefit from a differentiated treatment. 1507 The IETF has two main models for providing differentiated treatment 1508 of packets in routers. The Integrated Services (IntServ) model 1509 [RFC1633] together with the Resource Reservation Protocol (RSVP) 1510 [RFC2205] [RFC2210] [RFC2961] provides per-flow guaranteed end-to-end 1511 transmission service. The Differentiated Services (DiffServ) 1512 framework [RFC2475] provides non- signaled flow differentiation that 1513 usually provides, but does not guarantee, proper transmission 1514 service. 1516 However, these architectures have potential weaknesses for deployment 1517 in Mobile Access Networks. For example, RSVP requires support from 1518 both communication end points, and the protocol may have potential 1519 performance issues in mobile environments. DiffServ can only provide 1520 statistical guarantees and is not well suited for dynamic 1521 environments. 1523 Let us consider a scenario, where a fixed network correspondent node 1524 (CN) would be sending a multimedia stream to an end host behind a 1525 wireless link. If the correspondent node does not support RSVP it 1526 cannot signal its traffic characteristics to the network and request 1527 specific forwarding services. Likewise, if the correspondent node is 1528 not able to mark its traffic with a proper DiffServ Code Point (DSCP) 1529 to trigger service differentiation, the multimedia stream will get 1530 only best-effort service which may result in poor visual and audio 1531 quality in the receiving application. Even if the connecting wired 1532 network is over-provisioned, an end host would still benefit from 1533 local resource reservations, especially in wireless access networks, 1534 where the bottleneck resource is most probably the wireless link. 1536 RSVP proxies would be a very beneficial solution to this problem. It 1537 would allow distinguishing local network reservations from the end- 1538 to-end reservations. The end host does not need to know the access 1539 network topology or the nodes that will reserve the local resources. 1540 The access network would do resource reservations for both incoming 1541 and outgoing flows based on certain criterion, e.g., filters based on 1542 application protocols. Another option is that the mobile end host 1543 makes an explicit reservation that identifies the intention and the 1544 access network will find the correct local access network node(s) to 1545 respond to the reservation. RSVP proxies would, thus, allow resource 1546 reservation over the segment which is the most likely bottleneck, the 1547 wireless connectivity. If the wireless access network uses a local 1548 mobility management mechanism, where the IP address of the mobile 1549 node does not change during handover, RSVP reservations would follow 1550 the mobile node movement. 1552 A.5. RSVP Proxies for Reservations in the presence of IPsec Gateways 1554 [I-D.ietf-tsvwg-vpn-signaled-preemption] discusses how resource 1555 reservation can be supported end-to-end in a nested VPN environment. 1556 At each VPN level, VPN Routers behave as [RFC4301] security gateways 1557 between a plaintext domain and a cyphertext domain. To achieve end- 1558 to-end resource reservation, the VPN Routers process RSVP signaling 1559 on the plaintext side, perform aggregation of plaintext reservations, 1560 and maintain the corresponding aggregate RSVP reservations on the 1561 cyphertext side. Each aggregate reservation is established on behalf 1562 of multiple encrypted end-to-end sessions sharing the same ingress 1563 and egress VPN Routers. These aggregate reservations can be as 1564 specified in [RFC3175] or [RFC4860]. 1566 Section 3 of [I-D.ietf-tsvwg-vpn-signaled-preemption] discusses the 1567 necessary data flows within a VPN Router to achieve the behavior 1568 described in the previous paragraph. Two mechanisms are described to 1569 achieve such data flows. Section 3.1 presents the case where the VPN 1570 Router carries data across the cryptographic boundary. Section 3.2 1571 discusses the case where the VPN router uses a Network-Guard. 1573 Where such mechanisms are not supported by the VPN Routers, the 1574 approach for end-to-end reservation presented in 1575 [I-D.ietf-tsvwg-vpn-signaled-preemption] cannot be deployed. An 1576 alternative approach to support resource reservations within the 1577 cyphertext core is to use the "Application_Entity-Controlled Proxy" 1578 approach (as defined in Section 4.5) in the following way: 1580 o the RSVP Proxies are located inside the cyphertext domain and use 1581 aggregate RSVP reservations, 1583 o the Application Entity exchange application level signaling with 1584 the end systems in the plaintext domain, 1586 o the Application Entity controls the RSVP Proxies in the cyphertext 1587 domain via an RSVP Proxy control interface 1589 This is illustrated in Figure 17 in the case where the application is 1590 SIP-based multimedia communications. 1592 |-------| |-------| 1593 |SIP |///////////////////\\\\\\\\\\\\\\\\\|SIP | 1594 /|Server/| |Server/|\ 1595 / |Proxy | |Proxy | \ 1596 / |-------| |-------| \ 1597 / ^ \\ // ^ \ 1598 / ^ \\ // ^ \ 1599 / ^ \\ // ^ \ 1600 |---| |------| |--------| *** *** |--------| |------| |---| 1601 | S |---|IPsec |--| ARSVP |---*r*---*r*---| ARSVP |--|IPsec |---| R | 1602 |---| | GW | | Sender | *** *** |Receiver| | GW | |---| 1603 |------| | Proxy | | Proxy | |------| 1604 |--------| |--------| 1606 ***PT*****> **********************CT****************> ****PT***> 1608 =====> =====> 1609 =====ARSVP======> 1611 |----| RSVP-capable |----| RSVP-capable *** 1612 | S | Sender | R | Receiver *r* regular RSVP 1613 |----| |----| *** router 1615 |------| 1616 |IPsec | IPsec security gateway 1617 | GW | 1618 |------| 1620 ARSVP Aggregate RSVP 1622 ***> media flow 1624 ==> segment of flow path protected by RSVP reservation 1626 / \ SIP signaling 1628 ^ Network management interface between SIP Server/Proxy 1629 and IPsec security gateway 1631 // control interface between SIP Server/Proxy and ARSVP Proxy 1633 PT Plaintext network 1635 CT Cyphertext network 1637 Figure 17: RSVP Proxies for Reservations in the Presence of IPsec 1638 Gateways 1640 Where the sender and receiver are RSVP capable, they may also use 1641 RSVP signaling. This achieves resource reservation on the plaintext 1642 segments of the end-to-end i.e. : 1644 o from the sender to the ingress IPsec gateway and 1646 o from the egress IPsec gateway to the receiver. 1648 In this use case, because the VPN Routers do not support any RSVP 1649 specific mechanism, the end-to-end RSVP signaling is effectively 1650 hidden by the IPsec gateways on the cyphertext segment of the end-to- 1651 end path. 1653 As with the "Application_Entity-Controlled Proxy" approach (defined 1654 in Section 4.5), the solution here for synchronizing RSVP signaling 1655 with application-level signaling is to rely on an application-level 1656 signaling device that controls an on-path RSVP Proxy function. 1657 However, in the present use case, the RSVP Proxies are a component of 1658 a cyphertext network where all user (bearer) traffic is IPsec 1659 encrypted. This has a number of implications including the 1660 following: 1662 1. encrypted flows can not be identified in the cyphertext domain so 1663 that network nodes can only classify traffic based on IP address 1664 and DiffServ Code Points (DSCPs). As a result, only aggregate 1665 RSVP reservations (such as those specified in [RFC3175] or 1666 [RFC4860] ) can be used. This is similar to 1667 [I-D.ietf-tsvwg-vpn-signaled-preemption]. 1669 2. Determining the RSVP Sender proxy and RSVP receiver Proxy to be 1670 used for aggregation of a given flow from sender to receiver 1671 creates a number of challenges. Details on how this may be 1672 achieved are beyond the scope of this document. We observe that, 1673 as illustrated in Figure 17, this may be facilitated by a network 1674 management interface between the application entity and the IPsec 1675 gateways. For example, this interface may be used by the 1676 application entity to obtain information about which IPsec 1677 gateway is on the path of a given end-to-end flow. Then, the 1678 application entity may maintain awareness of which RSVP Proxy is 1679 on the cyphertext path between a given pair of IPsec gateways. 1680 How such awareness is achieved is beyond the scope of this 1681 document. We simply observe that such awareness can be easily 1682 achieved through simple configuration in the particular case 1683 where a single (physical or logical) RSVP Proxy is fronting a 1684 given IPsec gateway. We also observe that when awareness of the 1685 RSVP Receiver Proxy for a particular egress IPsec gateway (or 1686 end-to-end flow) is not available, the aggregate reservation may 1687 be signaled by the RSVP Sender Proxy to the destination address 1688 of the egress IPsec gateway and then proxied by the RSVP Receiver 1689 Proxy. 1691 Different flavors of operations are possible in terms of aggregate 1692 reservation sizing. For example, the application entity can initiate 1693 an aggregate reservation of fixed size a priori and then simply keep 1694 count of the bandwidth used by sessions and reject sessions that 1695 would result in excess usage of an aggregate reservation. The 1696 application entity could also re-size the aggregate reservations on a 1697 session by session basis. Alternatively, the application entity 1698 could re-size the aggregate reservations in step increments typically 1699 corresponding to the bandwidth requirement of multiple sessions. 1701 Authors' Addresses 1703 Francois Le Faucheur 1704 Cisco Systems 1705 Greenside, 400 Avenue de Roumanille 1706 Sophia Antipolis 06410 1707 France 1709 Phone: +33 4 97 23 26 19 1710 Email: flefauch@cisco.com 1712 Jukka Manner 1713 University of Helsinki 1714 P.O. Box 68 1715 University of Helsinki FIN-00014 University of Helsinki 1716 Finland 1718 Phone: +358 9 191 51298 1719 Email: jmanner@cs.helsinki.fi 1720 URI: http://www.cs.helsinki.fi/u/jmanner/ 1722 Dan Wing 1723 Cisco Systems 1724 170 West Tasman Drive 1725 San Jose, CA 95134 1726 United States 1728 Email: dwing@cisco.com 1729 Allan Guillou 1730 Neuf Cegetel 1731 40-42 Quai du Point du Jour 1732 Boulogne-Billancourt, 92659 1733 France 1735 Email: allan.guillou@neufcegetel.fr 1737 Full Copyright Statement 1739 Copyright (C) The IETF Trust (2007). 1741 This document is subject to the rights, licenses and restrictions 1742 contained in BCP 78, and except as set forth therein, the authors 1743 retain all their rights. 1745 This document and the information contained herein are provided on an 1746 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1747 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1748 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1749 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1750 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1751 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1753 Intellectual Property 1755 The IETF takes no position regarding the validity or scope of any 1756 Intellectual Property Rights or other rights that might be claimed to 1757 pertain to the implementation or use of the technology described in 1758 this document or the extent to which any license under such rights 1759 might or might not be available; nor does it represent that it has 1760 made any independent effort to identify any such rights. Information 1761 on the procedures with respect to rights in RFC documents can be 1762 found in BCP 78 and BCP 79. 1764 Copies of IPR disclosures made to the IETF Secretariat and any 1765 assurances of licenses to be made available, or the result of an 1766 attempt made to obtain a general license or permission for the use of 1767 such proprietary rights by implementers or users of this 1768 specification can be obtained from the IETF on-line IPR repository at 1769 http://www.ietf.org/ipr. 1771 The IETF invites any interested party to bring to its attention any 1772 copyrights, patents or patent applications, or other proprietary 1773 rights that may cover technology that may be required to implement 1774 this standard. Please address the information to the IETF at 1775 ietf-ipr@ietf.org. 1777 Acknowledgment 1779 Funding for the RFC Editor function is provided by the IETF 1780 Administrative Support Activity (IASA).