idnits 2.17.1 draft-ietf-tsvwg-rsvp-proxy-approaches-00.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 1424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1448. 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 (February 24, 2007) is 6271 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-05 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-13 -- No information found for draft-ietf-tsvwg-rsvp-proxy-proto - is the name correct? -- 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 (~~), 3 warnings (==), 11 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: August 28, 2007 University of Helsinki 6 D. Wing 7 Cisco 8 A. Guillou 9 Neuf 10 February 24, 2007 12 RSVP Proxy Approaches 13 draft-ietf-tsvwg-rsvp-proxy-approaches-00.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 August 28, 2007. 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 QoS required by certain 48 flows. With conventional RSVP, both the data sender and receiver of 49 a given flow take part in RSVP signaling. Yet, there are many use 50 cases where resource reservation is required, but the receiver, the 51 sender, or both, is not RSVP-capable. This document presents RSVP 52 Proxy behaviors allowing RSVP routers to perform RSVP signaling on 53 behalf of a receiver or a sender that is not RSVP-capable. This 54 allows resource reservations to be established on parts of the end- 55 to-end path. This document reviews conceptual approaches for 56 deploying RSVP Proxies and discusses how those can synchronize RSVP 57 reservations with application requirements. This document also 58 points out where extensions to RSVP (or to other protocols) may be 59 needed for deployment of a given RSVP Proxy approach. However, such 60 extensions are outside the scope of this document. Finally, 61 practical use cases for RSVP Proxy are described. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 4 68 2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 5 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4. RSVP Proxy Approaches . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Path-Triggered Receiver Proxy . . . . . . . . . . . . . . 7 72 4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 10 73 4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 13 74 4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 15 75 4.5. Application-Signaling-Triggered On-Path Proxy . . . . . . 17 76 4.6. Application-Signaling-Triggered Off-Path Source Proxy . . 21 77 4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 23 78 4.8. Other Approaches . . . . . . . . . . . . . . . . . . . . . 24 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 82 8. Informative References . . . . . . . . . . . . . . . . . . . . 25 83 Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 27 84 A.1. RSVP-based VoD CAC in Broadband Aggregation Networks . . . 27 85 A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 31 86 A.3. RSVP-based Voice CAC in TSP Domain . . . . . . . . . . . . 33 87 A.4. RSVP Proxies for Mobile Access Networks . . . . . . . . . 34 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 89 Intellectual Property and Copyright Statements . . . . . . . . . . 37 91 1. Introduction 93 Guaranteed QoS for some applications with tight QoS requirements may 94 be achieved by reserving resources in each node on the end-to-end 95 path. The main IETF protocol for these resource reservations is 96 RSVP, specified in [RFC2205]. RSVP does not require that all 97 intermediate nodes support RSVP, however it assumes that both the 98 sender and the receiver of the data flow support RSVP. There are 99 environments where it would be useful to be able to reserve resources 100 for a flow on at least a subset of the flow path even when the sender 101 or the receiver (or both) is not RSVP capable. 103 Since the data sender or receiver may be unaware of RSVP, there are 104 two scenarios. In the first case, an entity in the network must 105 operate on behalf of the data sender, generate an RSVP Path message, 106 and eventually receive, process and sink a Resv message. We refer to 107 this entity as the RSVP Sender Proxy. In the latter case, an entity 108 in the network must receive a Path message sent by a data sender (or 109 by an RSVP Sender Proxy), and reply to it with a Resv message on 110 behalf of the data receiver(s). We refer to this entity as the RSVP 111 Receiver Proxy. 113 The flow sender and receiver generally have at least some (if not 114 full) awareness of the application producing or consuming that flow. 115 Hence, the sender and receiver are in a natural position to 116 synchronize the establishment, maintenance and tear down of the RSVP 117 reservation with the application requirements and to determine the 118 characteristics of the reservation (bandwidth, QoS service,...) which 119 best match the application requirements. For example, before 120 completing the establishment of a multimedia session, the endpoints 121 may decide to establish RSVP reservations for the corresponding 122 flows. Similarly, when the multimedia session is torn down, the 123 endpoints may decide to tear down the corresponding RSVP 124 reservations. For example, [RFC3312] discusses how RSVP reservations 125 can be very tightly synchronised by SIP endpoints with SIP session 126 control and SIP signaling. 128 When RSVP reservation establishment, maintenance and tear down is to 129 be handled by RSVP Proxy devices on behalf of an RSVP sender or 130 receiver, a key challenge for the RSVP proxy is to determine when the 131 RSVP reservations need to be established, maintained and torn down 132 and to determine what are the characteristics (bandwidth, QoS 133 Service,...) of the required RSVP reservations matching the 134 application requirements. We refer to this problem as the 135 synchronization of RSVP reservations with application level 136 requirements. 138 The IETF Next Steps in Signaling (NSIS) working group is designing, 139 as one their many charter items, a new QoS signaling protocol. This 140 scheme already includes the notion of proxy operation, and 141 terminating QoS signaling on nodes that are not the actual data 142 senders or receivers. This is the same concept as the proxy 143 operation for RSVP discussed in this document. One difference though 144 is that the NSIS framework does not consider multicast resource 145 reservations, which RSVP provides today. 147 The next two sections introduce the notion of RSVP Sender Proxy and 148 RSVP receiver Proxy. The following section defines useful 149 terminology. The subsequent section then presents several 150 fundamental RSVP Proxy approaches insisting on how they achieve the 151 synchronization of RSVP reservations with application level 152 requirements. Appendix A includes more detailed use cases for the 153 proxies in various deployment environments. 155 2. RSVP Proxy Behaviors 157 This section discusses the two types of proxies; the RSVP Sender 158 Proxy operating on behalf of data senders, and the RSVP Receiver 159 Proxy operating for data receivers. The concepts presented in this 160 document are not meant to replace the standard RSVP and end-to-end 161 RSVP reservations are still expected to be used whenever possible. 162 However, RSVP Proxies are intended to facilitate RSVP deployment 163 where end-to-end RSVP signaling is not possible. 165 2.1. RSVP Receiver Proxy 167 With conventional RSVP operations, RSVP reservations are controlled 168 by receivers of data. After a data sender has sent an RSVP Path 169 message towards the intended recipient(s), each recipient that 170 requires a reservation generates a Resv message. If, however, a data 171 receiver is not running the RSVP protocol, the last hop RSVP router 172 will still send the Path message to the data receiver, which will 173 silently drop this message as an IP packet with an unknown protocol 174 number. 176 In order for reservations to be made in such a scenario, one of the 177 RSVP routers on the data path must somehow know that the data 178 receiver will not be participating in the resource reservation 179 signaling. This RSVP router should, thus, perform RSVP Receiver 180 Proxy functionality on behalf of the data receiver. This is 181 illustrated in the figure below. Various mechanisms by which the 182 RSVP proxy router can gain the required information are discussed 183 later in the document. 185 |----| *** *** |----------| |----| 186 | S |---------*r*----------*r*---------| RSVP |----------| R | 187 |----| *** *** | Receiver | |----| 188 | Proxy | 189 |----------| 191 *************************************************************> 193 ===================RSVP======================> 195 |----| RSVP-capable |----| non-RSVP-capable *** 196 | S | Sender | R | Receiver *r* regular RSVP 197 |----| |----| *** router 199 ***> unidirectional media flow 201 ==> segment of flow path protected by RSVP reservation 203 Figure 1: RSVP Receiver Proxy 205 2.2. RSVP Sender Proxy 207 With conventional RSVP operations, If a data sender is not running 208 the RSVP protocol, a resource reservation can not be set up; a data 209 receiver can not alone reserve resources without Path messages first 210 being sent. Thus, even if the data receiver is running RSVP, it 211 still needs some node on the data path to send a Path message towards 212 the data receiver. 214 In that case, in a similar manner to the RSVP Receiver Proxy 215 described before, an RSVP node on the data path must somehow know 216 that it should generate a Path message for setting up a resource 217 reservation. This case is more complex than the Receiver Proxy, 218 since the RSVP Sender Proxy must be able to generate all the 219 information in the Path message (such as the Sender TSpec) without 220 the benefit of having previously seen any RSVP messages. An RSVP 221 Receiver Proxy, by contrast only needs to formulate an appropriate 222 Resv message in response to an incoming Path message. Mechanisms to 223 operate an RSVP Sender Proxy are discussed later in this document. 225 |----| |----------| *** *** |----| 226 | S |---------| RSVP |---------*r*----------*r*----------| R | 227 |----| | Sender | *** *** |----| 228 | Proxy | 229 |----------| 231 *************************************************************> 233 ================RSVP======================> 235 |----| non-RSVP-capable |----| RSVP-capable *** 236 | S | Sender | R | Receiver *r* regular RSVP 237 |----| |----| *** router 239 ***> unidirectional media flow 241 ==> segment of flow path protected by RSVP reservation 243 Figure 2: RSVP Sender Proxy 245 3. Terminology 247 On-Path: located on the datapath of the actual flow of data from the 248 application (regardless of where it is located on the application 249 level signaling path) 251 Off-Path: not On-Path 253 RSVP-capable (or RSVP-aware): which supports the RSVP protocol as per 254 [RFC2205] 256 RSVP Receiver Proxy: an RSVP capable router performing, on behalf of 257 a receiver, the RSVP operations which would normally be performed by 258 an RSVP-capable receiver if end-to-end RSVP signaling was used. Note 259 that while RSVP is used upstream of the RSVP Receiver Proxy, RSVP is 260 not used downstream of the RSVP Receiver Proxy. 262 RSVP Sender Proxy: an RSVP capable router performing, on behalf of a 263 sender, the RSVP operations which would normally be performed by an 264 RSVP-capable sender if end-to-end RSVP signaling was used. Note that 265 while RSVP is used downstream of the RSVP Sender Proxy, RSVP is not 266 used upstream of the RSVP Sender Proxy. 268 Regular RSVP Router: an RSVP-capable router which is not behaving as 269 a RSVP Receiver Proxy nor as a RSVP Sender Proxy. 271 Note that the roles of RSVP Receiver Proxy, RSVP Sender Proxy, 272 Regular RSVP Router are all relative to one unidirectional flow. A 273 given router may act as the RSVP Receiver Proxy for a flow, as the 274 RSVP Sender Proxy for another flow and as a Regular RSVP router for 275 yet another flow. 277 Application level signaling: signaling between entities operating 278 above the IP layer and which are aware of the QoS requirements for 279 actual media flows. SIP and RTSP are examples of application level 280 signaling protocol. RSVP is clearly not an application level 281 signaling. 283 4. RSVP Proxy Approaches 285 This section specifies several fundamental RSVP Proxy approaches. 287 4.1. Path-Triggered Receiver Proxy 289 In this approach, it is assumed that the sender is RSVP capable and 290 takes full care of the synchronisation between application 291 requirements and RSVP reservations. With this approach, the RSVP 292 Receiver Proxy uses the RSVP Path messages generated by the sender as 293 the cue for establishing the RSVP reservation on behalf of the 294 receiver. The RSVP Receiver Proxy is effectively acting as a slave 295 making reservations (on behalf of the receiver) under the sender's 296 control. This changes somewhat the usual RSVP reservation model 297 where reservations are normally controlled by receivers. Such a 298 change greatly facilitates operations in the scenario of interest 299 here, which is where the receiver is not RSVP capable. Indeed it 300 allows the RSVP Receiver Proxy to remain application unaware by 301 taking advantage of the application awareness and RSVP awareness of 302 the sender. 304 With the Path-Triggered RSVP Receiver Proxy approach, the RSVP router 305 may be configured to use receipt of a regular RSVP Path message as 306 the trigger for RSVP Receiver Proxy behavior. 308 On receipt of the RSVP Path message, the RSVP Receiver Proxy: 310 1. establishes the RSVP Path state as per regular RSVP processing 312 2. identifies the downstream interface towards the receiver 314 3. sinks the Path message 315 4. behaves as if a Resv message (whose details are discussed below) 316 was received on the downstream interface. This includes 317 performing admission control on the downstream interface, 318 establishing a Resv state (in case of successful admission 319 control) and forwarding the Resv message upstream, sending 320 periodic refreshes of the Resv message and tearing down the 321 reservation if the Path state is torn down. 323 In order to build the Resv message, the RSVP Receiver Proxy can take 324 into account information received in the Path message. For example, 325 the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv 326 message which mirrors the SENDER_TSPEC object in the received Path 327 message. 329 Operation of the Path-Triggered Receiver Proxy in the case of a 330 successful reservation is illustrated in the Figure below. 332 |----| *** *** |----------| |----| 333 | S |---------*r*----------*r*---------| RSVP |----------| R | 334 |----| *** *** | Receiver | |----| 335 | Proxy | 336 |----------| 338 *************************************************************> 340 ===================RSVP======================> 342 ---Path---> ----Path----> ---Path----> 344 <--Resv---> <---Resv----- <--Resv---- 346 |----| RSVP-capable |----| Non-RSCP-capable *** 347 | S | Sender | R | Receiver *r* regular RSVP 348 |----| |----| *** router 350 ***> media flow 352 ==> segment of flow path protected by RSVP reservation 354 Figure 3: Path-Triggered RSVP Receiver Proxy 356 In case the reservation establishment is rejected (for example 357 because of an admission control failure on a regular RSVP router on 358 the path between the RSVP-capable sender and the RSVP Receiver 359 Proxy), a ResvErr message will be generated as per conventional RSVP 360 operations and will travel downstream towards the RSVP Receiver 361 Proxy. While this ensures that the RSVP Receiver Proxy is aware of 362 the reservation failure, conventional RSVP procedures do not cater 363 for notification of the sender of the reservation failure. Operation 364 of the Path-Triggered RSVP Receiver Proxy in the case of an admission 365 control failure is illustrated in the Figure below. 367 |----| *** *** |----------| |----| 368 | S |---------*r*----------*r*---------| RSVP |----------| R | 369 |----| *** *** | Receiver | |----| 370 | Proxy | 371 |----------| 373 *************************************************************> 375 ===================RSVP======================> 377 ---Path---> ----Path----> ---Path----> 379 <---Resv----- <--Resv------ 381 ---ResvErr---> --ResvErr---> 383 |----| RSVP-capable |----| Non-RSCP-capable *** 384 | S | Sender | R | Receiver *r* regular RSVP 385 |----| |----| *** router 387 ***> media flow 389 ==> segment of flow path protected by RSVP reservation 391 Figure 4: Path-Triggered RSVP Receiver Proxy with Failure 393 Since, as explained above, in this scenario involving the RSVP 394 Receiver Proxy, synchronisation between application and RSVP 395 reservation is generally performed by the sender, notifying the 396 sender of reservation failure is needed. 397 [I-D.ietf-tsvwg-rsvp-proxy-proto] specifies RSVP extensions allowing 398 such sender notification in case of reservation failure. 400 4.2. Path-Triggered Sender Proxy for Reverse Direction 402 In this approach, it is assumed that one endpoint is RSVP capable and 403 takes full care of the synchronisation between application 404 requirements and RSVP reservations. This endpoint is the sender for 405 one flow direction (which we refer to as the "forward" direction) and 406 is the receiver for the flow in the opposite direction (which we 407 refer to as the "reverse" direction). 409 With the Path-Triggered Sender Proxy for Reverse Direction approach, 410 the RSVP Proxy uses the RSVP signaling generated by the sender as the 411 cue for initiating RSVP signaling for the reservation in the reverse 412 direction. Thus, the RSVP Proxy is effectively acting as a Sender 413 Proxy for the reverse direction under the control of the sender for 414 the forward direction. Note that this assumes a degree of symmetry 415 for the two directions of the flow (as is currently typical for IP 416 telephony, for example). 418 This is illustrated in the Figure below. 420 |----| *** *** |----------| |----| 421 | E |---------*r*----------*r*---------| RSVP |----------| E | 422 |----| *** *** | Sender | |----| 423 | Proxy | 424 |----------| 426 *************************************************************> 428 <===================RSVP====================== 430 ---Path---> ----Path----> ---Path----> 432 <--Path---> <---Path----- <--Path---- 434 ---Resv---> ----Resv----> ---Resv----> 436 |----| *** 437 | E | Endpoint *r* regular RSVP 438 |----| *** router 440 ***> media flow 442 ==> segment of flow path protected by RSVP reservation 443 in reverse direction 445 Figure 5: Path-Triggered Sender Proxy for Reverse Direction 447 Of course, the RSVP Proxy may simultaneously (and typically will) 448 also act as the Path-Triggered Receiver Proxy for the forward 449 direction, as defined in Section 4.1. Such an approach is most 450 useful in situations involving RSVP reservations in both directions 451 for symmetric flows. This is illustrated in the Figure below 452 |----| *** *** |----------| |----| 453 | E |---------*r*----------*r*---------| RSVP |----------| E | 454 |----| *** *** | Receiver | |----| 455 | & Sender | 456 | Proxy | 457 |----------| 459 *************************************************************> 461 <===================RSVP=====================> 463 ---Path---> ----Path----> ---Path----> 465 <--Resv---> <---Resv----- <--Resv---- 467 <--Path---> <---Path----- <--Path---- 469 ---Resv---> ----Resv----> ---Resv----> 471 |----| *** 472 | E | Endpoint *r* regular RSVP 473 |----| *** router 475 <***> media flow 477 <==> segment of flow path protected by RSVP reservation 478 in forward and in reverse direction 480 Figure 6: Path Triggered Receiver & Sender Proxy 482 With the Path-Triggered Sender Proxy for Reverse Direction approach, 483 the RSVP router may be configurable to use receipt of a regular RSVP 484 Path message as the trigger for Sender Proxy for Reverse Direction 485 behavior. 487 On receipt of the RSVP Path message for the forward direction, the 488 RSVP Sender Receiver Proxy : 490 1. sinks the Path message 492 2. behaves as if a Path message for reverse direction (whose details 493 are discussed below) had been received by the Sender Proxy. This 494 includes establishing the corresponding Path state, forwarding 495 the Path message downstream, sending periodic refreshes of the 496 Path message and tearing down the Path in reverse direction when 497 the Path state in forward direction is torn down. 499 In order to build the Path message for the reverse direction, the 500 RSVP Sender Proxy can take into account information in the received 501 Path message for the forward direction. For example, the RSVP Sender 502 Proxy may mirror the SENDER_TSPEC object in the received Path 503 message. 505 We observe that this approach does not require any extensions to the 506 existing RSVP protocol. 508 4.3. Inspection-Triggered Proxy 510 In this approach, it is assumed that the RSVP Proxy device is on the 511 datapath of "packets of interest", that it can inspect such packets 512 on the fly as they transit through it, and that it can infer 513 information from these packets of interest to determine what RSVP 514 reservations need to be established, when and with what 515 characteristics (possibly also using some configured information). 517 One example of "packets of interest" could be application level 518 signaling. An RSVP Proxy device capable of inspecting SIP signaling 519 for multimedia session or RTSP signaling for Video streaming, can 520 obtain from such signaling information about when a multimedia 521 session is up or when a Video is going to be streamed. It can also 522 identify the addresses and ports of senders and receivers and can 523 determine the bandwidth of the corresponding flows. Thus, such an 524 RSVP Proxy device can determine all necessary information to 525 synchronise RSVP reservations to application requirements. This is 526 illustrated in the Figure below. 528 |-------------| 529 | Application | 530 | Signaling | 531 | Entity | 532 |-------------| 533 // \\ 534 // \\ 535 // \\ 536 538 |----| |--------| *** |--------| |----| 539 | E |--------| RSVP |------*r*--------| RSVP |----------| E | 540 |----| | Proxy | *** | Proxy | |----| 541 |--------| |--------| 543 <************************************************************> 545 <=========RSVP=============> 547 |----| 548 | E | End system (sender, or receiver, or both) 549 |----| 551 *** 552 *r* Regular RSVP router 553 *** 555 application level signaling 557 <***> media flow 559 <==> segment of flow path protected by RSVP reservation 561 Figure 7: Inspection-Triggered RSVP Proxy 563 Another example of "packets of interest" could be packets belonging 564 to the application flow itself (e.g. media packets). An RSVP Proxy 565 device capable of detecting the transit of packets from a particular 566 flow, can attempt to establish a reservation corresponding to that 567 flow. Characteristics of the reservation may be derived from 568 configuration, flow measurement or a combination of those. 570 Note however, that in case of reservation failure, the inspection- 571 triggered RSVP Proxy does not have a direct mechanism for notifying 572 the application (since it is not participating itself actively in 573 application signaling) so that the application takes appropriate 574 action (for example terminate the corresponding session). To 575 mitigate this problem, the inspection-triggered RSVP Proxy may mark 576 differently the DSCP of flows for which an RSVP reservation has been 577 successfully proxied from the flows for which a reservation is not in 578 place. In some situations, the Inspection-Triggered Proxy might be 579 able to modify the "packets of interest" (e.g. application signaling 580 messages) to convey some hint to applications that the corresponding 581 flows cannot be guaranteed by RSVP reservations. 583 With the inspection-triggered Proxy approach, the RSVP Receiver Proxy 584 is effectively required to attempt to build application awareness by 585 traffic inspection and then is somewhat limited in the actions in can 586 take in case of reservation failure. However, this may be a useful 587 approach in some environments. Note also that this approach does not 588 require any change to the RSVP protocol. 590 With the "Inspection-Triggered" RSVP Proxy approach, the RSVP router 591 may be configurable to use and interpret some specific "packets of 592 interest" as the trigger for RSVP Receiver Proxy behavior. 594 4.4. STUN-Triggered Proxy 596 In this approach, the RSVP Proxy entity takes advantage of the 597 application awareness provided by the STUN signaling to synchronise 598 RSVP reservations with application requirements. The STUN signaling 599 is sent from endpoint to endpoint. This is illustrated in the figure 600 below. 602 |---------| 603 | SIP | 604 | Server | 605 |---------| 606 // \\ 607 // \\ 608 // \\ 609 // \\ 610 // \\ 611 |----| |--------| *** |--------| |----| 612 | E |--------| RSVP |------*r*--------| RSVP |----------| E | 613 |----| | Proxy | *** | Proxy | |----| 614 |--------| |--------| 616 <**************************************************************> 618 <=========RSVP=============> 620 |----| 621 | E | End system (sender, or receiver, or both) also STUN Clients 622 |----| 624 *** 625 *r* Regular RSVP router 626 *** 628 <***> STUN message flow and RTP media flow (over same UDP ports) 630 <==> segment of flow path protected by RSVP reservation 632 // signaling 634 Figure 8: STUN-Triggered Proxy 636 In this approach, a STUN [I-D.ietf-behave-rfc3489bis] message 637 triggers the RSVP proxy. Using a STUN message eases the RSVP proxy 638 agent's computational burden because it need only look for STUN 639 messages rather than maintain state of all flows. More importantly, 640 the STUN message can also include a STUN attribute describing the 641 bandwidth and describing the application requesting the flow, which 642 allows the RSVP proxy agent to authorize an appropriately-sized 643 reservation for each flow. 645 For unicast flows, [I-D.ietf-mmusic-ice] is an already widely-adopted 646 emerging standard for NAT traversal. For our purposes, we are not 647 interested in its NAT traversal capabilities. Rather, ICE's useful 648 characteristic is its connectivity check -- the exchange of STUN 649 Binding Request messages between hosts to verify connectivity (see 650 Connectivity Check Usage in [I-D.ietf-behave-rfc3489bis]). By 651 including new STUN attributes in those messages an RSVP proxy agent 652 could perform its functions more effectively. Additionally, the RSVP 653 proxy agent can inform endpoints of an RSVP reservation failure by 654 dropping the ICE connectivity check message. This provides very 655 RSVP-like call admission control and signaling to the endpoints, 656 without implementing RSVP on the endpoints. 658 For multicast flows (or certain kinds of unicast flows that don't or 659 can't use ICE), a STUN Indication message 660 [I-D.ietf-behave-rfc3489bis] could be used for similar purposes. The 661 STUN Indication message is not acknowledged by its receiver and has 662 the same scalability as the underlying multicast flow itself. 664 The corresponding extensions to ICE and STUN for such a STUN- 665 triggered RSVP Proxy approach are beyond the scope of this document. 666 They may be defined in the future in a separate document. 668 4.5. Application-Signaling-Triggered On-Path Proxy 670 In this approach, it is assumed that an entity involved in the 671 application level signaling controls an RSVP Proxy device which is 672 located in the datapath of the application flows (i.e. "on-path"). 673 In this case, the RSVP Proxy entity does not attempt to understand 674 the application reservation requirements, but instead is instructed 675 by the entity participating in application level signaling to 676 establish, maintain and tear down reservations as needed by the 677 application flows. In other words, with this approach, the solution 678 for synchronising RSVP signaling with application-level signaling is 679 to rely on an application-level signaling entity which controls an 680 RSVP Proxy function that sits in the flow datapath. 682 In some instantiations, the application-level signaling entity may be 683 collocated with the on-path RSVP Proxy device. The figure below 684 illustrates such an environment in the case where the application- 685 level signaling protocol is SIP. 687 |--------| |--------| 688 -----------|SIP |----------------|SIP |---------- 689 / |Server/ | |Server/ | \ 690 / |Proxy | |Server/ | \ 691 |----| |--------| *** |--------| |----| 692 | E |-----------| Bearer |------*r*-------| Bearer |----------| E | 693 |----| | Path | *** | Path | |----| 694 | Entity | | Entity | 695 | + | | + | 696 | RSVP | | RSVP | 697 | Proxy | | Proxy | 698 |--------| |--------| 700 <******************> <***********************> <***************> 702 <=========RSVP=============> 704 |----| 705 | E | End system (sender, or receiver, or both) 706 |----| 708 *** 709 *r* Regular RSVP router 710 *** 712 <***> media flow 714 <==> segment of flow path protected by RSVP reservation 716 / SIP signaling 718 Figure 9: Application-Signaling-Triggered On-Path Proxy 720 This RSVP Proxy approach does not require any protocol extensions. 721 We also observe that when multiple sessions are to be established 722 between two given such RSVP Proxy, the RSVP Proxy have the option to 723 establish aggregate RSVP reservations (as defined in ([RFC3175] or 724 [I-D.ietf-tsvwg-rsvp-ipsec]) for a group of sessions, instead of 725 establishing one RSVP reservation per session. 727 Consider an environment involving decomposed Session Border 728 Controllers (SBCs). The SBC function may be broken up into a 729 Signaling Border Element (SBE) and Datapath Border Elements (DBEs). 730 The DBEs are remotely controled by the SBE. This may be achieved 731 using a protocol like [RFC3525]. Where admission control and 732 bandwidth reservation is required between the SBEs for QoS guarantees 733 of the sessions, the SBE could implement RSVP Proxy functionality. 735 In that case, the application-level signaling entity (the SBE) is 736 remotely located from the on-path RSVP Proxy devices (located in the 737 DBEs). Such an environment is illustrated in the Figure below. 739 |---------| 740 -----------------| SBE |------------------ 741 / | | \ 742 / |---------| \ 743 / // \\ \ 744 / // \\ \ 745 / // \\ \ 746 / // \\ \ 747 / // \\ \ 748 |----| |--------| *** |--------| |----| 749 | E |-----------| DBE |------*r*-------| DBE |----------| E | 750 |----| | | *** | | |----| 751 | + | | + | 752 | RSVP | | RSVP | 753 | Proxy | | Proxy | 754 |--------| |--------| 756 <******************> <***********************> <***************> 758 <=========RSVP=============> 760 |----| 761 | E | End system (sender, or receiver, or both) 762 |----| 764 *** 765 *r* Regular RSVP router 766 *** 768 SBE Signaling Border Element 769 DBE Datapath Border Element 770 SBE + DBE = decomposed Session Border Controller (decomposed SBC) 772 <***> media flow 774 <==> segment of flow path protected by RSVP reservation 776 / SIP signaling 778 // control interface between the SBE and DBE 780 Figure 10: Remote Signaling Border Element 782 This RSVP Proxy approach does not require any extension to the RSVP 783 protocol. However, it may require extensions to the protocol (e.g. 784 that may be based on [RFC3525]) used by the application level 785 signaling entity to control the remote on-path RSVP Proxy entities. 787 4.6. Application-Signaling-Triggered Off-Path Source Proxy 789 In this approach, it is assumed that an entity involved in the 790 application level signaling also behaves as the RSVP Source Proxy 791 device. However, since such an application level signaling entity is 792 generally not on the datapath of the actual application flows, the 793 RSVP messages need to be logically "tunnelled" between the off-path 794 RSVP Source Proxy and a router in the datapath and upstream of the 795 segment of the path to be protected by RSVP reservations. This is to 796 ensure that the RSVP messages follow the exact same path as the flow 797 they protect (as required by RSVP operations) on the segment of the 798 end-to-end path which is to be subject to RSVP reservations. 800 With this approach, the solution for synchronising RSVP signaling 801 with application-level signaling is to co-locale the RSVP Proxy 802 function with a (typically) off-path application-level signaling 803 entity and then "tunnel" the RSVP signaling towards the appropriate 804 router in the datapath. 806 The figure below illustrates such an environment. 808 |-------------| 809 --------------| Application |----------- 810 / | Signaling | \ 811 / | Entity + | \ 812 / | RSVP Sender | \ 813 / | Proxy | \ 814 / |-------------| \ 815 / /=/ \ 816 / /=/ \ 817 / /=/ \ 818 / /=/ \ 819 / /=/ \ 820 |----| |--------| *** |----| 821 | S |-----------| RSVP |-----------*r*----------------------| R | 822 |----| | Router | *** |----| 823 |--------| 825 ****************************************************************> 827 =========RSVP==============================> 829 |----| |----| *** 830 | S | Sender | R | Receiver *r* regular RSVP 831 |----| |----| *** router 833 <***> media flow 835 ==> segment of flow path protected by RSVP reservation 836 in forward direction 838 / Application level signaling 840 /*/ GRE-tunnelled RSVP (Path messages) 842 Figure 11: Application-Signaling-Triggered Off-Path Source Proxy 844 With the "Application-Triggered Off-Path Source Proxy" approach, the 845 RSVP Source Proxy : 847 o generates a Path message on behalf of the sender, corresponding to 848 the reservation needed by the application and maintains the 849 corresponding Path state. The Path message built by the Source 850 Proxy is exactly the same as would be built by the actual sender 851 (if it was RSVP capable), with one single exception which is that 852 the RSVP Sender Proxy put its own IP address as the RSVP Previous 853 Hop. In particular, it is recommended that the source address of 854 the Path message built by the RSVP Source Proxy be set to the IP 855 address of the sender (not of the Sender Proxy). This helps 856 ensuring that, in the presence of non-RSVP routers and of load- 857 balancing in the network where the load-balancing algorithm takes 858 into account the source IP address, the Path message generated by 859 the Sender Proxy follows the exact same path that the actual 860 stream sourced by the sender. 862 o encapsulates the Path message into a GRE tunnel whose destination 863 address is an RSVP Router sitting on the datapath for the flow 864 (and upstream of the segment which requires QoS guarantees via 865 RSVP reservation). 867 o processes the corresponding received RSVP messages (including Resv 868 messages) as per regular RSVP. 870 o synchronises the RSVP reservation state with application level 871 requirements and signaling. 873 Note that since the Off-Path Source Proxy encodes its own IP address 874 as the RSVP PHOP in the Path message, the RSVP Router terminating the 875 GRE tunnel naturally addresses all the RSVP messages travelling 876 upstream hop-by-hop (such as Resv messages) to the Off-Path Source 877 Proxy (without having to encapsulate those in a reverse-direction GRE 878 tunnel to the Off-Path Proxy). 880 This RSVP Proxy approach does not require any extension to the RSVP 881 protocol. It only requires tunneling of the downstream end-to-end 882 routed RSVP messages (in particular the Path messages) in a GRE 883 tunnel. 885 4.7. RSVP-Signaling-Triggered Proxy 887 An RSVP proxy can also be triggered and controlled through extended 888 RSVP signaling from the remote end that is RSVP-capable (and supports 889 these RSVP extensions for Proxy control). For example, an RSVP 890 capable sender could send a new or extended RSVP message explicitely 891 requesting an RSVP Proxy device on the path towards the receiver to 892 behave as an RSVP Receiver Proxy and also to trigger a reverse 893 direction reservation thus also behaving as a sender proxy. The new 894 or extended RSVP message sent by the sender could also include 895 attributes (e.g. bandwidth) for the reservations to be signaled by 896 the RSVP Proxy. 898 The challenges in these explicit signaling schemes are: 900 o How does the proxy differentiate between reservation requests that 901 must be proxied, from requests that should go end-to-end? 903 o How does the node sending the explicit messages know where the 904 proxy is located, e.g., an IP address of the proxy that should 905 reply to the signaling? 907 o How are sender and receiver proxy operations differentiated? 909 An example of such a mechanism is presented in 910 [I-D.manner-tsvwg-rsvp-proxy-sig]. This scheme is primarily targeted 911 to local access network reservations whereby an end host can request 912 resource reservations for both incoming and outgoing flows only over 913 the access network. This may be useful in environments where the 914 access network is typically the bottleneck while the core is 915 comparatively over-provisioned, as may be the case with a number of 916 radio access technologies. In this proposal, messages targeted to 917 the proxy are flagged with one bit in all RSVP message. Similarly, 918 all messages sent by the proxy back are marked. The use of one bit 919 allows differentiating between proxied and end-to-end reservations. 920 For triggering an RSVP receiver proxy, the sender of the data sends a 921 PATH message which is marked with the mentioned one bit. The 922 receiver proxy is located on the signaling and data path, eventually 923 gets the PATH message, and replies back with a RESV. A node triggers 924 an RSVP sender proxy with a new PATH_REQUEST message, which instructs 925 the proxy to send a PATH messages towards the triggering node. The 926 node then replies back with a RESV. More details can be found in 927 [I-D.manner-tsvwg-rsvp-proxy-sig]. 929 Such RSVP-Signaling-Triggered Proxy approaches require RSVP signaling 930 extensions which are outside the scope of the present document, 931 however they can provide more flexibility in the control of the Proxy 932 behavior (e.g. control of reverse reservation parameters). 934 4.8. Other Approaches 936 In some cases, having a full RSVP implementation running on an end 937 host can be seen to produce excessive overhead. In end-hosts that 938 are low in processing power and functionality, having an RSVP daemon 939 run and take care of the signaling may introduce unnecessary 940 overhead. One article [Kars01] proposes to create a remote API so 941 that the daemon would in fact run on the end-host's default router 942 and the end-host application would send its requests to that daemon. 943 Thus, we can have deployments, where an end host uses some 944 proprietary simple protocol to communicate with its pre-defined RSVP 945 router - a form of RSVP proxy. 947 5. Security Considerations 949 In the environments concerned by this document, RSVP messages are 950 used to control resource reservations on a segment of the end-to-end 951 path of flows. To ensure the integrity of the associated reservation 952 and admission control mechanisms, the mechanisms defined in 953 [RFC2747]] and [RFC3097] can be used. Those protect RSVP messages 954 integrity hop-by-hop and provide node authentication, thereby 955 protecting against corruption and spoofing of RSVP messages. 957 An important issue regarding the various types of proxy functionality 958 is authorization: which node is authorized to send messages on behalf 959 of the data sender or receiver, and how is the authorization 960 verified? RFC 3520 [RFC3520] presents a mechanism to include 961 authorization information within RSVP signaling messages. Subsequent 962 versions of this document will discuss in more details how such 963 mechanisms can be used to address security of RSVP Proxy approaches. 965 6. IANA Considerations 967 This document does not make any request to IANA registration. 969 7. Acknowledgments 971 This document benefited from earlier work on the concept of RSVP 972 Proxy including the one documented by Silvano Gai, Dinesh Dutt, 973 Nitsan Elfassy and Yoram Bernet. It also benefited from discussions 974 with Pratik Bose, Chris Christou and Michael Davenport. 976 8. Informative References 978 [I-D.ietf-behave-rfc3489bis] 979 Rosenberg, J., "Simple Traversal Underneath Network 980 Address Translators (NAT) (STUN)", 981 draft-ietf-behave-rfc3489bis-05 (work in progress), 982 October 2006. 984 [I-D.ietf-mmusic-ice] 985 Rosenberg, J., "Interactive Connectivity Establishment 986 (ICE): A Methodology for Network Address Translator (NAT) 987 Traversal for Offer/Answer Protocols", 988 draft-ietf-mmusic-ice-13 (work in progress), January 2007. 990 [I-D.ietf-tsvwg-rsvp-ipsec] 991 Le Faucheur, L., "Generic Aggregate Resource ReSerVation 992 Protocol (RSVP) Reservations", February 2007. 994 [I-D.ietf-tsvwg-rsvp-proxy-proto] 995 Le Faucheur, L., "RSVP Extensions For Path-Triggered RSVP 996 Receiver Proxy", February 2007. 998 [I-D.manner-tsvwg-rsvp-proxy-sig] 999 Manner, J., "Localized RSVP for Controlling RSVP Proxies", 1000 October 2006. 1002 [Kars01] Karsten, M., "Experimental Extensions to RSVP -- Remote 1003 Client and One-Pass Signalling", IWQoS Karlsruhe, Germany, 1004 2006. 1006 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1007 Services in the Internet Architecture: an Overview", 1008 RFC 1633, June 1994. 1010 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1011 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1012 Functional Specification", RFC 2205, September 1997. 1014 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1015 Services", RFC 2210, September 1997. 1017 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1018 and W. Weiss, "An Architecture for Differentiated 1019 Services", RFC 2475, December 1998. 1021 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1022 Authentication", RFC 2747, January 2000. 1024 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1025 and S. Molendini, "RSVP Refresh Overhead Reduction 1026 Extensions", RFC 2961, April 2001. 1028 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 1029 Authentication -- Updated Message Type Value", RFC 3097, 1030 April 2001. 1032 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1033 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 1034 RFC 3175, September 2001. 1036 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 1037 "Integration of Resource Management and Session Initiation 1038 Protocol (SIP)", RFC 3312, October 2002. 1040 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 1041 "Session Authorization Policy Element", RFC 3520, 1042 April 2003. 1044 [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, 1045 "Gateway Control Protocol Version 1", RFC 3525, June 2003. 1047 Appendix A. Use Cases for RSVP Proxies 1049 A.1. RSVP-based VoD CAC in Broadband Aggregation Networks 1051 As broadband services for residential are becoming more and more 1052 prevalent, next generation aggregation networks are being deployed in 1053 order to aggregate traffic from broadband users (whether attached via 1054 Digital Subscriber Line technology aka DSL, Fiber To The Home/Curb 1055 aka FTTx, Cable or other broadband access technology) and service 1056 providers core network or service delivery platforms. Video on 1057 Demand (VoD) services which may be offered to broadband users present 1058 significant capacity planning challenges for the aggregation network 1059 because each VoD stream requires significant dedicated sustained 1060 bandwidth (typically 2-4 Mb/s in Standard Definition TV and 8-12 Mb/s 1061 in High Definition TV), the VoD codec algorithms are very sensitive 1062 to packet loss and the load resulting from such services is very hard 1063 to predict (e.g. it can vary very suddenly with block-buster titles 1064 made available as well as with commercial offerings). As a result, 1065 transport of VoD streams on the aggregation network usually translate 1066 into a strong requirement for admission control, so that the quality 1067 of established VoD sessions can be protected at all times by 1068 rejecting the excessive session attempts during unpredictable peaks, 1069 during link or node failures, or combination of those factors. 1071 RSVP can be used in the aggregation network for admission control of 1072 the VoD sessions. However, since Customer Premises equipment such as 1073 Set Top Boxes (which behave as the receiver for VoD streams) often do 1074 not yet support RSVP, the last IP hop in the aggregation network can 1075 behave as an RSVP Receiver Proxy. This way, RSVP can be used between 1076 VoD Pumps and the Last IP hop in the Aggregation network to perform 1077 accurate admission control of VoD streams over the resources set 1078 aside for VoD in the aggregation network (typically a certain 1079 percentage of the bandwidth of any link). As VoD streams are 1080 unidirectional, a simple "Path-Triggered" RSVP Receiver Proxy (as 1081 described in Section 4.1) is all that is required in this use case. 1083 The Figure below illustrates operation of RSVP-based admission 1084 control of VoD sessions in an Aggregation network involving RSVP 1085 support on the VoD Pump (the senders) and RSVP Receiver Proxy on the 1086 last IP hop of the aggregation network. All the customer premises 1087 equipment remain RSVP unaware. 1089 |-------------| 1090 ----| VoD SRM |----------- 1091 / | | \ 1092 / | | \ 1093 / | | \ 1094 / | | \ 1095 / |-------------| \ 1096 / \ 1097 / \ 1098 / \ 1099 / \ 1100 / \ 1101 |----| |------| *** *** |--------| |-----| |---| 1102 | VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV 1103 |Pump| |Router| *** *** |Receiver| |-----| |---| 1104 |----| |------| |Proxy | 1105 |--------| 1107 <---Aggregation Net-------------> 1109 ******************************************************> 1111 ====================RSVP==============> 1113 SRM Systems Resource Manager 1115 *** |---| 1116 *r* regular RSVP |STB| Set Top Box 1117 *** router |---| 1119 <***> media flow 1121 ==> segment of flow path protected by RSVP reservation 1122 in forward direction 1124 / VoD Application level signaling 1126 Figure 12: VoD Use Case with Receiver Proxy 1128 In the case where the VoD Pumps are not RSVP-capable, an Application- 1129 Signaling-triggered Off-Path Source Proxy (as described in 1130 Section 4.6) can also be implemented on the VoD Controller or Systems 1131 Resource Manager (SRM) devices typically involved in VoD deployments. 1132 The Figure below illustrates operation of RSVP-based admission 1133 control of VoD sessions in an Aggregation network involving such 1134 Application-Signaling-triggered Off-Path Source Proxy on the SRM and 1135 RSVP Receiver Proxy on the Last IP hop of the aggregation network. 1136 All the customer premises equipment, as well as the VoD pumps, remain 1137 RSVP unaware. 1139 |-------------| 1140 ----| VoD SRM |----------- 1141 / | | \ 1142 / | + | \ 1143 / | RSVP Sender | \ 1144 / | Proxy | \ 1145 / |-------------| \ 1146 / /=/ \ 1147 / /=/ \ 1148 / /=/ \ 1149 / /=/ \ 1150 / /=/ \ 1151 |----| |------| *** *** |--------| |-----| |---| 1152 | VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV 1153 |Pump| |Router| *** *** |Receiver| |-----| |---| 1154 |----| |------| |Proxy | 1155 |--------| 1157 <---Aggregation Net-------------> 1159 ******************************************************> 1161 ==============RSVP==============> 1163 SRM Systems Resource Manager 1165 *** |---| 1166 *r* regular RSVP |STB| Set Top Box 1167 *** router |---| 1169 <***> media flow 1171 ==> segment of flow path protected by RSVP reservation 1172 in forward direction 1174 / VoD Application level signaling 1176 /*/ GRE-tunnelled RSVP (Path messages) 1178 Figure 13: VoD Use Case with Receiver Proxy and SRM-based Sender 1179 Proxy 1181 The RSVP Proxy entities specified in this document play a significant 1182 role here since they allow immediate deployment of an RSVP-based 1183 admission control solution for VoD without requiring any upgrade to 1184 the huge installed base of non-RSVP-capable customer premises 1185 equipment. In one mode described above, they also avoid upgrade of 1186 non-RSVP-capable VoD pumps. In turn, this means that the benefits of 1187 on-path admission control can be offered to VoD services over 1188 broadband aggregation networks. Those include accurate bandwidth 1189 accounting regardless of topology (hub-and-spoke, ring, mesh, star, 1190 arbitrary combinations) and dynamic adjustment to any change in 1191 topology (such as failure, routing change, additional links...). 1193 A.2. RSVP-based Voice/Video CAC in Enterprise WAN 1195 More and more enterprises are migrating their telephony and 1196 videoconferencing applications onto IP. When doing so, there is a 1197 need for retaining admission control capabilities of existing TDM- 1198 based systems to ensure the QoS of these applications is maintained 1199 even when transiting through the enterprise's Wide Area Network 1200 (WAN). Since many of the endpoints already deployed (such as IP 1201 Phones or Videoconferencing terminals) are not RSVP capable, RSVP 1202 Proxy approaches are very useful by allowing deployment of an RSVP- 1203 based admission control solution over the WAN without requiring 1204 upgrade of the existing terminals. 1206 A common deployment architecture for such environments involves 1207 Application-Signaling-Triggered On-Path RSVP Proxy as defined in 1208 Section 4.5. Routers sitting at the edges of the WAN network behave 1209 as Media Relay in the datapath. For example, such a Media Relay 1210 router on the WAN Edge may terminate a call-leg from the calling IP 1211 phone and relay it to another call-leg setup on the WAN side towards 1212 another Media Relay router on the egress side of the WAN towards the 1213 called IP phone. Finally that egress Media Relay router may 1214 terminate the call leg from the ingress Media Relay router and relay 1215 it onto a call-leg setup to the called IP Phone. The Media Relay 1216 routers setup, maintain and tear down the call-legs on the WAN 1217 segment under the control of the SIP Server/Proxy. They also 1218 establish, maintain and tear-down RSVP reservations over the WAN 1219 segment for these call-legs also under the control of the SIP Server/ 1220 Proxy. The SIP Server/Proxy synchronises the RSVP reservation status 1221 with the status of end-to-end calls. For example, the called IP 1222 phone will only be instructed to play a ring tone if the RSVP 1223 reservations for the corresponding WAN call leg has been successfully 1224 established. 1226 This architecture allowing RSVP-based admission control of voice and 1227 video on the Enterprise WAN is illustrated in the Figure below. 1229 |---------| 1230 --------------| SIP |------------ 1231 / | Server/ | \ 1232 / | Proxy | \ 1233 / |---------| \ 1234 / // \\ \ 1235 / // \\ \ 1236 / // \\ \ 1237 / // \\ \ 1238 / // \\ \ 1239 |-----| |--------| *** *** |--------| |-----| 1240 | IP |------| Media |---*r*---*r*---| Media |-------|IP | 1241 |Phone| | Relay | *** *** | Relay | |Phone| 1242 |-----| | + | | + | |-----| 1243 | RSVP | | RSVP | 1244 | Proxy | | Proxy | 1245 |--------| |--------| 1247 <--campus--> <--campus--> 1248 network network 1250 <---------WAN-----------> 1252 <*************> <***********************> <**************> 1254 <=========RSVP===========> 1256 *** 1257 *r* Regular RSVP router 1258 *** 1260 <***> media flow 1262 <==> segment of flow path protected by RSVP reservation 1264 / SIP signaling 1266 // control interface between the SIP Server/Proxy and 1267 Media Relay/RSVP Proxy 1269 Figure 14: CAC on Enterprise WAN Use Case 1271 A.3. RSVP-based Voice CAC in TSP Domain 1273 Let us consider an environment involving multiple Telephony Service 1274 Providers (TSPs). Those may be interconnected through Session Border 1275 Controllers (SBC) which are on-path i.e. on the datapath of the voice 1276 media streams. The SBCs may be remotely controlled by a SIP Server/ 1277 Proxy. Support of RSVP Proxy on one side of the SBC may be used to 1278 perform RSVP-based admission control through one of the TSP Domain, 1279 even if it is not used end-to-end (and in particular when another TSP 1280 domain remains entirely non-RSVP-aware). This relies on the 1281 Application-Signaling-Triggered On-Path RSVP Proxy presented in 1282 Section 4.5. This is illustrated in the Figure below. 1284 |---------| 1285 --------------| SIP |------------ 1286 / | Server/ | \ 1287 / | Proxy | \ 1288 / |---------| \ 1289 / || \ 1290 / || \ 1291 / || \ 1292 / || \ 1293 / || \ 1294 |-----| |---------| |--------| |---------| |-----| 1295 | IP |------| TSP |-----| SBC |-----| TSP |--|IP | 1296 |Phone| | Domain1 | | + | | Domain2 | |Phone| 1297 |-----| | | | RSVP | | | |-----| 1298 | | | Proxy | | | 1299 | | |--------| | | 1300 |---------| |---------| 1302 <******************************> <*************************> 1304 <=========RSVP===========> 1306 <***> media flow 1308 <==> segment of flow path protected by RSVP reservation 1310 / SIP signaling 1312 || control interface between the SIP Server/Proxy and 1313 SBC/RSVP Proxy 1315 Figure 15: Voice CAC in TSP Domain 1317 A.4. RSVP Proxies for Mobile Access Networks 1319 Mobile access networks are increasingly based on IP technology. This 1320 implies that, on the network layer, all traffic, both traditional 1321 data and streamed data like audio or video, is transmitted as 1322 packets. Increasingly popular multimedia applications would benefit 1323 from better than best-effort service from the network, a forwarding 1324 service with strict Quality of Service (QoS) with guaranteed minimum 1325 bandwidth and bounded delay. Other applications, such as electronic 1326 commerce, network control and management, and remote login 1327 applications, would also benefit from a differentiated treatment. 1329 The IETF has two main models for providing differentiated treatment 1330 of packets in routers. The Integrated Services (IntServ) model 1331 [RFC1633] together with the Resource Reservation Protocol (RSVP) 1332 [RFC2205] [RFC2210] [RFC2961] provides per-flow guaranteed end-to-end 1333 transmission service. The Differentiated Services (DiffServ) 1334 framework [RFC2475] provides non- signaled flow differentiation that 1335 usually provides, but does not guarantee, proper transmission 1336 service. 1338 However, these architectures have weaknesses, for example, RSVP 1339 requires support from both communication end points, and the protocol 1340 may have potential performance issues in mobile environments. 1341 DiffServ can only provide statistical guarantees and is not well 1342 suited for dynamic environments. 1344 Let us consider a scenario, where a fixed network correspondent node 1345 (CN) would be sending a multimedia stream to an end host behind a 1346 wireless link. If the correspondent node does not support RSVP it 1347 cannot signal its traffic characteristics to the network and request 1348 specific forwarding services. Likewise, if the correspondent node is 1349 not able to mark its traffic with a proper DiffServ Code Point (DSCP) 1350 to trigger service differentiation, the multimedia stream will get 1351 only best-effort service which may result in poor visual and audio 1352 quality in the receiving application. Even if the connecting wired 1353 network is over-provisioned, an end host would still benefit from 1354 local resource reservations, especially in wireless access networks, 1355 where the bottleneck resource is most probably the wireless link. 1357 RSVP proxies would be a very beneficial solution to this problem. It 1358 would allow distinguishing local network reservations from the end- 1359 to-end reservations. The end host does not need to know the access 1360 network topology or the nodes that will reserve the local resources. 1361 The access network would do resource reservations for both incoming 1362 and outgoing flows based on certain criterion, e.g., filters based on 1363 application protocols. Another option is that the mobile end host 1364 makes an explicit reservation that identifies the intention and the 1365 access network will find the correct local access network node(s) to 1366 respond to the reservation. RSVP proxies would, thus, allow resource 1367 reservation over the segment which is the most likely bottleneck, the 1368 wireless connectivity. If the wireless access network uses a local 1369 mobility management mechanism, where the IP address of the mobile 1370 node does not change during handover, RSVP reservations would follow 1371 the mobile node movement. 1373 Authors' Addresses 1375 Francois Le Faucheur 1376 Cisco Systems 1377 Greenside, 400 Avenue de Roumanille 1378 Sophia Antipolis 06410 1379 France 1381 Phone: +33 4 97 23 26 19 1382 Email: flefauch@cisco.com 1384 Jukka Manner 1385 University of Helsinki 1386 P.O. Box 68 1387 University of Helsinki FIN-00014 University of Helsinki 1388 Finland 1390 Phone: +358 9 191 51298 1391 Email: jmanner@cs.helsinki.fi 1392 URI: http://www.cs.helsinki.fi/u/jmanner/ 1394 Dan Wing 1395 Cisco Systems 1396 170 West Tasman Drive 1397 San Jose, CA 95134 1398 United States 1400 Email: dwing@cisco.com 1402 Allan Guillou 1403 Neuf Cegetel 1404 40-42 Quai du Point du Jour 1405 Boulogne-Billancourt, 92659 1406 France 1408 Email: allan.guillou@neufcegetl.fr 1410 Full Copyright Statement 1412 Copyright (C) The IETF Trust (2007). 1414 This document is subject to the rights, licenses and restrictions 1415 contained in BCP 78, and except as set forth therein, the authors 1416 retain all their rights. 1418 This document and the information contained herein are provided on an 1419 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1420 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1421 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1422 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1423 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1424 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1426 Intellectual Property 1428 The IETF takes no position regarding the validity or scope of any 1429 Intellectual Property Rights or other rights that might be claimed to 1430 pertain to the implementation or use of the technology described in 1431 this document or the extent to which any license under such rights 1432 might or might not be available; nor does it represent that it has 1433 made any independent effort to identify any such rights. Information 1434 on the procedures with respect to rights in RFC documents can be 1435 found in BCP 78 and BCP 79. 1437 Copies of IPR disclosures made to the IETF Secretariat and any 1438 assurances of licenses to be made available, or the result of an 1439 attempt made to obtain a general license or permission for the use of 1440 such proprietary rights by implementers or users of this 1441 specification can be obtained from the IETF on-line IPR repository at 1442 http://www.ietf.org/ipr. 1444 The IETF invites any interested party to bring to its attention any 1445 copyrights, patents or patent applications, or other proprietary 1446 rights that may cover technology that may be required to implement 1447 this standard. Please address the information to the IETF at 1448 ietf-ipr@ietf.org. 1450 Acknowledgment 1452 Funding for the RFC Editor function is provided by the IETF 1453 Administrative Support Activity (IASA).