idnits 2.17.1 draft-ietf-tsvwg-rsvp-proxy-approaches-06.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 1949. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1960. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1967. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1973. 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 (October 31, 2008) is 5649 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-ietf-mmusic-qos-identification-02 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-16 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-proxy-proto-07 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-01 -- No information found for draft-manner-tsvwg-rsvp-proxy-sig - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 12 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: May 4, 2009 University of Helsinki 6 D. Wing 7 Cisco 8 A. Guillou 9 Neuf 10 October 31, 2008 12 RSVP Proxy Approaches 13 draft-ietf-tsvwg-rsvp-proxy-approaches-06.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 May 4, 2009. 40 Abstract 42 The Resource ReSerVation Protocol (RSVP) can be used to make end-to- 43 end resource reservations in an IP network in order to guarantee the 44 quality of service required by certain flows. RSVP assumes that both 45 the data sender and receiver of a given flow take part in RSVP 46 signaling. Yet, there are many use cases where resource reservation 47 is required, but the receiver, the sender, or both, is not RSVP- 48 capable. This document presents RSVP Proxy behaviors allowing RSVP 49 routers to initiate or terminate RSVP signaling on behalf of a 50 receiver or a sender that is not RSVP-capable. This allows resource 51 reservations to be established on a critical subset of the end-to-end 52 path. This document reviews conceptual approaches for deploying RSVP 53 Proxies and discusses how RSVP reservations can be synchronized with 54 application requirements, despite the sender, receiver, or both not 55 participating in RSVP. This document also points out where 56 extensions to RSVP (or to other protocols) may be needed for 57 deployment of a given RSVP Proxy approach. However, such extensions 58 are outside the scope of this document. Finally, practical use cases 59 for RSVP Proxy are described. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 5 66 2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 6 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4. RSVP Proxy Approaches . . . . . . . . . . . . . . . . . . . . 8 69 4.1. Path-Triggered Receiver Proxy . . . . . . . . . . . . . . 8 70 4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 11 71 4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 15 72 4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 17 73 4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 20 74 4.5.1. Application_Entity-Controlled Sender Proxy using 75 "RSVP over GRE" . . . . . . . . . . . . . . . . . . . 22 76 4.5.2. Application_Entity-Controlled Proxy via Co-Location . 24 77 4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 25 78 4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 28 79 4.8. Reachability Considerations . . . . . . . . . . . . . . . 29 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 82 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 83 8. Informative References . . . . . . . . . . . . . . . . . . . . 31 84 Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 34 85 A.1. RSVP-based VoD CAC in Broadband Aggregation Networks . . . 34 86 A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 38 87 A.3. RSVP-based Voice CAC in Telephony Service Provider Core . 39 88 A.4. RSVP Proxies for Mobile Access Networks . . . . . . . . . 41 89 A.5. RSVP Proxies for Reservations in the presence of IPsec 90 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 43 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 92 Intellectual Property and Copyright Statements . . . . . . . . . . 48 94 1. Introduction 96 Guaranteed Quality of Service (QoS) for some applications with tight 97 requirements (such as voice or video) may be achieved by reserving 98 resources in each node on the end-to-end path. The main IETF 99 protocol for these resource reservations is RSVP, specified in 100 [RFC2205]. RSVP does not require that all intermediate nodes support 101 RSVP, however it assumes that both the sender and the receiver of the 102 data flow support RSVP. There are environments where it would be 103 useful to be able to reserve resources for a flow on at least a 104 subset of the flow path even when the sender or the receiver (or 105 both) is not RSVP (for example from the sender to the network edge, 106 or from edge to edge, or from the network edge to the receiver). 108 Since the data sender or receiver may be unaware of RSVP, there are 109 two types of RSVP Proxies. When the sender is not using RSVP, an 110 entity in the network must operate on behalf of the data sender, and 111 in particular, generate RSVP Path messages, and eventually receive, 112 process and sink Resv messages. We refer to this entity as the RSVP 113 Sender Proxy. When the receiver is not using RSVP, an entity in the 114 network must receive Path messages sent by a data sender (or by an 115 RSVP Sender Proxy), sink those, and return Resv messages on behalf of 116 the data receiver(s). We refer to this entity as the RSVP Receiver 117 Proxy. The RSVP Proxies need to be on the data path in order to 118 establish the RSVP reservation; Note, however, that some of the 119 approaches described in this document allow the RSVP Proxies to be 120 controlled/triggered by an off-path entity. 122 The flow sender and receiver generally have at least some (if not 123 full) awareness of the application producing or consuming that flow. 124 Hence, the sender and receiver are in a natural position to 125 synchronize the establishment, maintenance and tear down of the RSVP 126 reservation with the application requirements. Similarly they are in 127 a natural position to determine the characteristics of the 128 reservation (bandwidth, QoS service,...) which best match the 129 application requirements. For example, before completing the 130 establishment of a multimedia session, the endpoints may decide to 131 establish RSVP reservations for the corresponding flows. Similarly, 132 when the multimedia session is torn down, the endpoints may decide to 133 tear down the corresponding RSVP reservations. For instance, 134 [RFC3312] discusses how RSVP reservations can be very tightly 135 synchronized by endpoints that uses the [RFC3261] Session Initation 136 Protocol (SIP) for session control. 138 When RSVP reservation establishment, maintenance and tearing down is 139 to be handled by RSVP Proxies on behalf of an RSVP sender or 140 receiver, a key challenge for the RSVP Proxy is to determine when the 141 RSVP reservations need to be established, maintained and torn down 142 and to determine what are the characteristics (bandwidth, QoS 143 Service,...) of the required RSVP reservations matching the 144 application requirements. We refer to this problem as the 145 synchronization of RSVP reservations with application level 146 requirements. 148 The IETF Next Steps in Signaling (NSIS) working group is specifying a 149 new QoS signaling protocol: the QoS NSIS Signaling Layer Protocol 150 (NSLP) ([I-D.ietf-nsis-qos-nslp]). This protocol also includes the 151 notion of proxy operation, and terminating QoS signaling on nodes 152 that are not the actual data senders or receivers (see section "4.8 153 Proxy Mode" of [I-D.ietf-nsis-qos-nslp]. This is the same concept as 154 the proxy operation for RSVP discussed in this document. One 155 difference though is that the NSIS framework does not consider 156 multicast resource 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 It is important to keep in mind that the strongly recommended RSVP 167 deployment model remains end to end as assumed in [RFC2205] with RSVP 168 support on the sender and the receiver. The end to end model allows 169 the most effective synchronization between the reservation and 170 application requirements. Also, when compared to the end to end RSVP 171 model, the use of RSVP Proxies involves additional operational burden 172 and/or impose some topological constaints. The additional 173 operational burden comes in particular from additional configuration 174 needed to activate the RSVP Proxies and to help them identify for 175 which senders/receivers a Proxy behavior is required and for which 176 senders/receivers it is not (so that an RSVP Proxy does not attempt 177 establishment of reservations on behalf of devices that are already 178 establishing the reservations themselves). The additional 179 topological constaints come in particular from the requirement to 180 have one, and only one, Receiver Proxy on the path from any sender to 181 every non-RSVP capable device (so that an non-RSVP capable device is 182 always taken care of by an RSVP Proxy, and so that an RSVP Proxy does 183 not short-circuit another RSVP Proxy closer to the non-RSVP capable 184 device). 186 It is also worth noting that RSVP operations on endsystems is 187 considerably simpler than on a router, and consequently that RSVP 188 implementations on endsystems are very lightweight (particularly 189 considering modern endsystems capabilities, including mobile and 190 portable devices). For example, endsystem RSVP implementations are 191 reported to only consume low tens of kilobytes of code space. Hence, 192 the present document should not be seen as an encouragement to depart 193 from the end to end RSVP model. Its purpose is only to allow RSVP 194 deployment in special environments where RSVP just cannot be used on 195 some senders and/or some receivers for reasons specific to the 196 environment. 198 2. RSVP Proxy Behaviors 200 This section discusses the two types of proxies; the RSVP Sender 201 Proxy operating on behalf of data senders, and the RSVP Receiver 202 Proxy operating for data receivers. The concepts presented in this 203 document are not meant to deprecate the traditional [RFC2205] RSVP 204 end-to-end model: end-to-end RSVP reservations are still expected to 205 be used whenever possible. However, RSVP Proxies are intended to 206 facilitate RSVP deployment where end-to-end RSVP signaling is not 207 possible. 209 2.1. RSVP Receiver Proxy 211 With conventional end-to-end RSVP operations, RSVP reservations are 212 controlled by receivers of data. After a data sender has sent an 213 RSVP Path message towards the intended recipient(s), each recipient 214 that requires a reservation generates a Resv message. If, however, a 215 data receiver is not running the RSVP protocol, the last hop RSVP 216 router will still send the Path message to the data receiver, which 217 will silently drop this message as an IP packet with an unknown 218 protocol number. 220 In order for reservations to be made in such a scenario, one of the 221 RSVP routers on the data path determines that the data receiver will 222 not be participating in the resource reservation signaling and 223 performs RSVP Receiver Proxy functionality on behalf of the data 224 receiver. This is illustrated in Figure 1. Various mechanisms by 225 which the RSVP proxy router can gain the required information are 226 discussed later in the document. 228 |----| *** *** |----------| |----| 229 | S |---------*r*----------*r*---------| RSVP |----------| R | 230 |----| *** *** | Receiver | |----| 231 | Proxy | 232 |----------| 234 ===================RSVP==============> 236 ***********************************************************> 238 |----| RSVP-capable |----| non-RSVP-capable *** 239 | S | Sender | R | Receiver *r* regular RSVP 240 |----| |----| *** router 242 ***> unidirectional media flow 244 ==> segment of flow path protected by RSVP reservation 246 Figure 1: RSVP Receiver Proxy 248 2.2. RSVP Sender Proxy 250 With conventional end-to-end RSVP operations, if a data sender is not 251 running the RSVP protocol, a resource reservation can not be set up; 252 a data receiver can not alone reserve resources without Path messages 253 first being received. Thus, even if the data receiver is running 254 RSVP, it still needs some node on the data path to send a Path 255 message towards the data receiver. 257 In that case, an RSVP node on the data path determines that it should 258 generate Path messages to allow the receiver to set up the resource 259 reservation. This node is referred to as the RSVP Sender Proxy and 260 is illustrated in Figure 2. This case presents additional challenges 261 over the Receiver Proxy case, since the RSVP Sender Proxy must be 262 able to generate all the information in the Path message (such as the 263 Sender TSpec) without the benefit of having previously received any 264 RSVP message. An RSVP Receiver Proxy, by contrast only needs to 265 formulate an appropriate Resv message in response to an incoming Path 266 message. Mechanisms to operate an RSVP Sender Proxy are discussed 267 later in this document. 269 |----| |----------| *** *** |----| 270 | S |---------| RSVP |---------*r*----------*r*----------| R | 271 |----| | Sender | *** *** |----| 272 | Proxy | 273 |----------| 275 ================RSVP==================> 277 ***********************************************************> 279 |----| non-RSVP-capable |----| RSVP-capable *** 280 | S | Sender | R | Receiver *r* regular RSVP 281 |----| |----| *** router 283 ***> unidirectional media flow 285 ==> segment of flow path protected by RSVP reservation 287 Figure 2: RSVP Sender Proxy 289 3. Terminology 291 o On-Path: located on the datapath of the actual flow of application 292 data (regardless of where it is located with respect to the 293 application level signaling path). 295 o Off-Path: not On-Path. 297 o RSVP-capable (or RSVP-aware): which supports the RSVP protocol as 298 per [RFC2205]. 300 o RSVP Receiver Proxy: an RSVP capable router performing, on behalf 301 of a receiver, the RSVP operations which would normally be 302 performed by an RSVP-capable receiver if end-to-end RSVP signaling 303 was used. Note that while RSVP is used upstream of the RSVP 304 Receiver Proxy, RSVP is not used downstream of the RSVP Receiver 305 Proxy. 307 o RSVP Sender Proxy: an RSVP capable router performing, on behalf of 308 a sender, the RSVP operations which would normally be performed by 309 an RSVP-capable sender if end-to-end RSVP signaling was used. 310 Note that while RSVP is used downstream of the RSVP Sender Proxy, 311 RSVP is not used upstream of the RSVP Sender Proxy. 313 o Regular RSVP Router: an RSVP-capable router which is not behaving 314 as a RSVP Receiver Proxy nor as a RSVP Sender Proxy. 316 o Application level signaling: signaling between entities operating 317 above the IP layer and which are aware of the QoS requirements for 318 actual media flows. SIP ([RFC3261]) and RTSP ([RFC2326]) are 319 examples of application level signaling protocol. SDP ([RFC4566]) 320 is an example of session description protocol that can be used by 321 the application level signaling protocol and from which some of 322 the RSVP reservation parameters (addresses, ports and bandwidth) 323 might be derived. RSVP is clearly not an application level 324 signaling. 326 The roles of RSVP Receiver Proxy, RSVP Sender Proxy, Regular RSVP 327 Router are all relative to a given unidirectional flow. A given 328 router may act as the RSVP Receiver Proxy for a flow, as the RSVP 329 Sender Proxy for another flow and as a Regular RSVP router for yet 330 another flow. 332 Some application level signaling protocols support negotiation of QoS 333 reservations for a media stream. For example, with [RFC3312], 334 resource reservation requirements are explicitely signaled during 335 session establishment using SIP and SDP. Also, 336 [I-D.ietf-mmusic-qos-identification] defines a mechanism to negotiate 337 which resource reservation mechanism is to be used for a particular 338 media stream. Clearly, these reservation negotiation mechanisms can 339 be invoked and operate effectively when when both ends support RSVP 340 (and obviously RSVP Proxies are not used). When both ends do not 341 support RSVP (and RSVP proxies are used at both ends) these 342 mechanisms will simply not be invoked. In the case where one end 343 supports RSVP and the other does not (and is helped by an RSVP 344 Proxy), the application level signaling entity supporting the non 345 RSVP capable end might use the reservation negotiation mechanisms in 346 such a way that the non RSVP capable end (helped by an RSVP Proxy) 347 appears to the remote end as an RSVP capable device. This will 348 ensure that the RSVP capable end is not discouraged to use RSVP 349 because the remote end is not RSVP capable. In the case of SIP, the 350 application level entity may achieve this by taking advantage of the 351 "segmented" Status Type of [RFC3312] and/or by implementing a SIP 352 [RFC3261] Back-to-Back User Agent (B2BUA). 354 4. RSVP Proxy Approaches 356 This section discusses fundamental RSVP Proxy approaches. 358 4.1. Path-Triggered Receiver Proxy 360 In this approach, it is assumed that the sender is RSVP capable and 361 takes full care of the synchronization between application 362 requirements and RSVP reservations. With this approach, the RSVP 363 Receiver Proxy uses the RSVP Path messages generated by the sender as 364 the cue for establishing the RSVP reservation on behalf of the 365 receiver. The RSVP Receiver Proxy is effectively acting as a slave 366 making reservations (on behalf of the receiver) under the sender's 367 control. This changes somewhat the usual RSVP reservation model 368 where reservations are normally controlled by receivers. Such a 369 change greatly facilitates operations in the scenario of interest 370 here, which is where the receiver is not RSVP capable. Indeed it 371 allows the RSVP Receiver Proxy to remain application unaware by 372 taking advantage of the application awareness and RSVP awareness of 373 the sender. 375 With the Path-Triggered RSVP Receiver Proxy approach, the RSVP router 376 may be configured to use receipt of a regular RSVP Path message as 377 the trigger for RSVP Receiver Proxy behavior. 379 On receipt of the RSVP Path message, the RSVP Receiver Proxy: 381 1. establishes the RSVP Path state as per regular RSVP processing 383 2. identifies the downstream interface towards the receiver 385 3. sinks the Path message 387 4. behaves as if a Resv message (whose details are discussed below) 388 was received on the downstream interface. This includes 389 performing admission control on the downstream interface, 390 establishing a Resv state (in case of successful admission 391 control) and forwarding the Resv message upstream, sending 392 periodic refreshes of the Resv message and tearing down the 393 reservation if the Path state is torn down. 395 In order to build the Resv message, the RSVP Receiver Proxy can take 396 into account information received in the Path message. For example, 397 the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv 398 message which mirrors the SENDER_TSPEC object in the received Path 399 message. 401 Operation of the Path-Triggered Receiver Proxy in the case of a 402 successful reservation is illustrated in Figure 3. 404 |----| *** *** |----------| |----| 405 | S |---------*r*----------*r*---------| RSVP |----------| R | 406 |----| *** *** | Receiver | |----| 407 | Proxy | 408 |----------| 410 ---Path---> ----Path----> ---Path----> 412 <--Resv---> <---Resv----- <--Resv---- 414 ==================RSVP===============> 416 **********************************************************> 418 |----| RSVP-capable |----| Non-RSVP-capable *** 419 | S | Sender | R | Receiver *r* regular RSVP 420 |----| |----| *** router 422 ***> media flow 424 ==> segment of flow path protected by RSVP reservation 426 Figure 3: Path-Triggered RSVP Receiver Proxy 428 In case the reservation establishment is rejected (for example 429 because of an admission control failure on a regular RSVP router on 430 the path between the RSVP-capable sender and the RSVP Receiver 431 Proxy), a ResvErr message will be generated as per conventional RSVP 432 operations and will travel downstream towards the RSVP Receiver 433 Proxy. While this ensures that the RSVP Receiver Proxy is aware of 434 the reservation failure, conventional RSVP procedures do not cater 435 for notification of the sender of the reservation failure. Operation 436 of the Path-Triggered RSVP Receiver Proxy in the case of an admission 437 control failure is illustrated in Figure 4. 439 |----| *** *** |----------| |----| 440 | S |---------*r*----------*r*---------| RSVP |----------| R | 441 |----| *** *** | Receiver | |----| 442 | Proxy | 443 |----------| 445 ---Path---> ----Path----> ---Path----> 447 <---Resv----- <--Resv------ 449 ---ResvErr---> --ResvErr---> 451 ===================RSVP===============> 453 **********************************************************> 455 |----| RSVP-capable |----| Non-RSVP-capable *** 456 | S | Sender | R | Receiver *r* regular RSVP 457 |----| |----| *** router 459 ***> media flow 461 ==> segment of flow path protected by RSVP reservation 463 Figure 4: Path-Triggered RSVP Receiver Proxy with Failure 465 Since, as explained above, in this scenario involving the RSVP 466 Receiver Proxy, synchronization between application and RSVP 467 reservation is generally performed by the sender, notifying the 468 sender of reservation failure is needed. 469 [I-D.ietf-tsvwg-rsvp-proxy-proto] specifies RSVP extensions allowing 470 such sender notification in case of reservation failure in the 471 presence of a Path-Triggered RSVP Receiver Proxy. 473 4.2. Path-Triggered Sender Proxy for Reverse Direction 475 In this approach, it is assumed that one endpoint is RSVP capable and 476 takes full care of the synchronization between application 477 requirements and RSVP reservations. This endpoint is the sender for 478 one flow direction (which we refer to as the "forward" direction) and 479 is the receiver for the flow in the opposite direction (which we 480 refer to as the "reverse" direction). 482 With the Path-Triggered Sender Proxy for Reverse Direction approach, 483 the RSVP Proxy uses the RSVP signaling generated by the receiver (for 484 the reverse direction) as the cue for initiating RSVP signaling for 485 the reservation in the reverse direction. More precisely, the RSVP 486 Proxy can take the creation (respectively, maintenance and teardown) 487 of a Path state by the receiver as the cue to create (respectively, 488 maintain and teardown) a Path state towards the receiver. Thus, the 489 RSVP Proxy is effectively acting as a Sender Proxy for the reverse 490 direction under the control of the receiver (for the reverse 491 direction). Note that this assumes a degree of symmetry for example 492 in terms of bandwidth for the two directions of the flow (as is 493 currently typical for IP telephony, for example). 495 The signaling flow for the Path-Triggered Sender Proxy for Reverse 496 Direction is illustrated in Figure 5. 498 Path messages generated by the receiver need to transit via the RSVP 499 Sender Proxy that is on the path from the sender to the receiver. In 500 some topologies, this will always be the case: for example where the 501 sender is on a stub network hanging off the RSVP Sender Proxy or 502 where there is no asymetric routing (such that if a RSVP Sender Proxy 503 is on the path from receiver to sender, then it is also on the path 504 from sender to receiver). In some topologies (such as those 505 involving asymetric routing), this may not always happen naturally. 506 Measures to ensure this does happen in these topologies are outside 507 the scope of this document. 509 |----| *** *** |----------| |----| 510 | R |---------*r*----------*r*---------| RSVP |----------| S | 511 |----| *** *** | Sender | |----| 512 | Proxy | 513 |----------| 515 ---Path---> ----Path----> ---Path----> 517 <--Path---> <---Path----- <--Path---- 519 ---Resv---> ----Resv----> ---Resv----> 521 <================RSVP================== 523 <********************************************************** 525 |----| RSVP-capable |----| Non-RSVP-capable *** 526 | R | Receiver for | S | Sender for *r* regular RSVP 527 |----| reverse direction |----| reverse direction *** router 529 ***> media flow 531 ==> segment of flow path protected by RSVP reservation 532 in reverse direction 534 Figure 5: Path-Triggered Sender Proxy for Reverse Direction 536 Of course, the RSVP Proxy may simultaneously (and typically will) 537 also act as the Path-Triggered Receiver Proxy for the forward 538 direction, as defined in Section 4.1. Such an approach is most 539 useful in situations involving RSVP reservations in both directions 540 for symmetric flows. This is illustrated in Figure 6. 542 |----| *** *** |----------| |----| 543 |S/R |---------*r*----------*r*---------| RSVP |----------|S/R&| 544 |----| *** *** | Receiver | |----| 545 | & Sender | 546 | Proxy | 547 |----------| 549 ---Path---> ----Path----> ---Path----> 551 <--Resv---> <---Resv----- <--Resv---- 553 <--Path---> <---Path----- <--Path---- 555 ---Resv---> ----Resv----> ---Resv----> 557 ================RSVP==================> 558 <================RSVP================== 560 **********************************************************> 561 <********************************************************** 563 |----| RSVP-capable |----| Non-RSVP-capable *** 564 |S/R | Sender and |S/R&| Sender and *r* regular RSVP 565 |----| Receiver |----| Receiver *** router 567 ***> media flow 569 ==> segment of flow path protected by RSVP reservation 570 in forward and in reverse direction 572 Figure 6: Path Triggered Receiver & Sender Proxy 574 With the Path-Triggered Sender Proxy for Reverse Direction approach, 575 the RSVP router may be configurable to use receipt of a regular RSVP 576 Path message as the trigger for Sender Proxy for Reverse Direction 577 behavior. 579 On receipt of the RSVP Path message for the forward direction, the 580 RSVP Sender Receiver Proxy : 582 1. sinks the Path message 584 2. behaves as if a Path message for reverse direction (whose details 585 are discussed below) had been received by the Sender Proxy. This 586 includes establishing the corresponding Path state, forwarding 587 the Path message downstream, sending periodic refreshes of the 588 Path message and tearing down the Path in reverse direction when 589 the Path state in forward direction is torn down. 591 In order to build the Path message for the reverse direction, the 592 RSVP Sender Proxy can take into account information in the received 593 Path message for the forward direction. For example, the RSVP Sender 594 Proxy may mirror the SENDER_TSPEC object in the received Path 595 message. 597 We observe that this approach does not require any extensions to the 598 existing RSVP protocol. 600 In the case where reservations are required in both directions (as 601 shown in Figure 6), the RSVP-capable device simply needs to behave as 602 a regular RSVP sender and RSVP receiver. It needs not be aware that 603 an RSVP Proxy happens to be used and the Path message it sent for the 604 forward reservation also acts as the trigger for establishment of the 605 reverse reservation. However, in the case where a reservation is 606 only required in the reverse direction (as shown in Figure 5), the 607 RSVP-capable device has to generate Path messages in order to trigger 608 the reverse direction reservation even if no reservation is required 609 in the forward direction. Although this is not in violation with 610 [RFC2205], it may not be the default behavior of an RSVP-capable 611 device and therefore may need a behavioral change specifically to 612 facilitate operation of the Path-Triggered Sender Proxy for Reverse 613 Direction. 615 4.3. Inspection-Triggered Proxy 617 In this approach, it is assumed that the RSVP Proxy is on the 618 datapath of "packets of interest", that it can inspect such packets 619 on the fly as they transit through it, and that it can infer 620 information from these packets of interest to determine what RSVP 621 reservations need to be established, when and with what 622 characteristics (possibly also using some configured information). 624 One example of "packets of interest" could be application level 625 signaling. An RSVP Proxy capable of inspecting SIP signaling for 626 multimedia session or RTSP signaling for Video streaming, can obtain 627 from such signaling information about when a multimedia session is up 628 or when a Video is going to be streamed. It can also identify the 629 addresses and ports of senders and receivers and can determine the 630 bandwidth of the corresponding flows. Thus, such an RSVP Proxy can 631 determine all necessary information to synchronize RSVP reservations 632 to application requirements. This is illustrated in Figure 7. 634 |-------------| 635 | Application | 636 | Signaling | 637 | Entity | 638 |-------------| 639 / \ 640 / \ 641 / \ 642 644 |----| |--------| *** |--------| |----| 645 | S |--------| RSVP |------*r*--------| RSVP |----------| R | 646 |----| | Proxy | *** | Proxy | |----| 647 |--------| |--------| 649 =======RSVP=======> 651 ********************************************************> 653 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 654 | S | Sender | R | Receiver *r* regular RSVP 655 |----| |----| *** router 657 application level signaling 659 ***> media flow 661 ==> segment of flow path protected by RSVP reservation 663 Figure 7: Inspection-Triggered RSVP Proxy 665 Another example of "packets of interest" could be packets belonging 666 to the application flow itself (e.g. media packets). An RSVP Proxy 667 capable of detecting the transit of packets from a particular flow, 668 can attempt to establish a reservation corresponding to that flow. 669 Characteristics of the reservation may be derived from configuration, 670 flow measurement or a combination of those. 672 Note however, that in case of reservation failure, the inspection- 673 triggered RSVP Proxy does not have a direct mechanism for notifying 674 the application (since it is not participating itself actively in 675 application signaling) so that the application is not in a position 676 to take appropriate action (for example terminate the corresponding 677 session). To mitigate this problem, the inspection-triggered RSVP 678 Proxy may mark differently the DSCP of flows for which an RSVP 679 reservation has been successfully proxied from the flows for which a 680 reservation is not in place. In some situations, the Inspection- 681 Triggered Proxy might be able to modify the "packets of interest" 682 (e.g. application signaling messages) to convey some hint to 683 applications that the corresponding flows cannot be guaranteed by 684 RSVP reservations. 686 With the inspection-triggered Proxy approach, the RSVP Proxy is 687 effectively required to attempt to build application awareness by 688 traffic inspection and then is somewhat limited in the actions it can 689 take in case of reservation failure. Depending on the "packets of 690 interest" used by the RSVP Proxy to trigger the reservation, there is 691 a risk that the RSVP Proxy ends up establishing a reservation for a 692 media flow that actually never starts. However, this can be 693 mitigated by timing out and tear down of an unnecessary reservation 694 by the RSVP Proxy when no corresponding media flow is observed. The 695 inspection-triggered approach is also subject to the general 696 limitations associated with data inspection. This includes being 697 defeated in the presence of encryption or being dependent on some 698 topology constraints such as relying on the fact that both the 699 packets of interest and the corresponding flow packets always transit 700 through the same RSVP Proxy. 702 Nonetheless, this may be a useful approach in specific environments. 703 Note also that this approach does not require any change to the RSVP 704 protocol. 706 With the "Inspection-Triggered" RSVP Proxy approach, the RSVP router 707 may be configurable to use and interpret some specific "packets of 708 interest" as the trigger for RSVP Receiver Proxy behavior. 710 4.4. STUN-Triggered Proxy 712 In this approach, the RSVP Proxy takes advantage of the application 713 awareness provided by the STUN signaling to synchronize RSVP 714 reservations with application requirements. The STUN signaling is 715 sent from endpoint to endpoint. This is illustrated in [RFC5389]. 717 |----| |--------| *** |--------| |----| 718 | S |--------| RSVP |------*r*--------| RSVP |----------| R | 719 |----| | Proxy | *** | Proxy | |----| 720 |--------| |--------| 722 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^> 724 =======RSVP=======> 726 ********************************************************> 728 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 729 | S | Sender | R | Receiver *r* regular RSVP 730 |----| |----| *** router 732 ^^^> STUN message flow (over same UDP ports as media flow) 734 ==> segment of flow path protected by RSVP reservation 736 ***> RTP media flow 738 Figure 8: STUN-Triggered Proxy 740 In this approach, a STUN[RFC5389] message triggers the RSVP Proxy. 742 For unicast flows, [I-D.ietf-mmusic-ice] is a widely-adopted approach 743 for NAT traversal. For our purposes of triggering RSVP Proxy 744 behavior, we rely on ICE's connectivity check which is based on the 745 exchange of STUN Binding Request messages between hosts to verify 746 connectivity (see section 2.2 of [I-D.ietf-mmusic-ice]). The STUN 747 message could also include (yet to be specified) STUN attributes to 748 indicate information such as the bandwidth and application requesting 749 the flow, which would allow the RSVP proxy agent to create an 750 appropriately-sized reservation for each flow. Including such new 751 STUN attributes in the ICE connectivity check messages would 752 facilitates operation of the RSVP Proxy. To ensure RSVP reservations 753 are only established when needed, the RSVP Proxy needs to 754 distinguish, among all the STUN messages, the ones that reflect (with 755 high likelihood) an actual upcoming media flow. This can be achieved 756 by identifying the STUN messages associated with an ICE connectivity 757 check. In turn, this can be achieved through (some combination of) 758 the following checks: 760 o if, as discussed above, new STUN attributes (e.g. conveying the 761 flow bandwidth) are indeed defined in the future in view of 762 facilitating STUN-Triggered reservations, then the presence of 763 these attributes would reveal that the STUN message is part of an 764 ICE connectivity check. 766 o the presence of the PRIORITY, USE-CANDIDATE, ICE-CONTROLLED or 767 ICE-CONTROLLING attributes reveals that the STUN message is part 768 of an ICE connectivity check 770 o the RSVP Proxy may wait for a STUN message containing the USE- 771 CANDIDATE attribute indicating the selected ICE "path" to trigger 772 reservation only for the selected "path". This allows the RSVP 773 Proxy to only trigger a reservation for the "path" actually 774 selected and therefore for the media flow that will actually be 775 established (for example when ICE is being used for v4/v6 path 776 selection). 778 o the RSVP Proxy configuration could contain some information 779 facilitating determination of when to perform RSVP Proxy 780 reservation and not. For example, the RSVP Proxy configuration 781 could contain the IP addresses of the STUN servers such that STUN 782 messages to/from those addresses are known to not be part of an 783 ICE connectivity check. As another example, the RSVP Proxy 784 configuration could contain information identifying the set of 785 DiffServ Code Point (DSCP) values that the media flows requiring 786 reservation use, so that STUN messages not using one of theses 787 DSCP values are known to not be part of an ICE connectivity check. 789 Despite these checks, there is always a potential risk that the RSVP 790 Proxy ends up establishing a reservation for a media flow that 791 actually never starts. However, this is limited to situations where 792 the end-systems is interested enough in establishing connectivity for 793 a flow but yet never transmit. Also, this can be mitigated by timing 794 out and tear down of an unnecessary reservations by the RSVP Proxy 795 when no cortresponding media flow is observed. 797 The RSVP Proxy agent can inform endpoints of an RSVP reservation 798 failure implicitely by dropping the ICE connectivity check message or 799 explicitely by sending ICMP messages back to the endpoint. This 800 allows reasonably effective synchronisation between RSVP reservations 801 handled by the RSVP Proxies and the application running on non RSVP- 802 capable endpoints. It also has the benefits of operating through 803 NATs. 805 For multicast flows (or certain kinds of unicast flows that don't or 806 can't use ICE), a STUN Indication message [RFC5389] could be used to 807 carry the (yet to be defined) STUN attributes mentioned earlier to 808 indicate the flow bandwidth, thereby providing a benefit similar to 809 the ICE connectivity check. STUN Indication messages are not 810 acknowledged by the receiver and have the same scalability as the 811 underlying multicast flow. 813 The corresponding extensions to ICE and STUN for such a STUN- 814 triggered RSVP Proxy approach are beyond the scope of this document. 815 They may be defined in the future in a separate document. As the 816 STUN-triggered RSVP Proxy approach uses STUN in a way (i.e. to 817 trigger reservations) that is beyond its initial intended purpose, 818 the potential security implications need to be considered by the 819 operator. 821 4.5. Application_Entity-Controlled Proxy 823 In this approach, it is assumed that an entity involved in the 824 application level signaling controls an RSVP Proxy which is located 825 in the datapath of the application flows (i.e. "on-path"). With this 826 approach, the RSVP Proxy does not attempt to determine itself the 827 application reservation requirements. Instead the RSVP Proxy is 828 instructed by the entity participating in application level signaling 829 to establish, maintain and tear down reservations as needed by the 830 application flows. In other words, with this approach, the solution 831 for synchronizing RSVP signaling with application level requirements 832 is to rely on an application-level signaling entity that controls an 833 RSVP Proxy function that sits in the flow datapath. This approach 834 allows control of an RSVP Sender Proxy, an RSVP Receiver Proxy or 835 both. 837 Operation of the Application_Entity-Controlled Proxy is illustrated 838 in Figure 9. 840 |---------| |---------| 841 /////////| App |////\\\\| App |\\\\\\\\ 842 / | Entity | | Entity | \ 843 / |---------| |---------| \ 844 / // \\ \ 845 / // \\ \ 846 / // \\ \ 847 / // \\ \ 848 / // \\ \ 849 |----| |--------| *** |---------| |----| 850 | S |----------| |------*r*-------| |---------| R | 851 |----| | RSVP | *** | RSVP | |----| 852 | Sender | | Receiver| 853 | Proxy | | Proxy | 854 |--------| |---------| 856 =======RSVP=======> 858 ********************************************************> 860 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 861 | S | Sender | R | Receiver *r* regular RSVP 862 |----| |----| *** router 864 ***> media flow 866 ==> segment of flow path protected by RSVP reservation 868 /\ Application signaling (e.g. SIP) 870 // RSVP Proxy control interface 872 Figure 9: Application_Entity-Controlled Proxy 874 As an example, the Application_Entity-Controlled Proxy may be used in 875 the context of SIP Servers ([RFC3261]) or Session Border Controllers 876 (SBCs) (see [I-D.ietf-sipping-sbc-funcs] for description of SBCs) to 877 establish RSVP reservations for multimedia sessions. In that case, 878 the Application Entity may be the signaling component of the SBC. 880 This RSVP Proxy approach does not require any extension to the RSVP 881 protocol. However, it relies on an RSVP Proxy control interface 882 allowing control of the RSVP Proxy by an application signaling 883 entity. This RSVP Proxy control interface is beyond the scope of the 884 present document. Candidate protocols for realizing such interface 885 include SNMP([RFC3416]), COPS-PR([RFC3084]), QPIM ([RFC3644]), the 886 Extensible Markup Language (XML) and DIAMETER([RFC3588]). This 887 interface can rely on soft states or hard states. Clearly, when hard 888 states are used, those need to be converted appropriately by the RSVP 889 Proxy entities into the corresponding RSVP soft states. As an 890 example, [I-D.ietf-dime-diameter-qos] is intended to allow control of 891 RSVP Proxy via DIAMETER. 893 In general, the Application Entity is not expected to maintain 894 awareness of which RSVP Receiver Proxy is on the path to which 895 destination. However, in the particular cases where it does so 896 reliably, we observe that the Application Entity could control the 897 RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP 898 reservations are used between those, instead of one reservation per 899 flow. For example, these aggregate reservations could be of RSVP- 900 AGGREGATE type as specified in [RFC3175] or of GENERIC-AGGREGATE type 901 as specified in [RFC4860]. Such aggregate reservations could be used 902 so that a single reservation can be used for multiple (possibly all) 903 application flows transiting via the same RSVP Sender Proxy and the 904 same RSVP Receiver Proxy. 906 For situations where only the RSVP Sender Proxy has to be controlled 907 by this interface, the interface may be realized through the simple 908 use of RSVP itself, over a GRE tunnel from the application entity to 909 the RSVP Sender Proxy. This particular case is further discussed in 910 Section 4.5.1. Another particular case of interest is where the 911 application signaling entity resides on the same device as the RSVP 912 Proxy. In that case, this interface may be trivially realized as an 913 internal API. An example environment based on this particular case 914 is illustrated in Section 4.5.2. 916 4.5.1. Application_Entity-Controlled Sender Proxy using "RSVP over GRE" 918 This approach is simply a particular case of the more general 919 Application_Entity-Controlled Proxy, but where only RSVP Sender 920 Proxies need to be controlled by the application, and where RSVP is 921 effectively used as the control protocol between the application 922 signaling entity and the RSVP Sender Proxy. 924 In this approach, the RSVP messages (e.g. RSVP Path message) are 925 effectively generated by the application entity and logically 926 "tunnelled" to the RSVP Sender Proxy via GRE tunneling. This is to 927 ensure that the RSVP messages follow the exact same path as the flow 928 they protect (as required by RSVP operations) on the segment of the 929 end-to-end path which is to be subject to RSVP reservations. 931 Figure 10 illustrates such an environment. 933 |-------------| 934 ////////////| Application |\\\\\\\\\ 935 / | Entity | \ 936 / |-------------| \ 937 / /=/ \ 938 / /=/ \ 939 / /=/ \ 940 / /=/ \ 941 / /=/ \ 942 / /=/ \ 943 / /=/ \ 944 / /=/ \ 945 |----| |--------| *** |----| 946 | S |-----------| RSVP |-----------*r*-----------------| R | 947 |----| | Sender | *** |----| 948 | Proxy | 949 |--------| 951 =========RSVP====================> 953 *****************************************************> 955 |----| non-RSVP-capable |----| RSVP-capable *** 956 | S | Sender | R | Receiver *r* regular RSVP 957 |----| |----| *** router 959 ***> media flow 961 ==> segment of flow path protected by RSVP reservation 963 /\ Application level signaling 965 /=/ GRE-tunnelled RSVP (Path messages) 967 Figure 10: Application-Entity-Controlled Sender Proxy via "RSVP over 968 GRE" 970 With the Application_Entity-Controlled Sender Proxy using "RSVP Over 971 GRE", the application entity : 973 o generates a Path message on behalf of the sender, corresponding to 974 the reservation needed by the application and maintains the 975 corresponding Path state. The Path message built by the 976 application entity is exactly the same as would be built by the 977 actual sender (if it was RSVP-capable), with one single exception 978 which is that the Application Entity puts its own IP address as 979 the RSVP Previous Hop. In particular, it is recommended that the 980 source address of the Path message built by the application entity 981 be set to the IP address of the sender (not of the application 982 entity). This helps ensuring that, in the presence of non-RSVP 983 routers and of load-balancing in the network where the load- 984 balancing algorithm takes into account the source IP address, the 985 Path message generated by the application entity follows the exact 986 same path that the actual stream sourced by the sender. 988 o encapsulates the Path message into a GRE tunnel whose destination 989 address is the RSVP Sender Proxy i.e. an RSVP Router sitting on 990 the datapath for the flow (and upstream of the segment which 991 requires QoS guarantees via RSVP reservation). 993 o processes the corresponding received RSVP messages (including Resv 994 messages) as per regular RSVP. 996 o synchronizes the RSVP reservation state with application level 997 requirements and signaling. 999 Note that since the application entity encodes its own IP address as 1000 the previous RSVP hop inside the [RFC2205] RSVP_HOP object of the 1001 Path message, the RSVP Router terminating the GRE tunnel naturally 1002 addresses all the RSVP messages travelling upstream hop-by-hop (such 1003 as Resv messages) to the application entity (without having to 1004 encapsulate those in a reverse-direction GRE tunnel towards the 1005 application entity). 1007 4.5.2. Application_Entity-Controlled Proxy via Co-Location 1009 This approach is simply a particular case of the more general 1010 Application_Entity-Controlled Proxy, but where the application entity 1011 is co-located with the RSVP Proxy. As an example, Session Border 1012 Controllers (SBC) with on-board SIP agents could implement RSVP Proxy 1013 functions and make use of such an approach to achieve session 1014 admission control over the SBC-to-SBC segment using RSVP signaling. 1016 Figure 11 illustrates operations of the Application_Entity-Controlled 1017 RSVP Proxy via Co-location. 1019 |---------| |---------| 1020 ////////| App |////////\\\\\\\| App |\\\\\\\\\ 1021 / | Entity | | Entity | \ 1022 / | | | | \ 1023 |----| |---------| *** |---------| |----| 1024 | S |--------| RSVP |------*r*------| RSVP |---------| R | 1025 |----| | Sender | *** | Receiver| |----| 1026 | Proxy | | Proxy | 1027 |---------| |---------| 1029 =======RSVP======> 1031 *******************************************************> 1033 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 1034 | S | Sender | R | Receiver *r* regular RSVP 1035 |----| |----| *** router 1037 ***> media flow 1039 ==> segment of flow path protected by RSVP reservation 1041 /\ Application level signaling 1043 Figure 11: Application_Entity-Controlled Proxy via Co-Location 1045 This RSVP Proxy approach does not require any protocol extensions. 1046 We also observe that when multiple sessions are to be established on 1047 paths sharing the same RSVP Sender Proxy and the same RSVP Receiver 1048 Proxy, the RSVP Proxies have the option to establish aggregate RSVP 1049 reservations (as defined in ([RFC3175] or [RFC4860]) for a group of 1050 sessions, instead of establishing one RSVP reservation per session. 1052 4.6. Policy_Server-Controlled Proxy 1054 In this approach, it is assumed that a Policy Server, which is 1055 located in the control plane of the network, controls an RSVP Proxy 1056 which is located in the datapath of the application flows (i.e. "on- 1057 path"). In turn, the Policy server is triggered by an entity 1058 involved in the application level signaling. With this approach, the 1059 RSVP Proxy does not attempt to determine itself the application 1060 reservation requirements, but instead is instructed by the Policy 1061 Server to establish, maintain and tear down reservations as needed by 1062 the application flows. Moreover, the entity participating in 1063 application level signaling does not attempt to understand the 1064 specific reservation mechanism (i.e. RSVP) or the topology of the 1065 network layer, but instead it simply asks the policy server to 1066 perform (or tear down) a reservation. In other words, with this 1067 approach, the solution for synchronizing RSVP signaling with 1068 application level requirements is to rely on an application level 1069 entity that controls a policy server that, in turn, controls an RSVP 1070 Proxy function that sits in the flow datapath. This approach allows 1071 control of an RSVP Sender Proxy, an RSVP Receiver Proxy or both. 1073 Operation of the Policy_Server-Controlled Proxy is illustrated 1074 Figure 12. 1076 |---------| 1077 /////////////| App |\\\\\\\\\\\\\\ 1078 / | Entity | \ 1079 / |---------| \ 1080 / I \ 1081 / I \ 1082 / |----------| \ 1083 / | Policy | \ 1084 / | Server | \ 1085 / |----------| \ 1086 / // \\ \ 1087 / // \\ \ 1088 / // \\ \ 1089 |----| |--------| *** |---------| |----| 1090 | S |-----------| |------*r*-----| |----------| R | 1091 |----| | RSVP | *** | RSVP | |----| 1092 | Sender | | Receiver| 1093 | Proxy | | Proxy | 1094 |--------| |---------| 1096 =====RSVP========> 1098 **********************************************************> 1100 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 1101 | S | Sender | R | Receiver *r* regular RSVP 1102 |----| |----| *** router 1104 ***> media flow 1106 ==> segment of flow path protected by RSVP reservation 1108 /\ Application signaling (e.g. SIP) 1110 // RSVP Proxy control interface 1112 I Interface between Application Entity and Policy Server 1114 Figure 12: Policy_Server-Controlled Proxy 1116 This RSVP Proxy approach does not require any extension to the RSVP 1117 protocol. However, as with the Application_Entity-Controlled Proxy 1118 approach presented in Figure 9, this approach relies on an RSVP Proxy 1119 control interface allowing control of the RSVP Proxy (by the Policy 1120 Server in this case). This RSVP Proxy control interface is beyond 1121 the scope of the present document. Considerations about candidate 1122 protocols for realizing such interface can be found in Section 4.5. 1124 Again, for situations where only the RSVP Sender Proxy has to be 1125 controlled by this interface, the interface may be realized through 1126 the simple use of RSVP Itself, over a GRE tunnel from the Policy 1127 Server to the RSVP Sender Proxy. This is similar to what is 1128 presented in Section 4.5.1 except that the "RSVP over GRE" interface 1129 is used in this case by the Policy Server (instead of the application 1130 entity). 1132 The interface between the Application Entity and the Policy Server is 1133 beyond the scope of this document. 1135 4.7. RSVP-Signaling-Triggered Proxy 1137 An RSVP Proxy can also be triggered and controlled through extended 1138 RSVP signaling from the remote end that is RSVP-capable (and supports 1139 these RSVP extensions for Proxy control). For example, an RSVP 1140 capable sender could send a new or extended RSVP message explicitly 1141 requesting an RSVP Proxy on the path towards the receiver to behave 1142 as an RSVP Receiver Proxy and also to trigger a reverse direction 1143 reservation thus also behaving as a RSVP Sender Proxy. The new or 1144 extended RSVP message sent by the sender could also include 1145 attributes (e.g. bandwidth) for the reservations to be signaled by 1146 the RSVP Proxy. 1148 The challenges in these explicit signaling schemes include: 1150 o How can the nodes determine when a reservation request ought to be 1151 proxied and when it should not, and accordingly invoke appropriate 1152 signaling procedures? 1154 o How does the node sending the messages explicitly triggering the 1155 Proxy know where the Proxy is located, e.g., determine an IP 1156 address of the proxy that should reply to the signaling? 1158 o How is all the information needed by a Sender Proxy to generate a 1159 Path message actually communicated to the Proxy? 1161 An example of such a mechanism is presented in 1162 [I-D.manner-tsvwg-rsvp-proxy-sig]. This scheme is primarily targeted 1163 to local access network reservations whereby an end host can request 1164 resource reservations for both incoming and outgoing flows only over 1165 the access network. This may be useful in environments where the 1166 access network is typically the bottleneck while the core is 1167 comparatively over-provisioned, as may be the case with a number of 1168 radio access technologies. In this proposal, messages targeted to 1169 the Proxy are flagged with one bit in all RSVP messages. Similarly, 1170 all RSVP messages sent back by the Proxy are also flagged. The use 1171 of such a flag allows differentiating between proxied and end-to-end 1172 reservations. For triggering an RSVP Receiver Proxy, the sender of 1173 the data sends a Path message which is marked with the mentioned 1174 flag. The Receiver Proxy is located on the signaling and data path, 1175 eventually gets the Path message, and replies back with a Resv 1176 message. A node triggers an RSVP Sender Proxy with a newly defined 1177 Path_Request message, which instructs the proxy to send Path messages 1178 towards the triggering node. The node then replies back with a Resv. 1179 More details can be found in [I-D.manner-tsvwg-rsvp-proxy-sig]. 1181 Such an RSVP-Signaling-Triggered Proxy approach would require RSVP 1182 signaling extensions (that are outside the scope of the present 1183 document). However it could provide more flexibility in the control 1184 of the Proxy behavior (e.g. control of reverse reservation 1185 parameters) than provided by the Path-Triggered approaches defined in 1186 Section 4.1 and Section 4.2. 1188 Through potential corresponding protocol extensions, an RSVP- 1189 Signaling-Triggered Proxy approach could facilitate operation (e.g. 1190 reduce or avoid the need for associated configuration) in hybrid 1191 environments involving both reservations established end-to-end and 1192 reservations established via RSVP Proxies. For 1193 example,[I-D.manner-tsvwg-rsvp-proxy-sig] proposed a mechanism 1194 allowing an end-system to control whether a reservation can be 1195 handled by an RSVP Proxy on the path or is to be established end-to- 1196 end. 1198 4.8. Reachability Considerations 1200 There may be situations where the RSVP Receiver Proxy is reachable by 1201 the sender, while the receiver itself is not. In such situations, it 1202 is possible that the RSVP Receiver Proxy is not always aware that the 1203 receiver is unreachable, and consequently may accept to establish an 1204 RSVP reservation on behalf of that receiver. This would result in 1205 unnecessary reservation establishment and unnecessary network 1206 resource consumption. 1208 This is not considered a significant practical concern for a number 1209 of reasons. First, in many cases, if the receiver is not reachable 1210 from the sender, it will not be reachable either for application 1211 signaling so that application level session establishment will not be 1212 possible in the first place. Secondly, where the receiver is 1213 unreachable from the sender but is reachable for application level 1214 signaling (say because session establishment is performed through an 1215 off-path SIP agent that uses a different logical topology to 1216 communicate with the receiver), then the sender may detect that the 1217 receiver is unreachable before attempting reservation establishment. 1218 This may be achieved through mechanisms such as ICE's connectivity 1219 check ( [I-D.ietf-mmusic-ice]). Finally, even if the sender does not 1220 detect that the receiver is unreachable before triggering the RSVP 1221 reservation establishment, it is very likely that the application 1222 will quickly realise this lack of connectivity (e.g. the human 1223 accepting the phone call on the receiver side will not hear the 1224 human's voice on the sender side) and therefore tear down the session 1225 (e.g. hang up the phone) which in turn will trigger RSVP reservation 1226 release. 1228 Nonetheless, it is recommended that network administrators consider 1229 the above in light of their particular environment when deploying 1230 RSVP Proxys. 1232 The mirror considerations apply for situations involving an RSVP 1233 Sender Proxy and where the sender cannot reach the destination while 1234 the RSVP Sender Proxy can. 1236 5. Security Considerations 1238 In the environments of concern for this document, RSVP messages are 1239 used to control resource reservations on a segment of the end-to-end 1240 path of flows. The general security considerations associated with 1241 [RFC2205] apply. To ensure the integrity of the associated 1242 reservation and admission control mechanisms, the cryptographic 1243 authentication mechanisms defined in [RFC2747]] and [RFC3097] can be 1244 used. Those protect RSVP messages integrity hop-by-hop and provide 1245 node authentication, thereby protecting against corruption, spoofing 1246 of RSVP messages and replay. 1247 [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types and 1248 key provisioning methods as well as their respective applicability to 1249 RSVP authentication and RSVP encryption (e.g. [RFC4303]). 1251 A number of additional security considerations apply to the use of 1252 RSVP proxies and are discussed below. 1254 With some RSVP Proxy approaches, the RSVP proxy operates autonomously 1255 inside an RSVP router. This is the case for the Path-Triggered Proxy 1256 approaches defined in Section 4.1 and in Section 4.2, for the 1257 Inspection-Triggered Proxy approach defined in Section 4.3, for the 1258 STUN-Triggered Proxy approach defined in Section 4.4 and for the 1259 RSVP-Signaling-Triggered approach defined in Section 4.7. Proper 1260 reservation operation assumes that the RSVP proxy can be trusted to 1261 behave correctly in order to control the RSVP reservation as required 1262 and expected by the end systems. Since, the basic RSVP operation 1263 already assumes a trust model where end-systems trust RSVP nodes to 1264 appropriately perform RSVP reservations, the use of RSVP proxy that 1265 behave autonomously within an RSVP router is not seen as introducing 1266 any significant additional security threat or as fundamentally 1267 modifying the RSVP trust model. 1269 With some RSVP Proxy approaches, the RSVP proxy operate under the 1270 control of another entity. This is the case for the 1271 Application_Entity-Controlled Proxy approach defined in Section 4.5 1272 and for the Policy_Server-Controlled Proxy approach defined in 1273 Section 4.6. This introduces additional security risks since the 1274 entity controlling the RSVP Proxy needs to be trusted for proper 1275 reservation operation. The exact mechanisms to establish such trust 1276 are beyond the scope of this document, but they may include security 1277 mechanisms inside the protocol used as the control interface between 1278 the RSVP Proxy and the entity controlling it, as well as security 1279 mechanisms for all the interfaces involved in the reservation control 1280 chain (e.g. inside the application signaling protocol between the end 1281 systems and the application entity, and, in the case of the 1282 Policy_Server-Controlled Proxy approach, in the protocol between the 1283 application entity and the policy server). 1285 In some situations, the use of RSVP Proxy to control reservations on 1286 behalf of end-systems may actually reduce the security risk (at least 1287 from the network operator viewpoint). This could be the case, for 1288 example, because the routers where the RSVP Proxy functionality runs 1289 are less exposed to tampering than end-systems. Such a case is 1290 further discussed in section 4 of [I-D.ietf-tsvwg-rsvp-proxy-proto]. 1292 6. IANA Considerations 1294 This document does not make any request to IANA registration. 1296 7. Acknowledgments 1298 This document benefited from earlier work on the concept of RSVP 1299 Proxy including the one documented by Silvano Gai, Dinesh Dutt, 1300 Nitsan Elfassy and Yoram Bernet. It also benefited from discussions 1301 with Pratik Bose, Chris Christou and Michael Davenport. Tullio 1302 Loffredo and Massimo Sassi provided the base material for 1303 Section 4.6. Thanks to James Polk and Magnus Westerlund for their 1304 thorough review and comments. 1306 8. Informative References 1308 [I-D.ietf-dime-diameter-qos] 1309 Zorn, G., "Protocol for Diameter Quality of Service 1310 Application", November 2007. 1312 [I-D.ietf-mmusic-ice] 1313 Rosenberg, J., "Interactive Connectivity Establishment 1314 (ICE): A Protocol for Network Address Translator (NAT) 1315 Traversal for Offer/Answer Protocols", 1316 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1318 [I-D.ietf-mmusic-qos-identification] 1319 Polk, J., Dhesikan, S., and G. Camarillo, "Quality of 1320 Service (QoS) Mechanism Selection in the Session 1321 Description Protocol (SDP)", 1322 draft-ietf-mmusic-qos-identification-02 (work in 1323 progress), October 2008. 1325 [I-D.ietf-nsis-qos-nslp] 1326 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 1327 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 1328 (work in progress), February 2008. 1330 [I-D.ietf-sipping-sbc-funcs] 1331 Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 1332 A., and M. Bhatia, "Requirements from SIP (Session 1333 Initiation Protocol) Session Border Control Deployments", 1334 April 2007. 1336 [I-D.ietf-tsvwg-rsvp-proxy-proto] 1337 Faucheur, F., Manner, J., Narayanan, A., Guillou, A., and 1338 L. Faucheur, "RSVP Extensions for Path-Triggered RSVP 1339 Receiver Proxy", draft-ietf-tsvwg-rsvp-proxy-proto-07 1340 (work in progress), July 2008. 1342 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 1343 Behringer, M. and F. Faucheur, "Applicability of Keying 1344 Methods for RSVP Security", 1345 draft-ietf-tsvwg-rsvp-security-groupkeying-01 (work in 1346 progress), July 2008. 1348 [I-D.manner-tsvwg-rsvp-proxy-sig] 1349 Manner, J., "Localized RSVP for Controlling RSVP Proxies", 1350 October 2006. 1352 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1353 Services in the Internet Architecture: an Overview", 1354 RFC 1633, June 1994. 1356 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1357 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1358 Functional Specification", RFC 2205, September 1997. 1360 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1361 Services", RFC 2210, September 1997. 1363 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1364 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1366 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1367 and W. Weiss, "An Architecture for Differentiated 1368 Services", RFC 2475, December 1998. 1370 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1371 Authentication", RFC 2747, January 2000. 1373 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1374 and S. Molendini, "RSVP Refresh Overhead Reduction 1375 Extensions", RFC 2961, April 2001. 1377 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 1378 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 1379 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 1380 RFC 3084, March 2001. 1382 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 1383 Authentication -- Updated Message Type Value", RFC 3097, 1384 April 2001. 1386 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1387 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 1388 RFC 3175, September 2001. 1390 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1391 A., Peterson, J., Sparks, R., Handley, M., and E. 1392 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1393 June 2002. 1395 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 1396 "Integration of Resource Management and Session Initiation 1397 Protocol (SIP)", RFC 3312, October 2002. 1399 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 1400 Simple Network Management Protocol (SNMP)", STD 62, 1401 RFC 3416, December 2002. 1403 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1404 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1406 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 1407 Moore, "Policy Quality of Service (QoS) Information 1408 Model", RFC 3644, November 2003. 1410 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1411 Internet Protocol", RFC 4301, December 2005. 1413 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1414 RFC 4303, December 2005. 1416 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1417 Description Protocol", RFC 4566, July 2006. 1419 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 1420 Davenport, "Generic Aggregate Resource ReSerVation 1421 Protocol (RSVP) Reservations", RFC 4860, May 2007. 1423 [RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling 1424 in a Nested Virtual Private Network", RFC 4923, 1425 August 2007. 1427 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1428 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1429 October 2008. 1431 Appendix A. Use Cases for RSVP Proxies 1433 A.1. RSVP-based VoD CAC in Broadband Aggregation Networks 1435 As broadband services for residential are becoming more and more 1436 prevalent, next generation aggregation networks are being deployed in 1437 order to aggregate traffic from broadband users (whether attached via 1438 Digital Subscriber Line technology aka DSL, Fiber To The Home/Curb 1439 aka FTTx, Cable or other broadband access technology). Video on 1440 Demand (VoD) services which may be offered to broadband users present 1441 significant capacity planning challenges for the aggregation network 1442 for a number of reasons. First each VoD stream requires significant 1443 dedicated sustained bandwidth (typically 2-4 Mb/s in Standard 1444 Definition TV and 6-12 Mb/s in High Definition TV). Secondly, the 1445 VoD codec algorithms are very sensitive to packet loss. Finally, the 1446 load resulting from such services is very hard to predict (e.g. it 1447 can vary very suddenly with block-buster titles made available as 1448 well as with promotional offerings). As a result, transport of VoD 1449 streams on the aggregation network usually translate into a strong 1450 requirement for admission control. The admission control solution 1451 protects the quality of established VoD sessions by rejecting the 1452 additional excessive session attempts during unpredictable peaks, 1453 during link or node failures, or combination of those factors. 1455 RSVP can be used in the aggregation network for admission control of 1456 the VoD sessions. However, since Customer Premises equipment such as 1457 Set Top Boxes (which behave as the receiver for VoD streams) often do 1458 not support RSVP, the last IP hop in the aggregation network can 1459 behave as an RSVP Receiver Proxy. This way, RSVP can be used between 1460 VoD Pumps and the last IP hop in the Aggregation network to perform 1461 accurate admission control of VoD streams over the resources set 1462 aside for VoD in the aggregation network (typically a certain 1463 percentage of the bandwidth of any link). As VoD streams are 1464 unidirectional, a simple "Path-Triggered" RSVP Receiver Proxy (as 1465 described in Section 4.1) is all that is required in this use case. 1467 The Figure below illustrates operation of RSVP-based admission 1468 control of VoD sessions in an Aggregation network involving RSVP 1469 support on the VoD Pump (the senders) and RSVP Receiver Proxy on the 1470 last IP hop of the aggregation network. All the customer premises 1471 equipment remain RSVP unaware. 1473 |-------------| 1474 | VoD SRM | 1475 | | 1476 ////////| |\\\\\\\\\\\\\\\ 1477 / |-------------| \ 1478 / \ 1479 / \ 1480 / \ 1481 / \ 1482 / \ 1483 |----| |------| *** *** |--------| |-----| |---| 1484 | VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV 1485 |Pump| |Router| *** *** |Receiver| |-----| |---| 1486 |----| |------| |Proxy | 1487 |--------| 1489 <---Aggregation Net-------------> 1491 ******************************************************> 1493 ============RSVP====================> 1495 SRM Session Resource Manager 1497 *** |---| 1498 *r* regular RSVP |STB| Set Top Box 1499 *** router |---| 1501 ***> VoD media flow 1503 ==> segment of flow path protected by RSVP reservation 1505 /\ VoD Application level signaling (e.g. RTSP) 1507 Figure 13: VoD Use Case with Receiver Proxy 1509 In the case where the VoD Pumps are not RSVP-capable, an 1510 Application_Entity-Controlled Sender Proxy via "RSVP over GRE" 1511 approach (as described in Section 4.5.1) can also be implemented on 1512 the VoD Controller or Session Resource Manager (SRM) devices 1513 typically involved in VoD deployments. Figure 14 illustrates 1514 operation of RSVP-based admission control of VoD sessions in an 1515 Aggregation network involving such Application_Entity-Controlled 1516 Source Proxy combined with an RSVP Receiver Proxy on the last IP hop 1517 of the aggregation network. All the customer premises equipment, as 1518 well as the VoD pumps, remain RSVP unaware. 1520 |-------------| 1521 ////| VoD SRM |\\\\\\\\\\\ 1522 / | | \ 1523 / | + | \ 1524 / | RSVP Sender | \ 1525 / |Proxy Control| \ 1526 / |-------------| \ 1527 / /=/ \ 1528 / /=/ \ 1529 / /=/ \ 1530 / /=/ \ 1531 / /=/ \ 1532 |----| |------| *** *** |--------| |-----| |---| 1533 | VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV 1534 |Pump| |Sender| *** *** |Receiver| |-----| |---| 1535 |----| |Proxy | |Proxy | 1536 |------| |--------| 1538 <---Aggregation Net-------------> 1540 ******************************************************> 1542 =========RSVP==============> 1544 SRM Systems Resource Manager 1546 *** |---| 1547 *r* regular RSVP |STB| Set Top Box 1548 *** router |---| 1550 ***> VoD media flow 1552 ==> segment of flow path protected by RSVP reservation 1554 / VoD Application level signaling (e.g. RTSP) 1556 /=/ GRE-tunnelled RSVP (Path messages) 1558 Figure 14: VoD Use Case with Receiver Proxy and SRM-based Sender 1559 Proxy 1561 The RSVP Proxy entities specified in this document play a significant 1562 role here since they allow immediate deployment of an RSVP-based 1563 admission control solution for VoD without requiring any upgrade to 1564 the huge installed base of non-RSVP-capable customer premises 1565 equipment. In one mode described above, they also avoid upgrade of 1566 non-RSVP-capable VoD pumps. In turn, this means that the benefits of 1567 on-path admission control can be offered to VoD services over 1568 broadband aggregation networks without network or VoD Pump upgrade. 1569 Those include accurate bandwidth accounting regardless of topology 1570 (hub-and-spoke, ring, mesh, star, arbitrary combinations) and dynamic 1571 adjustment to any change in topology (such as failure, routing 1572 change, additional links...). 1574 A.2. RSVP-based Voice/Video CAC in Enterprise WAN 1576 More and more enterprises are migrating their telephony and 1577 videoconferencing applications onto IP. When doing so, there is a 1578 need for retaining admission control capabilities of existing TDM- 1579 based systems to ensure the QoS of these applications is maintained 1580 even when transiting through the enterprise's Wide Area Network 1581 (WAN). Since many of the endpoints already deployed (such as IP 1582 Phones or Videoconferencing terminals) are not RSVP capable, RSVP 1583 Proxy approaches are very useful: they allow deployment of an RSVP- 1584 based admission control solution over the WAN without requiring 1585 upgrade of the existing terminals. 1587 A common deployment architecture for such environments relies on the 1588 Application_Entity-Controlled Proxy approach as defined in 1589 Section 4.5. Routers sitting at the edges of the WAN network and 1590 naturally "on-path" for all inter-campus calls (or sessions) and 1591 behave as RSVP Proxies. The RSVP Proxies establish, maintain and 1592 tear-down RSVP reservations over the WAN segment for the calls (or 1593 sessions) under the control of the SIP Server/Proxy. The SIP Server/ 1594 Proxy synchronizes the RSVP reservation status with the status of 1595 end-to-end calls. For example, the called IP phone will only be 1596 instructed to play a ring tone if the RSVP reservations over the 1597 corresponding WAN segment has been successfully established. 1599 This architecture allowing RSVP-based admission control of voice and 1600 video on the Enterprise WAN is illustrated in Figure 15. 1602 |---------| 1603 //////////////| SIP |\\\\\\\\\\\\ 1604 / | Server/ | \ 1605 / | Proxy | \ 1606 / |---------| \ 1607 / // \\ \ 1608 / // \\ \ 1609 / // \\ \ 1610 / // \\ \ 1611 / // \\ \ 1612 |-----| |--------| *** *** |--------| |-----| 1613 | IP |------| Media |---*r*---*r*---| Media |-------|IP | 1614 |Phone| | Relay | *** *** | Relay | |Phone| 1615 |-----| | + | | + | |-----| 1616 | RSVP | | RSVP | 1617 | Proxy | | Proxy | 1618 |--------| |--------| 1620 <--campus--> <--campus--> 1621 network network 1623 <---------WAN-----------> 1625 <*************> <***********************> <**************> 1627 <=========RSVP===========> 1629 *** 1630 *r* Regular RSVP router 1631 *** 1633 <***> media flow 1635 <==> segment of flow path protected by RSVP reservation 1637 /\ SIP signaling 1639 // control interface between the SIP Server/Proxy and 1640 RSVP Proxy 1642 Figure 15: CAC on Enterprise WAN Use Case 1644 A.3. RSVP-based Voice CAC in Telephony Service Provider Core 1646 Let us consider an environment involving a Telephony Service Provider 1647 (TSP). Let us further assume that end-users are attached to the TSP 1648 via Session Border Controllers (SBCs). The SBCs may be remotely 1649 controlled by a SIP Server. The SIP Server may control establishment 1650 of RSVP reservations between the SBCs for admission control of 1651 sessions over the core. This relies on the Application_Entity- 1652 Controlled RSVP Proxy approach presented in Section 4.5. This is 1653 illustrated in the Figure below. 1655 |---------| 1656 //////////////| SIP |\\\\\\\\\\\\ 1657 / | Server/ | \ 1658 / | Proxy | \ 1659 / |---------| \ 1660 / // \\ \ 1661 / // \\ \ 1662 / // \\ \ 1663 / // \\ \ 1664 / // \\ \ 1665 |-----| |--------| *** *** |--------| |-----| 1666 | IP |------| |---*r*---*r*---| |-------|IP | 1667 |Phone| | SBC | *** *** | SBC | |Phone| 1668 |-----| | + | | + | |-----| 1669 | RSVP | | RSVP | 1670 | Proxy | | Proxy | 1671 |--------| |--------| 1673 <---Access----> <---Access-----> 1674 <---------Core----------> 1676 <*************> <***********************> <**************> 1678 <=========RSVP==========> 1680 *** 1681 *r* Regular RSVP router 1682 *** 1684 <***> media flow 1686 <==> segment of flow path protected by RSVP reservation 1688 /\ SIP signaling 1690 // control interface between the SIP Server/Proxy and 1691 SBC/RSVP Proxy 1693 Figure 16: Voice CAC in TSP Domain 1695 A.4. RSVP Proxies for Mobile Access Networks 1697 Mobile access networks are increasingly based on IP technology. This 1698 implies that, on the network layer, all traffic, both traditional 1699 data and streamed data like audio or video, is transmitted as 1700 packets. Increasingly popular multimedia applications would benefit 1701 from better than best-effort service from the network, a forwarding 1702 service with strict Quality of Service (QoS) with guaranteed minimum 1703 bandwidth and bounded delay. Other applications, such as electronic 1704 commerce, network control and management, and remote login 1705 applications, would also benefit from a differentiated treatment. 1707 The IETF has two main models for providing differentiated treatment 1708 of packets in routers. The Integrated Services (IntServ) model 1709 [RFC1633] together with the Resource Reservation Protocol (RSVP) 1710 [RFC2205] [RFC2210] [RFC2961] provides per-flow guaranteed end-to-end 1711 transmission service. The Differentiated Services (DiffServ) 1712 framework [RFC2475] provides non- signaled flow differentiation that 1713 usually provides, but does not guarantee, proper transmission 1714 service. 1716 However, these architectures have potential weaknesses for deployment 1717 in Mobile Access Networks. For example, RSVP requires support from 1718 both communication end points, and the protocol may have potential 1719 performance issues in mobile environments. DiffServ can only provide 1720 statistical guarantees and is not well suited for dynamic 1721 environments. 1723 Let us consider a scenario, where a fixed network correspondent node 1724 (CN) would be sending a multimedia stream to an end host behind a 1725 wireless link. If the correspondent node does not support RSVP it 1726 cannot signal its traffic characteristics to the network and request 1727 specific forwarding services. Likewise, if the correspondent node is 1728 not able to mark its traffic with a proper DiffServ Code Point (DSCP) 1729 to trigger service differentiation, the multimedia stream will get 1730 only best-effort service which may result in poor visual and audio 1731 quality in the receiving application. Even if the connecting wired 1732 network is over-provisioned, an end host would still benefit from 1733 local resource reservations, especially in wireless access networks, 1734 where the bottleneck resource is most probably the wireless link. 1736 RSVP proxies would be a very beneficial solution to this problem. It 1737 would allow distinguishing local network reservations from the end- 1738 to-end reservations. The end host does not need to know the access 1739 network topology or the nodes that will reserve the local resources. 1740 The access network would do resource reservations for both incoming 1741 and outgoing flows based on certain criterion, e.g., filters based on 1742 application protocols. Another option is that the mobile end host 1743 makes an explicit reservation that identifies the intention and the 1744 access network will find the correct local access network node(s) to 1745 respond to the reservation. RSVP proxies would, thus, allow resource 1746 reservation over the segment which is the most likely bottleneck, the 1747 wireless connectivity. If the wireless access network uses a local 1748 mobility management mechanism, where the IP address of the mobile 1749 node does not change during handover, RSVP reservations would follow 1750 the mobile node movement. 1752 A.5. RSVP Proxies for Reservations in the presence of IPsec Gateways 1754 [RFC4923] discusses how resource reservation can be supported end-to- 1755 end in a nested VPN environment. At each VPN level, VPN Routers 1756 behave as [RFC4301] security gateways between a plaintext domain and 1757 a cyphertext domain. To achieve end-to-end resource reservation, the 1758 VPN Routers process RSVP signaling on the plaintext side, perform 1759 aggregation of plaintext reservations, and maintain the corresponding 1760 aggregate RSVP reservations on the cyphertext side. Each aggregate 1761 reservation is established on behalf of multiple encrypted end-to-end 1762 sessions sharing the same ingress and egress VPN Routers. These 1763 aggregate reservations can be as specified in [RFC3175] or [RFC4860]. 1765 Section 3 of [RFC4923] discusses the necessary data flows within a 1766 VPN Router to achieve the behavior described in the previous 1767 paragraph. Two mechanisms are described to achieve such data flows. 1768 Section 3.1 presents the case where the VPN Router carries data 1769 across the cryptographic boundary. Section 3.2 discusses the case 1770 where the VPN router uses a Network-Guard. 1772 Where such mechanisms are not supported by the VPN Routers, the 1773 approach for end-to-end reservation presented in [RFC4923] cannot be 1774 deployed. An alternative approach to support resource reservations 1775 within the cyphertext core is to use the "Application_Entity- 1776 Controlled Proxy" approach (as defined in Section 4.5) in the 1777 following way: 1779 o the RSVP Proxies are located inside the cyphertext domain and use 1780 aggregate RSVP reservations, 1782 o the Application Entity exchange application level signaling with 1783 the end systems in the plaintext domain, 1785 o the Application Entity controls the RSVP Proxies in the cyphertext 1786 domain via an RSVP Proxy control interface 1788 This is illustrated in Figure 17 in the case where the application is 1789 SIP-based multimedia communications. 1791 |-------| |-------| 1792 |SIP |///////////////////\\\\\\\\\\\\\\\\\|SIP | 1793 /|Server/| |Server/|\ 1794 / |Proxy | |Proxy | \ 1795 / |-------| |-------| \ 1796 / ^ \\ // ^ \ 1797 / ^ \\ // ^ \ 1798 / ^ \\ // ^ \ 1799 |---| |------| |--------| *** *** |--------| |------| |---| 1800 | S |---|IPsec |--| ARSVP |---*r*---*r*---| ARSVP |--|IPsec |---| R | 1801 |---| | GW | | Sender | *** *** |Receiver| | GW | |---| 1802 |------| | Proxy | | Proxy | |------| 1803 |--------| |--------| 1805 ***PT*****> **********************CT****************> ****PT***> 1807 =====> =====> 1808 =====ARSVP======> 1810 |----| RSVP-capable |----| RSVP-capable *** 1811 | S | Sender | R | Receiver *r* regular RSVP 1812 |----| |----| *** router 1814 |------| 1815 |IPsec | IPsec security gateway 1816 | GW | 1817 |------| 1819 ARSVP Aggregate RSVP 1821 ***> media flow 1823 ==> segment of flow path protected by RSVP reservation 1825 / \ SIP signaling 1827 ^ Network management interface between SIP Server/Proxy 1828 and IPsec security gateway 1830 // control interface between SIP Server/Proxy and ARSVP Proxy 1832 PT Plaintext network 1834 CT Cyphertext network 1836 Figure 17: RSVP Proxies for Reservations in the Presence of IPsec 1837 Gateways 1839 Where the sender and receiver are RSVP capable, they may also use 1840 RSVP signaling. This achieves resource reservation on the plaintext 1841 segments of the end-to-end i.e. : 1843 o from the sender to the ingress IPsec gateway and 1845 o from the egress IPsec gateway to the receiver. 1847 In this use case, because the VPN Routers do not support any RSVP 1848 specific mechanism, the end-to-end RSVP signaling is effectively 1849 hidden by the IPsec gateways on the cyphertext segment of the end-to- 1850 end path. 1852 As with the "Application_Entity-Controlled Proxy" approach (defined 1853 in Section 4.5), the solution here for synchronizing RSVP signaling 1854 with application-level signaling is to rely on an application-level 1855 signaling device that controls an on-path RSVP Proxy function. 1856 However, in the present use case, the RSVP Proxies are a component of 1857 a cyphertext network where all user (bearer) traffic is IPsec 1858 encrypted. This has a number of implications including the 1859 following: 1861 1. encrypted flows can not be identified in the cyphertext domain so 1862 that network nodes can only classify traffic based on IP address 1863 and DiffServ Code Points (DSCPs). As a result, only aggregate 1864 RSVP reservations (such as those specified in [RFC3175] or 1865 [RFC4860] ) can be used. This is similar to [RFC4923]. 1867 2. Determining the RSVP Sender proxy and RSVP receiver Proxy to be 1868 used for aggregation of a given flow from sender to receiver 1869 creates a number of challenges. Details on how this may be 1870 achieved are beyond the scope of this document. We observe that, 1871 as illustrated in Figure 17, this may be facilitated by a network 1872 management interface between the application entity and the IPsec 1873 gateways. For example, this interface may be used by the 1874 application entity to obtain information about which IPsec 1875 gateway is on the path of a given end-to-end flow. Then, the 1876 application entity may maintain awareness of which RSVP Proxy is 1877 on the cyphertext path between a given pair of IPsec gateways. 1878 How such awareness is achieved is beyond the scope of this 1879 document. We simply observe that such awareness can be easily 1880 achieved through simple configuration in the particular case 1881 where a single (physical or logical) RSVP Proxy is fronting a 1882 given IPsec gateway. We also observe that when awareness of the 1883 RSVP Receiver Proxy for a particular egress IPsec gateway (or 1884 end-to-end flow) is not available, the aggregate reservation may 1885 be signaled by the RSVP Sender Proxy to the destination address 1886 of the egress IPsec gateway and then proxied by the RSVP Receiver 1887 Proxy. 1889 Different flavors of operations are possible in terms of aggregate 1890 reservation sizing. For example, the application entity can initiate 1891 an aggregate reservation of fixed size a priori and then simply keep 1892 count of the bandwidth used by sessions and reject sessions that 1893 would result in excess usage of an aggregate reservation. The 1894 application entity could also re-size the aggregate reservations on a 1895 session by session basis. Alternatively, the application entity 1896 could re-size the aggregate reservations in step increments typically 1897 corresponding to the bandwidth requirement of multiple sessions. 1899 Authors' Addresses 1901 Francois Le Faucheur 1902 Cisco Systems 1903 Greenside, 400 Avenue de Roumanille 1904 Sophia Antipolis 06410 1905 France 1907 Phone: +33 4 97 23 26 19 1908 Email: flefauch@cisco.com 1910 Jukka Manner 1911 University of Helsinki 1912 P.O. Box 68 1913 University of Helsinki FIN-00014 University of Helsinki 1914 Finland 1916 Phone: +358 9 191 51298 1917 Email: jmanner@cs.helsinki.fi 1918 URI: http://www.cs.helsinki.fi/u/jmanner/ 1920 Dan Wing 1921 Cisco Systems 1922 170 West Tasman Drive 1923 San Jose, CA 95134 1924 United States 1926 Email: dwing@cisco.com 1927 Allan Guillou 1928 Neuf Cegetel 1929 40-42 Quai du Point du Jour 1930 Boulogne-Billancourt, 92659 1931 France 1933 Email: allan.guillou@neufcegetel.fr 1935 Full Copyright Statement 1937 Copyright (C) The IETF Trust (2008). 1939 This document is subject to the rights, licenses and restrictions 1940 contained in BCP 78, and except as set forth therein, the authors 1941 retain all their rights. 1943 This document and the information contained herein are provided on an 1944 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1945 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1946 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1947 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1948 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1949 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1951 Intellectual Property 1953 The IETF takes no position regarding the validity or scope of any 1954 Intellectual Property Rights or other rights that might be claimed to 1955 pertain to the implementation or use of the technology described in 1956 this document or the extent to which any license under such rights 1957 might or might not be available; nor does it represent that it has 1958 made any independent effort to identify any such rights. Information 1959 on the procedures with respect to rights in RFC documents can be 1960 found in BCP 78 and BCP 79. 1962 Copies of IPR disclosures made to the IETF Secretariat and any 1963 assurances of licenses to be made available, or the result of an 1964 attempt made to obtain a general license or permission for the use of 1965 such proprietary rights by implementers or users of this 1966 specification can be obtained from the IETF on-line IPR repository at 1967 http://www.ietf.org/ipr. 1969 The IETF invites any interested party to bring to its attention any 1970 copyrights, patents or patent applications, or other proprietary 1971 rights that may cover technology that may be required to implement 1972 this standard. Please address the information to the IETF at 1973 ietf-ipr@ietf.org.