idnits 2.17.1 draft-ietf-tsvwg-rsvp-proxy-approaches-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5157 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4032' is defined on line 1707, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-proxy-proto-10 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-05 -- 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 4741 (Obsoleted by RFC 6241) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG F. Le Faucheur 3 Internet-Draft Cisco 4 Intended status: Informational J. Manner 5 Expires: September 9, 2010 TKK 6 D. Wing 7 Cisco 8 A. Guillou 9 SFR 10 March 8, 2010 12 RSVP Proxy Approaches 13 draft-ietf-tsvwg-rsvp-proxy-approaches-09.txt 15 Abstract 17 The Resource ReSerVation Protocol (RSVP) can be used to make end-to- 18 end resource reservations in an IP network in order to guarantee the 19 quality of service required by certain flows. RSVP assumes that both 20 the data sender and receiver of a given flow take part in RSVP 21 signaling. Yet, there are use cases where resource reservation is 22 required, but the receiver, the sender, or both, is not RSVP-capable. 23 This document presents RSVP Proxy behaviors allowing RSVP routers to 24 initiate or terminate RSVP signaling on behalf of a receiver or a 25 sender that is not RSVP-capable. This allows resource reservations 26 to be established on a critical subset of the end-to-end path. This 27 document reviews conceptual approaches for deploying RSVP Proxies and 28 discusses how RSVP reservations can be synchronized with application 29 requirements, despite the sender, receiver, or both not participating 30 in RSVP. This document also points out where extensions to RSVP (or 31 to other protocols) may be needed for deployment of a given RSVP 32 Proxy approach. However, such extensions are outside the scope of 33 this document. Finally, practical use cases for RSVP Proxy are 34 described. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt. 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 This Internet-Draft will expire on September 9, 2010. 59 Copyright Notice 61 Copyright (c) 2010 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the BSD License. 74 This document may contain material from IETF Documents or IETF 75 Contributions published or made publicly available before November 76 10, 2008. The person(s) controlling the copyright in some of this 77 material may not have granted the IETF Trust the right to allow 78 modifications of such material outside the IETF Standards Process. 79 Without obtaining an adequate license from the person(s) controlling 80 the copyright in such materials, this document may not be modified 81 outside the IETF Standards Process, and derivative works of it may 82 not be created outside the IETF Standards Process, except to format 83 it for publication as an RFC or to translate it into languages other 84 than English. 86 Table of Contents 88 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 89 2. RSVP Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 6 90 2.1. RSVP Receiver Proxy . . . . . . . . . . . . . . . . . . . 6 91 2.2. RSVP Sender Proxy . . . . . . . . . . . . . . . . . . . . 7 92 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 93 4. RSVP Proxy Approaches . . . . . . . . . . . . . . . . . . . . 9 94 4.1. Path-Triggered Receiver Proxy . . . . . . . . . . . . . . 9 95 4.1.1. Mechanisms for Maximizing the Reservation Span . . . . 12 96 4.2. Path-Triggered Sender Proxy for Reverse Direction . . . . 16 97 4.3. Inspection-Triggered Proxy . . . . . . . . . . . . . . . . 19 98 4.4. STUN-Triggered Proxy . . . . . . . . . . . . . . . . . . . 22 99 4.5. Application_Entity-Controlled Proxy . . . . . . . . . . . 24 100 4.5.1. Application_Entity-Controlled Sender Proxy using 101 "RSVP over GRE" . . . . . . . . . . . . . . . . . . . 27 102 4.5.2. Application_Entity-Controlled Proxy via Co-Location . 29 103 4.6. Policy_Server-Controlled Proxy . . . . . . . . . . . . . . 30 104 4.7. RSVP-Signaling-Triggered Proxy . . . . . . . . . . . . . . 33 105 4.8. Reachability Considerations . . . . . . . . . . . . . . . 34 106 5. Security Considerations . . . . . . . . . . . . . . . . . . . 35 107 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 108 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 110 8.1. Normative References . . . . . . . . . . . . . . . . . . . 37 111 8.2. Informative References . . . . . . . . . . . . . . . . . . 38 112 Appendix A. Use Cases for RSVP Proxies . . . . . . . . . . . . . 40 113 A.1. RSVP-based VoD Admission Control in Broadband 114 Aggregation Networks . . . . . . . . . . . . . . . . . . . 40 115 A.2. RSVP-based Voice/Video CAC in Enterprise WAN . . . . . . . 44 116 A.3. RSVP Proxies for Mobile Access Networks . . . . . . . . . 45 117 A.4. RSVP Proxies for Reservations in the presence of IPsec 118 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 47 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 121 1. Introduction 123 Guaranteed Quality of Service (QoS) for some applications with tight 124 requirements (such as voice or video) may be achieved by reserving 125 resources in each node on the end-to-end path. The main IETF 126 protocol for these resource reservations is RSVP, specified in 127 [RFC2205]. RSVP does not require that all intermediate nodes support 128 RSVP, however it assumes that both the sender and the receiver of the 129 data flow support RSVP. There are environments where it would be 130 useful to be able to reserve resources for a flow on at least a 131 subset of the flow path even when the sender or the receiver (or 132 both) is not RSVP (for example from the sender to the network edge, 133 or from edge to edge, or from the network edge to the receiver). 135 Since the data sender or receiver may be unaware of RSVP, there are 136 two types of RSVP Proxies. When the sender is not using RSVP, an 137 entity in the network must operate on behalf of the data sender, and 138 in particular, generate RSVP Path messages, and eventually receive, 139 process and sink Resv messages. We refer to this entity as the RSVP 140 Sender Proxy. When the receiver is not using RSVP, an entity in the 141 network must receive Path messages sent by a data sender (or by an 142 RSVP Sender Proxy), sink those, and return Resv messages on behalf of 143 the data receiver(s). We refer to this entity as the RSVP Receiver 144 Proxy. The RSVP Proxies need to be on the data path in order to 145 establish the RSVP reservation; Note, however, that some of the 146 approaches described in this document allow the RSVP Proxies to be 147 controlled/triggered by an off-path entity. 149 The flow sender and receiver generally have at least some (if not 150 full) awareness of the application producing or consuming that flow. 151 Hence, the sender and receiver are in a natural position to 152 synchronize the establishment, maintenance and tear down of the RSVP 153 reservation with the application requirements. Similarly they are in 154 a natural position to determine the characteristics of the 155 reservation (bandwidth, QoS service,...) which best match the 156 application requirements. For example, before completing the 157 establishment of a multimedia session, the endpoints may decide to 158 establish RSVP reservations for the corresponding flows. Similarly, 159 when the multimedia session is torn down, the endpoints may decide to 160 tear down the corresponding RSVP reservations. For instance, 161 [RFC3312] discusses how RSVP reservations can be very tightly 162 synchronized by endpoints that uses the [RFC3261] Session Initiation 163 Protocol (SIP) for session control. 165 When RSVP reservation establishment, maintenance and tearing down is 166 to be handled by RSVP Proxies on behalf of an RSVP sender or 167 receiver, a key challenge for the RSVP Proxy is to determine when the 168 RSVP reservations need to be established, maintained and torn down 169 and to determine what are the characteristics (bandwidth, QoS 170 Service,...) of the required RSVP reservations matching the 171 application requirements. We refer to this problem as the 172 synchronization of RSVP reservations with application level 173 requirements. 175 The IETF Next Steps in Signaling (NSIS) working group is specifying a 176 new QoS signaling protocol: the QoS NSIS Signaling Layer Protocol 177 (NSLP) ([I-D.ietf-nsis-qos-nslp]). This protocol also includes the 178 notion of proxy operation, and terminating QoS signaling on nodes 179 that are not the actual data senders or receivers (see section "4.8 180 Proxy Mode" of [I-D.ietf-nsis-qos-nslp]. This is the same concept as 181 the proxy operation for RSVP discussed in this document. One 182 difference though is that the NSIS framework does not consider 183 multicast resource reservations, which RSVP provides today. 185 Section 2 introduces the notion of RSVP Sender Proxy and RSVP 186 Receiver Proxy. Section 3 defines useful terminology. Section 4 187 then presents several fundamental RSVP Proxy approaches discussing 188 how they achieve the necessary synchronization of RSVP reservations 189 with application level requirements. Appendix A includes more 190 detailed use cases for the proxies in various real life deployment 191 environments. 193 It is important to keep in mind that the strongly recommended RSVP 194 deployment model remains end to end as assumed in [RFC2205] with RSVP 195 support on the sender and the receiver. The end to end model allows 196 the most effective synchronization between the reservation and 197 application requirements. Also, when compared to the end to end RSVP 198 model, the use of RSVP Proxies involves additional operational burden 199 and/or impose some topological constraints. The additional 200 operational burden comes in particular from additional configuration 201 needed to activate the RSVP Proxies and to help them identify for 202 which senders/receivers a Proxy behavior is required and for which 203 senders/receivers it is not (so that an RSVP Proxy does not perform 204 establishment of reservations on behalf of devices that are capable 205 of doing so themselves but would then be prevented -without 206 notification- from doing so by the RSVP Proxy). The additional 207 topological constraints come in particular from the requirement to 208 have one RSVP Receiver Proxy on the path from any sender to every 209 non-RSVP capable device (so that a non-RSVP capable device is always 210 taken care of by an RSVP Proxy) and the objective to have only one 211 such Receiver Proxy on the path from any sender to every non-RSVP 212 capable device (so that an RSVP Receiver Proxy does not short-circuit 213 another RSVP Receiver Proxy closer to the non-RSVP capable device, 214 thereby reducing the span of the RSVP reservation and the associated 215 benefits). In the case of the Path-triggered Receiver Proxy 216 approach, the operational burden and topological constraints can be 217 significantly alleviated using the mechanisms discussed in 218 Section 4.1.1. 220 It is also worth noting that RSVP operations on endsystems is 221 considerably simpler than on a router, and consequently that RSVP 222 implementations on endsystems are very lightweight (particularly 223 considering modern endsystems capabilities, including mobile and 224 portable devices). For example, endsystem RSVP implementations are 225 reported to only consume low tens of kilobytes of code space. Hence, 226 the present document should not be seen as an encouragement to depart 227 from the end to end RSVP model. Its purpose is only to allow RSVP 228 deployment in special environments where RSVP just cannot be used on 229 some senders and/or some receivers for reasons specific to the 230 environment. 232 2. RSVP Proxy Behaviors 234 This section discusses the two types of proxies; the RSVP Sender 235 Proxy operating on behalf of data senders, and the RSVP Receiver 236 Proxy operating for data receivers. The concepts presented in this 237 document are not meant to deprecate the traditional [RFC2205] RSVP 238 end-to-end model: end-to-end RSVP reservations are still expected to 239 be used whenever possible. However, RSVP Proxies are intended to 240 facilitate RSVP deployment where end-to-end RSVP signaling is not 241 possible. 243 2.1. RSVP Receiver Proxy 245 With conventional end-to-end RSVP operations, RSVP reservations are 246 controlled by receivers of data. After a data sender has sent an 247 RSVP Path message towards the intended recipient(s), each recipient 248 that requires a reservation generates a Resv message. If, however, a 249 data receiver is not running the RSVP protocol, the last hop RSVP 250 router will still send the Path message to the data receiver, which 251 will silently drop this message as an IP packet with an unknown 252 protocol number. 254 In order for reservations to be made in such a scenario, one of the 255 RSVP routers on the data path determines that the data receiver will 256 not be participating in the resource reservation signaling and 257 performs RSVP Receiver Proxy functionality on behalf of the data 258 receiver. This is illustrated in Figure 1. Various mechanisms by 259 which the RSVP proxy router can gain the required information are 260 discussed later in the document. 262 |****| *** *** |**********| |----| 263 | S |---------*r*----------*r*---------| RSVP |----------| R | 264 |****| *** *** | Receiver | |----| 265 | Proxy | 266 |**********| 268 ===================RSVP==============> 270 ***********************************************************> 272 |****| RSVP-capable |----| non-RSVP-capable *** 273 | S | Sender | R | Receiver *r* regular RSVP 274 |****| |----| *** router 276 ***> unidirectional media flow 278 ==> segment of flow path protected by RSVP reservation 280 Figure 1: RSVP Receiver Proxy 282 2.2. RSVP Sender Proxy 284 With conventional end-to-end RSVP operations, if a data sender is not 285 running the RSVP protocol, a resource reservation can not be set up; 286 a data receiver can not alone reserve resources without Path messages 287 first being received. Thus, even if the data receiver is running 288 RSVP, it still needs some node on the data path to send a Path 289 message towards the data receiver. 291 In that case, an RSVP node on the data path determines that it should 292 generate Path messages to allow the receiver to set up the resource 293 reservation. This node is referred to as the RSVP Sender Proxy and 294 is illustrated in Figure 2. This case presents additional challenges 295 over the Receiver Proxy case, since the RSVP Sender Proxy must be 296 able to generate all the information in the Path message (such as the 297 Sender TSpec) without the benefit of having previously received any 298 RSVP message. An RSVP Receiver Proxy, by contrast only needs to 299 formulate an appropriate Resv message in response to an incoming Path 300 message. Mechanisms to operate an RSVP Sender Proxy are discussed 301 later in this document. 303 |----| |**********| *** *** |****| 304 | S |---------| RSVP |---------*r*----------*r*----------| R | 305 |----| | Sender | *** *** |****| 306 | Proxy | 307 |**********| 309 ================RSVP==================> 311 ***********************************************************> 313 |----| non-RSVP-capable |****| RSVP-capable *** 314 | S | Sender | R | Receiver *r* regular RSVP 315 |----| |****| *** router 317 ***> unidirectional media flow 319 ==> segment of flow path protected by RSVP reservation 321 Figure 2: RSVP Sender Proxy 323 3. Terminology 325 o On-Path: located on the datapath of the actual flow of application 326 data (regardless of where it is located with respect to the 327 application level signaling path). 329 o Off-Path: not On-Path. 331 o RSVP-capable (or RSVP-aware): which supports the RSVP protocol as 332 per [RFC2205]. 334 o RSVP Receiver Proxy: an RSVP capable router performing, on behalf 335 of a receiver, the RSVP operations which would normally be 336 performed by an RSVP-capable receiver if end-to-end RSVP signaling 337 was used. Note that while RSVP is used upstream of the RSVP 338 Receiver Proxy, RSVP is not used downstream of the RSVP Receiver 339 Proxy. 341 o RSVP Sender Proxy: an RSVP capable router performing, on behalf of 342 a sender, the RSVP operations which would normally be performed by 343 an RSVP-capable sender if end-to-end RSVP signaling was used. 344 Note that while RSVP is used downstream of the RSVP Sender Proxy, 345 RSVP is not used upstream of the RSVP Sender Proxy. 347 o Regular RSVP Router: an RSVP-capable router which is not behaving 348 as a RSVP Receiver Proxy nor as a RSVP Sender Proxy. 350 o Application level signaling: signaling between entities operating 351 above the IP layer and which are aware of the QoS requirements for 352 actual media flows. SIP ([RFC3261]) and RTSP ([RFC2326]) are 353 examples of application level signaling protocol. SDP ([RFC4566]) 354 is an example of session description protocol that can be used by 355 the application level signaling protocol and from which some of 356 the RSVP reservation parameters (addresses, ports and bandwidth) 357 might be derived. RSVP is clearly not an application level 358 signaling. 360 The roles of RSVP Receiver Proxy, RSVP Sender Proxy, Regular RSVP 361 Router are all relative to a given unidirectional flow. A given 362 router may act as the RSVP Receiver Proxy for a flow, as the RSVP 363 Sender Proxy for another flow and as a Regular RSVP router for yet 364 another flow. 366 Some application level signaling protocols support negotiation of QoS 367 reservations for a media stream. For example, with [RFC3312], 368 resource reservation requirements are explicitly signaled during 369 session establishment using SIP and SDP. Also, [RFC5432] defines a 370 mechanism to negotiate which resource reservation mechanism is to be 371 used for a particular media stream. Clearly, these reservation 372 negotiation mechanisms can be invoked and operate effectively when 373 both ends support RSVP (and obviously RSVP Proxies are not used). 374 When both ends do not support RSVP (and RSVP proxies are used at both 375 ends) these mechanisms will simply not be invoked. In the case where 376 one end supports RSVP and the other does not (and is helped by an 377 RSVP Proxy), the application level signaling entity supporting the 378 non RSVP capable end might use the reservation negotiation mechanisms 379 in such a way that the non RSVP capable end (helped by an RSVP Proxy) 380 appears to the remote end as an RSVP capable device. This will 381 ensure that the RSVP capable end is not discouraged to use RSVP 382 because the remote end is not RSVP capable. In the case of SIP, the 383 application level entity may achieve this by taking advantage of the 384 "segmented" Status Type of [RFC3312] and/or by taking advantage of a 385 SIP [RFC3261] Back-to-Back User Agent (B2BUA). 387 4. RSVP Proxy Approaches 389 This section discusses fundamental RSVP Proxy approaches. 391 4.1. Path-Triggered Receiver Proxy 393 In this approach, it is assumed that the sender is RSVP capable and 394 takes full care of the synchronization between application 395 requirements and RSVP reservations. With this approach, the RSVP 396 Receiver Proxy uses the RSVP Path messages generated by the sender as 397 the cue for establishing the RSVP reservation on behalf of the 398 receiver. The RSVP Receiver Proxy is effectively acting as a slave 399 making reservations (on behalf of the receiver) under the sender's 400 control. This changes somewhat the usual RSVP reservation model 401 where reservations are normally controlled by receivers. Such a 402 change greatly facilitates operations in the scenario of interest 403 here, which is where the receiver is not RSVP capable. Indeed it 404 allows the RSVP Receiver Proxy to remain application unaware by 405 taking advantage of the application awareness and RSVP awareness of 406 the sender. 408 With the Path-Triggered RSVP Receiver Proxy approach, the RSVP router 409 may be configured to use receipt of a regular RSVP Path message as 410 the trigger for RSVP Receiver Proxy behavior. 412 On receipt of the RSVP Path message, the RSVP Receiver Proxy: 414 1. establishes the RSVP Path state as per regular RSVP processing 416 2. identifies the downstream interface towards the receiver 418 3. sinks the Path message 420 4. behaves as if a Resv message (whose details are discussed below) 421 was received on the downstream interface. This includes 422 performing admission control on the downstream interface, 423 establishing a Resv state (in case of successful admission 424 control) and forwarding the Resv message upstream, sending 425 periodic refreshes of the Resv message and tearing down the 426 reservation if the Path state is torn down. 428 In order to build the Resv message, the RSVP Receiver Proxy can take 429 into account information received in the Path message. For example, 430 the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv 431 message which mirrors the SENDER_TSPEC object in the received Path 432 message (as an RSVP-capable receiver would typically do). 434 Operation of the Path-Triggered Receiver Proxy in the case of a 435 successful reservation is illustrated in Figure 3. 437 |****| *** *** |**********| |----| 438 | S |---------*r*----------*r*---------| RSVP |----------| R | 439 |****| *** *** | Receiver | |----| 440 | Proxy | 441 |**********| 443 ---Path---> ----Path----> ---Path----> 445 <--Resv---> <---Resv----- <--Resv---- 447 ==================RSVP===============> 449 **********************************************************> 451 |****| RSVP-capable |----| Non-RSVP-capable *** 452 | S | Sender | R | Receiver *r* regular RSVP 453 |****| |----| *** router 455 ***> media flow 457 ==> segment of flow path protected by RSVP reservation 459 Figure 3: Path-Triggered RSVP Receiver Proxy 461 In case the reservation establishment is rejected (for example 462 because of an admission control failure on a regular RSVP router on 463 the path between the RSVP-capable sender and the RSVP Receiver 464 Proxy), a ResvErr message will be generated as per conventional RSVP 465 operations and will travel downstream towards the RSVP Receiver 466 Proxy. While this ensures that the RSVP Receiver Proxy is aware of 467 the reservation failure, conventional RSVP procedures do not cater 468 for notification of the sender of the reservation failure. Operation 469 of the Path-Triggered RSVP Receiver Proxy in the case of an admission 470 control failure is illustrated in Figure 4. 472 |****| *** *** |**********| |----| 473 | S |---------*r*----------*r*---------| RSVP |----------| R | 474 |****| *** *** | Receiver | |----| 475 | Proxy | 476 |**********| 478 ---Path---> ----Path----> ---Path----> 480 <---Resv----- <--Resv------ 482 ---ResvErr---> --ResvErr---> 484 ===================RSVP===============> 486 **********************************************************> 488 |****| RSVP-capable |----| Non-RSVP-capable *** 489 | S | Sender | R | Receiver *r* regular RSVP 490 |****| |----| *** router 492 ***> media flow 494 ==> segment of flow path protected by RSVP reservation 496 Figure 4: Path-Triggered RSVP Receiver Proxy with Failure 498 Since, as explained above, in this scenario involving the RSVP 499 Receiver Proxy, synchronization between application and RSVP 500 reservation is generally performed by the sender, notifying the 501 sender of reservation failure is needed. 502 [I-D.ietf-tsvwg-rsvp-proxy-proto] specifies RSVP extensions allowing 503 such sender notification in case of reservation failure in the 504 presence of a Path-Triggered RSVP Receiver Proxy. 506 4.1.1. Mechanisms for Maximizing the Reservation Span 508 The presence in the flow path of a Path-triggered RSVP Receiver Proxy 509 (for a given flow) that strictly behaves as described previously 510 would cause the Path message to be terminated and a Resv message to 511 be generated towards the sender. When the receiver is indeed not 512 RSVP capable and there is no other RSVP Receiver Proxy downstream on 513 the flow path, this achieves the best achievable result of 514 establishing an RSVP reservation as far downstream as the RSVP 515 Receiver Proxy. 517 However, if the eventual receiver was in fact RSVP capable, it would 518 be prevented from participating in RSVP signalling since it does not 519 receive any Path message. As a result, the RSVP reservation would 520 only span a subset of the path it could actually span. A similar 521 suboptimality would exist with multiple Receiver Proxies in the path 522 of the flow: the first Receiver Proxy may prevent the Path message 523 from reaching the second one and therefore prevent the reservation 524 from extending down to the second Receiver Proxy. 526 It is desirable that, in the presence of Path-triggered RSVP Receiver 527 Proxies and of a mix of RSVP-capable and non-RSVP-capable receivers, 528 the RSVP reservation spans as much of the flow path as possible. 529 This can be achieved dynamically (avoiding tedious specific 530 configuration), using the mechanisms described in Section 4.1.1.1 and 531 in Section 4.1.1.2. 533 4.1.1.1. Dynamic Discovery of Downstream RSVP Functionality 535 When generating a proxy Resv message upstream, a Receiver Proxy may 536 be configured to perform dynamic discovery of downstream RSVP 537 functionality. To that end, when generating the proxy Resv message 538 upstream, the Receiver Proxy forwards the Path message downstream 539 instead of terminating it. This allows an RSVP capable receiver (or 540 a downstream Receiver Proxy) to respond to the Path with an upstream 541 Resv message. On receipt of a Resv message, the Receiver Proxy 542 internally converts its state from a proxied reservation to a regular 543 midpoint RSVP behavior. From then on, everything proceeds as if the 544 RSVP router had behaved as a regular RSVP router at reservation 545 establishment (as opposed to having behaved as an RSVP receiver proxy 546 for that flow). 548 The RSVP Receiver Proxy behavior for dynamic discovery of downstream 549 RSVP functionality is illustrated in Figure 5 and is also discussed 550 in section 4.1 of [I-D.ietf-tsvwg-rsvp-proxy-proto]. 552 |****| *** |**********| |----| 553 | S |---------*r*---------| RSVP |---| R1 | 554 |****| *** | Receiver | |----| 555 | Proxy | 556 | | 557 | | |****| 558 | |------------| R2 | 559 |**********| |****| 561 ---Path---> --Path---> 562 (R1) (R1) \-------Path--> 563 / (R1) 564 <--Resv--- <---Resv--- 566 ================RSVP===> 568 **************************************> 570 ---Path---> --Path---> 571 (R2) (R2) \-------------Path----> 572 / (R2) 573 <--Resv--- <---Resv--- 574 <----Resv--- 576 ================RSVP===========================> 578 ***********************************************> 580 |****| RSVP-capable |----| non-RSVP-capable |****| RSVP-capable 581 | S | Sender | R | Receiver | R | Receiver 582 |****| |----| |****| 584 *** 585 *r* regular RSVP 586 *** router 588 (R1) = Path message contains a Session object whose destination is R1 590 ***> media flow 592 ==> segment of flow path protected by RSVP reservation 594 Figure 5: Dynamic Discovery of Downstream RSVP Functionality 596 This dynamic discovery mechanism has the benefit that new (or 597 upgraded) RSVP endpoints will automatically and seamlessly be able to 598 take advantage of end-to-end reservations, without impacting the 599 ability of a Receiver Proxy to proxy RSVP for other, non-RSVP-capable 600 endpoints. This mechanism also achieves the goal of automatically 601 discovering the longest possible RSVP-supporting segment in a network 602 with multiple Receiver Proxies along the path. This mechanism 603 dynamically adjusts to any topology and routing change. Also, this 604 mechanism dynamically handles the situation where a receiver was 605 RSVP-capable and for some reason (e.g. Software downgrade) no longer 606 is. Finally, this approach requires no new RSVP protocol extensions 607 and no configuration changes to the Receiver Proxy as new RSVP- 608 capable endpoints come and go. 610 The only identified drawbacks to this approach are: 612 o If admission control fails on the segment between the Receiver 613 Proxy and the RSVP-capable receiver, the receiver will get a 614 ResvError and can take application-level signalling steps to 615 terminate the call. However, the receiver proxy has already sent 616 a Resv upstream for this flow, so the sender will see a "false" 617 reservation which is not truly end-to-end. The actual admission 618 control status will resolve itself in a short while, but the 619 sender will need to roll back any permanent action (such as 620 billing) that may have been taken on receipt of the phantom Resv. 621 Note that if the second receiver is also a Receiver Proxy which is 622 not participating in application signalling, it will convert the 623 received ResvError into a PathError which will be received by the 624 sender. 626 o If there is no RSVP-capable receiver (or other Receiver Proxy) 627 downstream of the Receiver Proxy, then the Path messages sent by 628 the Receiver Proxy every RSVP refresh interval (e.g. 30 seconds by 629 default) will never be responded to. However, these messages 630 consume a small amount of bandwidth, and in addition would install 631 some RSVP state on RSVP-capable midpoint nodes downstream of the 632 first Receiver Proxy. This is seen as a very minor sub- 633 optimality. We also observe that such resources would be consumed 634 anyways if the receiver was RSVP capable. Still, if deemed 635 necessary, to mitigate this, the receiver proxy can tear down any 636 unanswered downstream Path state and stop sending Path messages 637 for the flow (or only send them at much lower frequency) as 638 further discussed in [I-D.ietf-tsvwg-rsvp-proxy-proto] . 640 4.1.1.2. Selective Receiver Proxy and Sender Control of Receiver Proxy 642 An RSVP Receiver Proxy can be selective about the sessions that it 643 terminates, based on local policy decision. For example, an edge 644 router functioning as a Receiver Proxy may behave as a proxy only for 645 Path messages that are actually going to exit the domain in question, 646 not for Path messages that are transiting through it but stay within 647 the domain. As another example, the receiver proxy may be 648 configurable to only proxy for flows addressed to a given destination 649 address or destination address ranges (for which end devices are 650 known to not be RSVP capable). 652 The decision to proxy a Resv for a Path may also be based on 653 information signalled from the sender in the Path message. For 654 example, the sender may identify the type of application or flow in 655 the Application Identity Policy Element ([RFC2872]) in the Path, and 656 the Receiver Proxy may be configured to proxy for only certain types 657 of flows. Or, if the sender knows (for example through application 658 signalling) that the receiver is RSVP capable, the sender can include 659 an indication in a Policy Element to any Receiver Proxy that it ought 660 not to terminate the Path (or conversely, if the receiver is known 661 not to support RSVP, the sender could include an indication to 662 Receiver Proxies that they ought to generate a proxy Resv message). 663 The Receiver Proxy Control Policy Element specified in section 4.2 of 664 [I-D.ietf-tsvwg-rsvp-proxy-proto] can be used for that purpose. 666 4.2. Path-Triggered Sender Proxy for Reverse Direction 668 In this approach, it is assumed that one endpoint is RSVP capable and 669 takes full care of the synchronization between application 670 requirements and RSVP reservations. This endpoint is the sender for 671 one flow direction (which we refer to as the "forward" direction) and 672 is the receiver for the flow in the opposite direction (which we 673 refer to as the "reverse" direction). 675 With the Path-Triggered Sender Proxy for Reverse Direction approach, 676 the RSVP Proxy uses the RSVP signaling generated by the receiver (for 677 the reverse direction) as the cue for initiating RSVP signaling for 678 the reservation in the reverse direction. More precisely, the RSVP 679 Proxy can take the creation (respectively, maintenance and teardown) 680 of a Path state by the receiver as the cue to create (respectively, 681 maintain and teardown) a Path state towards the receiver. Thus, the 682 RSVP Proxy is effectively acting as a Sender Proxy for the reverse 683 direction under the control of the receiver (for the reverse 684 direction). Note that this assumes a degree of symmetry for example 685 in terms of bandwidth for the two directions of the flow (as is 686 currently typical for IP telephony, for example). 688 The signaling flow for the Path-Triggered Sender Proxy for Reverse 689 Direction is illustrated in Figure 6. 691 Path messages generated by the receiver need to transit via the RSVP 692 Sender Proxy that is on the path from the sender to the receiver. In 693 some topologies, this will always be the case: for example where the 694 sender is on a stub network hanging off the RSVP Sender Proxy or 695 where there is no asymmetric routing (such that if a RSVP Sender 696 Proxy is on the path from receiver to sender, then it is also on the 697 path from sender to receiver). In some topologies (such as those 698 involving asymmetric routing), this may not always happen naturally. 699 Measures to ensure this does happen in these topologies are outside 700 the scope of this document. 702 |****| *** *** |**********| |----| 703 | R |---------*r*----------*r*---------| RSVP |----------| S | 704 |****| *** *** | Sender | |----| 705 | Proxy | 706 |**********| 708 ---Path---> ----Path----> ---Path----> 710 <--Path---> <---Path----- <--Path---- 712 ---Resv---> ----Resv----> ---Resv----> 714 <================RSVP================== 716 <********************************************************** 718 |****| RSVP-capable |----| Non-RSVP-capable *** 719 | R | Receiver for | S | Sender for *r* regular RSVP 720 |****| reverse direction |----| reverse direction *** router 722 ***> media flow 724 ==> segment of flow path protected by RSVP reservation 725 in reverse direction 727 Figure 6: Path-Triggered Sender Proxy for Reverse Direction 729 Of course, the RSVP Proxy may simultaneously (and typically will) 730 also act as the Path-Triggered Receiver Proxy for the forward 731 direction, as defined in Section 4.1. Such an approach is most 732 useful in situations involving RSVP reservations in both directions 733 for symmetric flows. This is illustrated in Figure 7. 735 |****| *** *** |----------| |----| 736 |S/R |---------*r*----------*r*---------| RSVP |----------|S/R | 737 |****| *** *** | Receiver | |----| 738 | & Sender | 739 | Proxy | 740 |----------| 742 ---Path---> ----Path----> ---Path----> 744 <--Resv---> <---Resv----- <--Resv---- 746 <--Path---> <---Path----- <--Path---- 748 ---Resv---> ----Resv----> ---Resv----> 750 ================RSVP==================> 751 <================RSVP================== 753 **********************************************************> 754 <********************************************************** 756 |****| RSVP-capable |----| Non-RSVP-capable *** 757 |S/R | Sender and |S/R | Sender and *r* regular RSVP 758 |****| Receiver |----| Receiver *** router 760 ***> media flow 762 ==> segment of flow path protected by RSVP reservation 763 in forward and in reverse direction 765 Figure 7: Path Triggered Receiver & Sender Proxy 767 With the Path-Triggered Sender Proxy for Reverse Direction approach, 768 the RSVP router may be configurable to use receipt of a regular RSVP 769 Path message as the trigger for Sender Proxy for Reverse Direction 770 behavior. 772 On receipt of the RSVP Path message for the forward direction, the 773 RSVP Sender Receiver Proxy : 775 1. sinks the Path message 777 2. behaves as if a Path message for reverse direction (whose details 778 are discussed below) had been received by the Sender Proxy. This 779 includes establishing the corresponding Path state, forwarding 780 the Path message downstream, sending periodic refreshes of the 781 Path message and tearing down the Path in reverse direction when 782 the Path state in forward direction is torn down. 784 In order to build the Path message for the reverse direction, the 785 RSVP Sender Proxy can take into account information in the received 786 Path message for the forward direction. For example, the RSVP Sender 787 Proxy may mirror the SENDER_TSPEC object in the received Path 788 message. 790 We observe that this approach does not require any extensions to the 791 existing RSVP protocol. 793 In the case where reservations are required in both directions (as 794 shown in Figure 7), the RSVP-capable device simply needs to behave as 795 a regular RSVP sender and RSVP receiver. It needs not be aware that 796 an RSVP Proxy happens to be used and the Path message it sent for the 797 forward reservation also acts as the trigger for establishment of the 798 reverse reservation. However, in the case where a reservation is 799 only required in the reverse direction (as shown in Figure 6), the 800 RSVP-capable device has to generate Path messages in order to trigger 801 the reverse direction reservation even if no reservation is required 802 in the forward direction. Although this is not in violation with 803 [RFC2205], it may not be the default behavior of an RSVP-capable 804 device and therefore may need a behavioral change specifically to 805 facilitate operation of the Path-Triggered Sender Proxy for Reverse 806 Direction. 808 4.3. Inspection-Triggered Proxy 810 In this approach, it is assumed that the RSVP Proxy is on the 811 datapath of "packets of interest", that it can inspect such packets 812 on the fly as they transit through it, and that it can infer 813 information from these packets of interest to determine what RSVP 814 reservations need to be established, when and with what 815 characteristics (possibly also using some configured information). 817 One example of "packets of interest" could be application level 818 signaling. An RSVP Proxy capable of inspecting SIP signaling for 819 multimedia session or RTSP signaling for Video streaming, can obtain 820 from such signaling information about when a multimedia session is up 821 or when a Video is going to be streamed. It can also identify the 822 addresses and ports of senders and receivers and can determine the 823 bandwidth of the corresponding flows. It can also determine when the 824 reservation is no longer needed and tear it down. Thus, such an RSVP 825 Proxy can determine all necessary information to synchronize RSVP 826 reservations to application requirements. This is illustrated in 827 Figure 8. 829 |-------------| 830 | Application | 831 | Signaling | 832 | Entity | 833 |-------------| 834 / \ 835 / \ 836 / \ 837 839 |----| |********| *** |********| |----| 840 | S |--------| RSVP |------*r*--------| RSVP |----------| R | 841 |----| | Proxy | *** | Proxy | |----| 842 |********| |********| 844 =======RSVP=======> 846 ********************************************************> 848 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 849 | S | Sender | R | Receiver *r* regular RSVP 850 |----| |----| *** router 852 application level signaling 854 ***> media flow 856 ==> segment of flow path protected by RSVP reservation 858 Figure 8: Inspection-Triggered RSVP Proxy 860 Another example of "packets of interest" could be transport control 861 messages (e.g. RTCP [RFC3550]) traveling alongside the application 862 flow itself (i.e. Media packets). An RSVP Proxy capable of 863 detecting the transit of packets from a particular flow, can attempt 864 to establish a reservation corresponding to that flow. 865 Characteristics of the reservation may be derived by various methods 866 such as from configuration, flow measurement or a combination of 867 those. However, these methods usually come with their respective 868 operational drawbacks: configuration involves an operational cost and 869 may hinder introduction of new applications, measurement is reactive 870 so that accurate reservation may lag actual traffic. 872 In case of reservation failure, the inspection-triggered RSVP Proxy 873 does not have a direct mechanism for notifying the application (since 874 it is not participating itself actively in application signaling) so 875 that the application is not in a position to take appropriate action 876 (for example terminate the corresponding session). To mitigate this 877 problem, the inspection-triggered RSVP Proxy may mark differently the 878 Differentiated Services codepoint (DSCP) ([RFC2474]) of flows for 879 which an RSVP reservation has been successfully proxied from the 880 flows for which a reservation is not in place. In some situations, 881 the Inspection-Triggered Proxy might be able to modify the "packets 882 of interest" (e.g. Application signaling messages) to convey some 883 hint to applications that the corresponding flows cannot be 884 guaranteed by RSVP reservations. 886 With the inspection-triggered Proxy approach, the RSVP Proxy is 887 effectively required to attempt to build application awareness by 888 traffic inspection and then is somewhat limited in the actions it can 889 take in case of reservation failure. Depending on the "packets of 890 interest" used by the RSVP Proxy to trigger the reservation, there is 891 a risk that the RSVP Proxy ends up establishing a reservation for a 892 media flow that actually never starts. However, this can be 893 mitigated by timing out and tearing down of an unnecessary 894 reservation by the RSVP Proxy when no corresponding media flow is 895 observed. This flow observation and time out approach can also be 896 used to tear down reservation that were rightfully established for a 897 flow but are no longer needed because the flow stopped. 899 The inspection-triggered approach is also subject to the general 900 limitations associated with data inspection. This includes being 901 impeded by encryption or tunnelling, or being dependent on some 902 topology constraints such as relying on the fact that both the 903 packets of interest and the corresponding flow packets always transit 904 through the same RSVP Proxy. 906 Nonetheless, this may be a useful approach in specific environments. 907 Note also that this approach does not require any change to the RSVP 908 protocol. 910 With the "Inspection-Triggered" RSVP Proxy approach, the RSVP router 911 may be configurable to use and interpret some specific "packets of 912 interest" as the trigger for RSVP Receiver Proxy behavior. 914 When operating off signaling traffic, the "Inspection-Triggered" RSVP 915 Proxy may be able to detect from the signaling that the endpoint is 916 capable of establishing an RSVP reservation (e.g. In the case of SIP 917 via inspection of the [RFC3312]/[RFC4032] Precondition), in which 918 case it would not behave as a Proxy for that endpoint . Also, the 919 "Inspection-Triggered" RSVP proxy may inspect RSVP signaling and if 920 it sees RSVP signaling for the flow of interest, it can disable its 921 sender proxy behavior for that flow (or that sender). Optionally, 922 through RSVP signaling inspection, the sender proxy might also 923 gradually "learn" (possibly with some timeout) which sender is RSVP 924 capable of not. These mechanisms can facilitate gradual and dynamic 925 migration from the Proxy model towards the end-to-end RSVP model as 926 more and more endpoints become RSVP capable. 928 4.4. STUN-Triggered Proxy 930 In this approach, the RSVP Proxy takes advantage of the application 931 awareness provided by the STUN ([RFC5389]) signaling to synchronize 932 RSVP reservations with application requirements. The STUN signaling 933 is sent from endpoint to endpoint. This is illustrated in Figure 9. 934 In this approach, a STUN message triggers the RSVP Proxy. 936 |----| |********| *** |********| |----| 937 | S |--------| RSVP |------*r*--------| RSVP |----------| R | 938 |----| | Proxy | *** | Proxy | |----| 939 |********| |********| 941 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^> 943 =======RSVP=======> 945 ********************************************************> 947 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 948 | S | Sender | R | Receiver *r* regular RSVP 949 |----| |----| *** router 951 ^^^> STUN message flow (over same UDP ports as media flow) 953 ==> segment of flow path protected by RSVP reservation 955 ***> RTP media flow 957 Figure 9: STUN-Triggered Proxy 959 For unicast flows, [I-D.ietf-mmusic-ice] is a widely-adopted approach 960 for NAT traversal. For our purposes of triggering RSVP Proxy 961 behavior, we rely on ICE's connectivity check which is based on the 962 exchange of STUN Binding Request messages between hosts to verify 963 connectivity (see section 2.2 of [I-D.ietf-mmusic-ice]). The STUN 964 message could also include (yet to be specified) STUN attributes to 965 indicate information such as the bandwidth and application requesting 966 the flow, which would allow the RSVP proxy agent to create an 967 appropriately-sized reservation for each flow. Including such new 968 STUN attributes in the ICE connectivity check messages would 969 facilitates operation of the RSVP Proxy. To ensure RSVP reservations 970 are only established when needed, the RSVP Proxy needs to 971 distinguish, among all the STUN messages, the ones that reflect (with 972 high likelihood) an actual upcoming media flow. This can be achieved 973 by identifying the STUN messages associated with an ICE connectivity 974 check. In turn, this can be achieved through (some combination of) 975 the following checks: 977 o if, as discussed above, new STUN attributes (e.g. Conveying the 978 flow bandwidth) are indeed defined in the future in view of 979 facilitating STUN-Triggered reservations, then the presence of 980 these attributes would reveal that the STUN message is part of an 981 ICE connectivity check. 983 o the presence of the PRIORITY, USE-CANDIDATE, ICE-CONTROLLED or 984 ICE-CONTROLLING attributes reveals that the STUN message is part 985 of an ICE connectivity check 987 o the RSVP Proxy may wait for a STUN message containing the USE- 988 CANDIDATE attribute indicating the selected ICE "path" to trigger 989 reservation only for the selected "path". This allows the RSVP 990 Proxy to only trigger a reservation for the "path" actually 991 selected and therefore for the media flow that will actually be 992 established (for example when ICE is being used for v4/v6 path 993 selection). 995 o the RSVP Proxy configuration could contain some information 996 facilitating determination of when to perform RSVP Proxy 997 reservation and not. For example, the RSVP Proxy configuration 998 could contain the IP addresses of the STUN servers such that STUN 999 messages to/from those addresses are known to not be part of an 1000 ICE connectivity check. As another example, the RSVP Proxy 1001 configuration could contain information identifying the set of 1002 Differentiated Services codepoint (DSCP) values that the media 1003 flows requiring reservation use, so that STUN messages not using 1004 one of these DSCP values are known to not be part of an ICE 1005 connectivity check. 1007 Despite these checks, there is always a potential risk that the RSVP 1008 Proxy ends up establishing a reservation for a media flow that 1009 actually never starts. However, this is limited to situations where 1010 the end-systems is interested enough in establishing connectivity for 1011 a flow but yet never transmit. Also, this can be mitigated by timing 1012 out and tear down of an unnecessary reservations by the RSVP Proxy 1013 when no corresponding media flow is observed. 1015 The RSVP Proxy agent can inform endpoints of an RSVP reservation 1016 failure implicitly by dropping the ICE connectivity check message or 1017 explicitly by sending ICMP messages back to the endpoint. This 1018 allows reasonably effective synchronisation between RSVP reservations 1019 handled by the RSVP Proxies and the application running on non RSVP- 1020 capable endpoints. It also has the benefits of operating through 1021 NATs. 1023 For multicast flows (or certain kinds of unicast flows that don't or 1024 can't use ICE), a STUN Indication message [RFC5389] could be used to 1025 carry the (yet to be defined) STUN attributes mentioned earlier to 1026 indicate the flow bandwidth, thereby providing a benefit similar to 1027 the ICE connectivity check. STUN Indication messages are not 1028 acknowledged by the receiver and have the same scalability as the 1029 underlying multicast flow. 1031 The corresponding extensions to ICE and STUN for such a STUN- 1032 triggered RSVP Proxy approach are beyond the scope of this document. 1033 They may be defined in the future in a separate document. As the 1034 STUN-triggered RSVP Proxy approach uses STUN in a way (i.e. To 1035 trigger reservations) that is beyond its initial intended purpose, 1036 the potential security implications need to be considered by the 1037 operator. 1039 ICE connectivity checks is not always used for all flows. When the 1040 STUN-triggered RSVP Proxy approach is used, it can establish RSVP 1041 reservations for flows for which ICE connectivity is performed. 1042 However, the STUN-triggered RSVP Proxy will not establish a 1043 reservation for flows for which ICE connectivity check is not 1044 performed. Those flows will either not benefit from an RSVP 1045 reservation or can benefit from an RSVP reservation established 1046 through other means (end-to-end RSVP, other forms of RSVP Proxy). 1048 The STUN-triggered approach relies on interception and inspection of 1049 STUN messages. Thus, this approach may be impeded by encryption or 1050 tunneling. 1052 4.5. Application_Entity-Controlled Proxy 1054 In this approach, it is assumed that an entity involved in the 1055 application level signaling controls an RSVP Proxy which is located 1056 in the datapath of the application flows (i.e. "on-path"). With this 1057 approach, the RSVP Proxy does not attempt to determine itself the 1058 application reservation requirements. Instead the RSVP Proxy is 1059 instructed by the entity participating in application level signaling 1060 to establish, maintain and tear down reservations as needed by the 1061 application flows. In other words, with this approach, the solution 1062 for synchronizing RSVP signaling with application level requirements 1063 is to rely on an application-level signaling entity that controls an 1064 RSVP Proxy function that sits in the flow datapath. This approach 1065 allows control of an RSVP Sender Proxy, an RSVP Receiver Proxy or 1066 both. 1068 Operation of the Application_Entity-Controlled Proxy is illustrated 1069 in Figure 10. 1071 |---------| |---------| 1072 /////////| App |////\\\\| App |\\\\\\\\ 1073 / | Entity | | Entity | \ 1074 / |---------| |---------| \ 1075 / // \\ \ 1076 / // \\ \ 1077 / // \\ \ 1078 / // \\ \ 1079 / // \\ \ 1080 |----| |********| *** |*********| |----| 1081 | S |----------| |------*r*-------| |---------| R | 1082 |----| | RSVP | *** | RSVP | |----| 1083 | Sender | | Receiver| 1084 | Proxy | | Proxy | 1085 |********| |*********| 1087 =======RSVP=======> 1089 ********************************************************> 1091 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 1092 | S | Sender | R | Receiver *r* regular RSVP 1093 |----| |----| *** router 1095 ***> media flow 1097 ==> segment of flow path protected by RSVP reservation 1099 /\ Application signaling (e.g. SIP) 1101 // RSVP Proxy control interface 1103 Figure 10: Application_Entity-Controlled Proxy 1105 As an example, the Application_Entity-Controlled Proxy may be used in 1106 the context of SIP Servers ([RFC3261]) or Session Border Controllers 1107 (SBCs) (see [I-D.ietf-sipping-sbc-funcs] for description of SBCs) to 1108 establish RSVP reservations for multimedia sessions. In that case, 1109 the Application Entity may be the signaling component of the SBC. 1111 This RSVP Proxy approach does not require any extension to the RSVP 1112 protocol. However, it relies on an RSVP Proxy control interface 1113 allowing control of the RSVP Proxy by an application signaling 1114 entity. This RSVP Proxy control interface is beyond the scope of the 1115 present document. Candidate protocols for realizing such interface 1116 include the IETF NETCONF configuration protocol 1117 ([RFC4741],[RFC5277]), Web Services protocol ([W3C]), QPIM 1118 ([RFC3644]) and DIAMETER ([RFC3588]). This interface can rely on 1119 soft states or hard states. Clearly, when hard states are used, 1120 those need to be converted appropriately by the RSVP Proxy entities 1121 into the corresponding RSVP soft states. As an example, 1122 [I-D.ietf-dime-diameter-qos] is intended to allow control of RSVP 1123 Proxy via DIAMETER. 1125 In general, the Application Entity is not expected to maintain 1126 awareness of which RSVP Receiver Proxy is on the path to which 1127 destination. However, in the particular cases where it does so 1128 reliably, we observe that the Application Entity could control the 1129 RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP 1130 reservations are used between those, instead of one reservation per 1131 flow. For example, these aggregate reservations could be of RSVP- 1132 AGGREGATE type as specified in [RFC3175] or of GENERIC-AGGREGATE type 1133 as specified in [RFC4860]. Such aggregate reservations could be used 1134 so that a single reservation can be used for multiple (possibly all) 1135 application flows transiting via the same RSVP Sender Proxy and the 1136 same RSVP Receiver Proxy. 1138 For situations where only the RSVP Sender Proxy has to be controlled 1139 by this interface, the interface may be realized through the simple 1140 use of RSVP itself, over a GRE tunnel from the application entity to 1141 the RSVP Sender Proxy. This particular case is further discussed in 1142 Section 4.5.1. Another particular case of interest is where the 1143 application signaling entity resides on the same device as the RSVP 1144 Proxy. In that case, this interface may be trivially realized as an 1145 internal API. An example environment based on this particular case 1146 is illustrated in Section 4.5.2. 1148 The application entity controlling the RSVP Proxy (e.g. a SIP Call 1149 Agent) would often be aware of a number of endpoint capabilities and 1150 it has to be aware about which endpoint can be best "served" by which 1151 RSVP Proxy anyways. So it is reasonable to assume that such an 1152 application is aware of whether a given endpoint is RSVP-capable or 1153 not. The application may also consider the QoS preconditions and QoS 1154 mechanisms signaled by an endpoint as per [RFC3312]/[RFC4032] and 1155 [RFC5432]. The information about endpoint RSVP capability can then 1156 be used by the application to decide whether to trigger Proxy 1157 behavior or not for a given endpoint. This can facilitate gradual 1158 and dynamic migration from the Proxy model towards the end-to-end 1159 RSVP model as more and more endpoints become RSVP capable. 1161 In some environments, the application entities (e.g. SIP Back-to- 1162 Back User Agents) that need to control the RSVP Proxies would already 1163 be deployed independently of the use, or not, of the 1164 Application_Entity-Controlled Proxy approach. In this case, the 1165 activation of the RSVP Proxy approach should not introduce 1166 significant disruption in the application signaling path. In some 1167 environments, additional application entities may need to be deployed 1168 to control the RSVP Proxies. In this case, the network operator 1169 needs to consider the associated risks of disruption to the 1170 application signaling path. 1172 4.5.1. Application_Entity-Controlled Sender Proxy using "RSVP over GRE" 1174 This approach is simply a particular case of the more general 1175 Application_Entity-Controlled Proxy, but where only RSVP Sender 1176 Proxies need to be controlled by the application, and where RSVP is 1177 effectively used as the control protocol between the application 1178 signaling entity and the RSVP Sender Proxy. 1180 In this approach, the RSVP messages (e.g. RSVP Path message) are 1181 effectively generated by the application entity and logically 1182 "tunnelled" to the RSVP Sender Proxy via GRE tunneling. This is to 1183 ensure that the RSVP messages follow the exact same path as the flow 1184 they protect (as required by RSVP operations) on the segment of the 1185 end-to-end path which is to be subject to RSVP reservations. 1187 Figure 11 illustrates such an environment. 1189 |-------------| 1190 ////////////| Application |\\\\\\\\\ 1191 / | Entity | \ 1192 / |-------------| \ 1193 / /=/ \ 1194 / /=/ \ 1195 / /=/ \ 1196 / /=/ \ 1197 / /=/ \ 1198 / /=/ \ 1199 / /=/ \ 1200 / /=/ \ 1201 |----| |********| *** |****| 1202 | S |-----------| RSVP |-----------*r*-----------------| R | 1203 |----| | Sender | *** |****| 1204 | Proxy | 1205 |********| 1207 =========RSVP====================> 1209 *****************************************************> 1211 |----| non-RSVP-capable |----| RSVP-capable *** 1212 | S | Sender | R | Receiver *r* regular RSVP 1213 |----| |----| *** router 1215 ***> media flow 1217 ==> segment of flow path protected by RSVP reservation 1219 /\ Application level signaling 1221 /=/ GRE-tunnelled RSVP (Path messages) 1223 Figure 11: Application-Entity-Controlled Sender Proxy via "RSVP over 1224 GRE" 1226 With the Application_Entity-Controlled Sender Proxy using "RSVP Over 1227 GRE", the application entity : 1229 o generates a Path message on behalf of the sender, corresponding to 1230 the reservation needed by the application and maintains the 1231 corresponding Path state. The Path message built by the 1232 application entity is exactly the same as would be built by the 1233 actual sender (if it was RSVP-capable), with one single exception 1234 which is that the Application Entity puts its own IP address as 1235 the RSVP Previous Hop. In particular, it is recommended that the 1236 source address of the Path message built by the application entity 1237 be set to the IP address of the sender (not of the application 1238 entity). This helps ensuring that, in the presence of non-RSVP 1239 routers and of load-balancing in the network where the load- 1240 balancing algorithm takes into account the source IP address, the 1241 Path message generated by the application entity follows the exact 1242 same path that the actual stream sourced by the sender. 1244 o encapsulates the Path message into a GRE tunnel whose destination 1245 address is the RSVP Sender Proxy i.e. An RSVP Router sitting on 1246 the datapath for the flow (and upstream of the segment which 1247 requires QoS guarantees via RSVP reservation). 1249 o processes the corresponding received RSVP messages (including Resv 1250 messages) as per regular RSVP. 1252 o synchronizes the RSVP reservation state with application level 1253 requirements and signaling. 1255 Note that since the application entity encodes its own IP address as 1256 the previous RSVP hop inside the [RFC2205] RSVP_HOP object of the 1257 Path message, the RSVP Router terminating the GRE tunnel naturally 1258 addresses all the RSVP messages travelling upstream hop-by-hop (such 1259 as Resv messages) to the application entity (without having to 1260 encapsulate those in a reverse-direction GRE tunnel towards the 1261 application entity). 1263 4.5.2. Application_Entity-Controlled Proxy via Co-Location 1265 This approach is simply a particular case of the more general 1266 Application_Entity-Controlled Proxy, but where the application entity 1267 is co-located with the RSVP Proxy. As an example, Session Border 1268 Controllers (SBC) with on-board SIP agents could implement RSVP Proxy 1269 functions and make use of such an approach to achieve session 1270 admission control over the SBC-to-SBC segment using RSVP signaling. 1272 Figure 12 illustrates operations of the Application_Entity-Controlled 1273 RSVP Proxy via Co-location. 1275 |---------| |---------| 1276 ////////| App |////////\\\\\\\| App |\\\\\\\\\ 1277 / | Entity | | Entity | \ 1278 / | | | | \ 1279 |----| |*********| *** |*********| |----| 1280 | S |--------| RSVP |------*r*------| RSVP |---------| R | 1281 |----| | Sender | *** | Receiver| |----| 1282 | Proxy | | Proxy | 1283 |*********| |*********| 1285 =======RSVP======> 1287 *******************************************************> 1289 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 1290 | S | Sender | R | Receiver *r* regular RSVP 1291 |----| |----| *** router 1293 ***> media flow 1295 ==> segment of flow path protected by RSVP reservation 1297 /\ Application level signaling 1299 Figure 12: Application_Entity-Controlled Proxy via Co-Location 1301 This RSVP Proxy approach does not require any protocol extensions. 1302 We also observe that when multiple sessions are to be established on 1303 paths sharing the same RSVP Sender Proxy and the same RSVP Receiver 1304 Proxy, the RSVP Proxies have the option to establish aggregate RSVP 1305 reservations (as defined in ([RFC3175] or [RFC4860]) for a group of 1306 sessions, instead of establishing one RSVP reservation per session. 1308 4.6. Policy_Server-Controlled Proxy 1310 In this approach, it is assumed that a Policy Server, which is 1311 located in the control plane of the network, controls an RSVP Proxy 1312 which is located in the datapath of the application flows (i.e. "on- 1313 path"). In turn, the Policy server is triggered by an entity 1314 involved in the application level signaling. With this approach, the 1315 RSVP Proxy does not attempt to determine itself the application 1316 reservation requirements, but instead is instructed by the Policy 1317 Server to establish, maintain and tear down reservations as needed by 1318 the application flows. Moreover, the entity participating in 1319 application level signaling does not attempt to understand the 1320 specific reservation mechanism (i.e. RSVP) or the topology of the 1321 network layer, but instead it simply asks the policy server to 1322 perform (or tear down) a reservation. In other words, with this 1323 approach, the solution for synchronizing RSVP signaling with 1324 application level requirements is to rely on an application level 1325 entity that controls a policy server that, in turn, controls an RSVP 1326 Proxy function that sits in the flow datapath. This approach allows 1327 control of an RSVP Sender Proxy, an RSVP Receiver Proxy or both. 1329 Operation of the Policy_Server-Controlled Proxy is illustrated 1330 Figure 13. 1332 |---------| 1333 /////////////| App |\\\\\\\\\\\\\\ 1334 / | Entity | \ 1335 / |---------| \ 1336 / I \ 1337 / I \ 1338 / |----------| \ 1339 / | Policy | \ 1340 / | Server | \ 1341 / |----------| \ 1342 / // \\ \ 1343 / // \\ \ 1344 / // \\ \ 1345 |----| |********| *** |*********| |----| 1346 | S |-----------| |------*r*-----| |----------| R | 1347 |----| | RSVP | *** | RSVP | |----| 1348 | Sender | | Receiver| 1349 | Proxy | | Proxy | 1350 |********| |*********| 1352 =====RSVP========> 1354 **********************************************************> 1356 |----| Non-RSVP-capable |----| Non-RSVP-capable *** 1357 | S | Sender | R | Receiver *r* regular RSVP 1358 |----| |----| *** router 1360 ***> media flow 1362 ==> segment of flow path protected by RSVP reservation 1364 /\ Application signaling (e.g. SIP) 1366 // RSVP Proxy control interface 1368 I Interface between Application Entity and Policy Server 1370 Figure 13: Policy_Server-Controlled Proxy 1372 This RSVP Proxy approach does not require any extension to the RSVP 1373 protocol. However, as with the Application_Entity-Controlled Proxy 1374 approach presented in Figure 10, this approach relies on an RSVP 1375 Proxy control interface allowing control of the RSVP Proxy (by the 1376 Policy Server in this case). This RSVP Proxy control interface is 1377 beyond the scope of the present document. Considerations about 1378 candidate protocols for realizing such interface can be found in 1379 Section 4.5. Again, for situations where only the RSVP Sender Proxy 1380 has to be controlled by this interface, the interface may be realized 1381 through the simple use of RSVP Itself, over a GRE tunnel from the 1382 Policy Server to the RSVP Sender Proxy. This is similar to what is 1383 presented in Section 4.5.1 except that the "RSVP over GRE" interface 1384 is used in this case by the Policy Server (instead of the application 1385 entity). 1387 The interface between the Application Entity and the Policy Server is 1388 beyond the scope of this document. 1390 4.7. RSVP-Signaling-Triggered Proxy 1392 An RSVP Proxy can also be triggered and controlled through extended 1393 RSVP signaling from the remote end that is RSVP-capable (and supports 1394 these RSVP extensions for Proxy control). For example, an RSVP 1395 capable sender could send a new or extended RSVP message explicitly 1396 requesting an RSVP Proxy on the path towards the receiver to behave 1397 as an RSVP Receiver Proxy and also to trigger a reverse direction 1398 reservation thus also behaving as a RSVP Sender Proxy. The new or 1399 extended RSVP message sent by the sender could also include 1400 attributes (e.g. Bandwidth) for the reservations to be signaled by 1401 the RSVP Proxy. 1403 The challenges in these explicit signaling schemes include: 1405 o How can the nodes determine when a reservation request ought to be 1406 proxied and when it should not, and accordingly invoke appropriate 1407 signaling procedures? 1409 o How does the node sending the messages explicitly triggering the 1410 Proxy know where the Proxy is located, e.g., determine an IP 1411 address of the proxy that should reply to the signaling? 1413 o How is all the information needed by a Sender Proxy to generate a 1414 Path message actually communicated to the Proxy? 1416 An example of such a mechanism is presented in 1417 [I-D.manner-tsvwg-rsvp-proxy-sig]. This scheme is primarily targeted 1418 to local access network reservations whereby an end host can request 1419 resource reservations for both incoming and outgoing flows only over 1420 the access network. This may be useful in environments where the 1421 access network is typically the bottleneck while the core is 1422 comparatively over-provisioned, as may be the case with a number of 1423 radio access technologies. In this proposal, messages targeted to 1424 the Proxy are flagged with one bit in all RSVP messages. Similarly, 1425 all RSVP messages sent back by the Proxy are also flagged. The use 1426 of such a flag allows differentiating between proxied and end-to-end 1427 reservations. For triggering an RSVP Receiver Proxy, the sender of 1428 the data sends a Path message which is marked with the mentioned 1429 flag. The Receiver Proxy is located on the signaling and data path, 1430 eventually gets the Path message, and replies back with a Resv 1431 message. A node triggers an RSVP Sender Proxy with a newly defined 1432 Path_Request message, which instructs the proxy to send Path messages 1433 towards the triggering node. The node then replies back with a Resv. 1434 More details can be found in [I-D.manner-tsvwg-rsvp-proxy-sig]. 1436 Such an RSVP-Signaling-Triggered Proxy approach would require RSVP 1437 signaling extensions (that are outside the scope of the present 1438 document). However it could provide more flexibility in the control 1439 of the Proxy behavior (e.g. Control of reverse reservation 1440 parameters) than provided by the Path-Triggered approaches defined in 1441 Section 4.1 and Section 4.2. 1443 Through potential corresponding protocol extensions, an RSVP- 1444 Signaling-Triggered Proxy approach could facilitate operation (e.g. 1445 Reduce or avoid the need for associated configuration) in hybrid 1446 environments involving both reservations established end-to-end and 1447 reservations established via RSVP Proxies. For 1448 example,[I-D.manner-tsvwg-rsvp-proxy-sig] proposed a mechanism 1449 allowing an end-system to control whether a reservation can be 1450 handled by an RSVP Proxy on the path or is to be established end-to- 1451 end. 1453 4.8. Reachability Considerations 1455 There may be situations where the RSVP Receiver Proxy is reachable by 1456 the sender, while the receiver itself is not. In such situations, it 1457 is possible that the RSVP Receiver Proxy is not always aware that the 1458 receiver is unreachable, and consequently may accept to establish an 1459 RSVP reservation on behalf of that receiver. This would result in 1460 unnecessary reservation establishment and unnecessary network 1461 resource consumption. 1463 This is not considered a significant practical concern for a number 1464 of reasons. First, in many cases, if the receiver is not reachable 1465 from the sender, it will not be reachable either for application 1466 signaling so that application level session establishment will not be 1467 possible in the first place. Secondly, where the receiver is 1468 unreachable from the sender but is reachable for application level 1469 signaling (say because session establishment is performed through an 1470 off-path SIP agent that uses a different logical topology to 1471 communicate with the receiver), then the sender may detect that the 1472 receiver is unreachable before attempting reservation establishment. 1473 This may be achieved through mechanisms such as ICE's connectivity 1474 check ( [I-D.ietf-mmusic-ice]). Finally, even if the sender does not 1475 detect that the receiver is unreachable before triggering the RSVP 1476 reservation establishment, it is very likely that the application 1477 will quickly realise this lack of connectivity (e.g. The human 1478 accepting the phone call on the receiver side will not hear the 1479 human's voice on the sender side) and therefore tear down the session 1480 (e.g. Hang up the phone) which in turn will trigger RSVP reservation 1481 release. 1483 Nonetheless, it is recommended that network administrators consider 1484 the above in light of their particular environment when deploying 1485 RSVP Proxys. 1487 The mirror considerations apply for situations involving an RSVP 1488 Sender Proxy and where the sender cannot reach the destination while 1489 the RSVP Sender Proxy can. 1491 5. Security Considerations 1493 In the environments of concern for this document, RSVP messages are 1494 used to control resource reservations on a segment of the end-to-end 1495 path of flows. The general security considerations associated with 1496 [RFC2205] apply. To ensure the integrity of the associated 1497 reservation and admission control mechanisms, the RSVP cryptographic 1498 authentication mechanisms defined in [RFC2747]] and [RFC3097] can be 1499 used. Those protect RSVP messages integrity hop-by-hop and provide 1500 node authentication, thereby protecting against corruption, spoofing 1501 of RSVP messages and replay. 1502 [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types and 1503 key provisioning methods as well as their respective applicability to 1504 RSVP authentication. 1506 [I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses 1507 applicability of IPsec mechanisms ([RFC4303], [RFC4303]) and 1508 associated key provisioning methods for security protection of RSVP. 1509 This discusion applies to the protection of RSVP in the presence of 1510 RSVP Proxies as defined in the present document. 1512 A subset of RSVP messages are signaled with the router alert option 1513 ([RFC2113],[RFC2711]). Based on the current security concerns 1514 associated with the use of the IP router alert option, the 1515 applicability of RSVP (and therefore of the RSVP Proxy approaches 1516 discussed in the present document) is limited to controlled 1517 environments (i.e. Environments where the security risks associated 1518 with the use of the router alert option are understood and protected 1519 against). The security aspects and common practices around the use 1520 of the current IP router alert option and consequences of using the 1521 IP router alert option by applications such as RSVP are discussed in 1522 details in [I-D.rahman-rtg-router-alert-considerations]. 1524 A number of additional security considerations apply to the use of 1525 RSVP proxies and are discussed below. 1527 With some RSVP Proxy approaches, the RSVP proxy operates autonomously 1528 inside an RSVP router. This is the case for the Path-Triggered Proxy 1529 approaches defined in Section 4.1 and in Section 4.2, for the 1530 Inspection-Triggered Proxy approach defined in Section 4.3, for the 1531 STUN-Triggered Proxy approach defined in Section 4.4 and for the 1532 RSVP-Signaling-Triggered approach defined in Section 4.7. Proper 1533 reservation operation assumes that the RSVP proxy can be trusted to 1534 behave correctly in order to control the RSVP reservation as required 1535 and expected by the end systems. Since, the basic RSVP operation 1536 already assumes a trust model where end-systems trust RSVP nodes to 1537 appropriately perform RSVP reservations, the use of RSVP proxy that 1538 behave autonomously within an RSVP router is not seen as introducing 1539 any significant additional security threat or as fundamentally 1540 modifying the RSVP trust model. 1542 With some RSVP Proxy approaches, the RSVP proxy operates under the 1543 control of another entity. This is the case for the 1544 Application_Entity-Controlled Proxy approach defined in Section 4.5 1545 and for the Policy_Server-Controlled Proxy approach defined in 1546 Section 4.6. This introduces additional security risks since the 1547 entity controlling the RSVP Proxy needs to be trusted for proper 1548 reservation operation and also introduces additional authentication 1549 and confidentiality requirements. The exact mechanisms to establish 1550 such trust, authentication and confidentiality are beyond the scope 1551 of this document, but they may include security mechanisms inside the 1552 protocol used as the control interface between the RSVP Proxy and the 1553 entity controlling it, as well as security mechanisms for all the 1554 interfaces involved in the reservation control chain (e.g. Inside 1555 the application signaling protocol between the end systems and the 1556 application entity, and, in the case of the Policy_Server-Controlled 1557 Proxy approach, in the protocol between the application entity and 1558 the policy server). 1560 In some situations, the use of RSVP Proxy to control reservations on 1561 behalf of end-systems may actually reduce the security risk (at least 1562 from the network operator viewpoint). This could be the case, for 1563 example, because the routers where the RSVP Proxy functionality runs 1564 are less exposed to tampering than end-systems. Such a case is 1565 further discussed in section 4 of [I-D.ietf-tsvwg-rsvp-proxy-proto]. 1566 This could also be the case because the use of RSVP Proxy allows 1567 localization of RSVP operation within the boundaries of a given 1568 administrative domain (thus easily operating as a controlled 1569 environment) while the end-to-end flow path spans multiple 1570 administrative domains. 1572 6. IANA Considerations 1574 This document does not make any request to IANA registration. 1576 7. Acknowledgments 1578 This document benefited from earlier work on the concept of RSVP 1579 Proxy including the one documented by Silvano Gai, Dinesh Dutt, 1580 Nitsan Elfassy and Yoram Bernet. It also benefited from discussions 1581 with Pratik Bose, Chris Christou and Michael Davenport. Tullio 1582 Loffredo and Massimo Sassi provided the base material for 1583 Section 4.6. Thanks to James Polk, Magnus Westerlund, Dan Romascanu, 1584 Ross Callon, Cullen Jennings and Jari Arkko for their thorough review 1585 and comments. 1587 8. References 1589 8.1. Normative References 1591 [I-D.ietf-mmusic-ice] 1592 Rosenberg, J., "Interactive Connectivity Establishment 1593 (ICE): A Protocol for Network Address Translator (NAT) 1594 Traversal for Offer/Answer Protocols", 1595 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1597 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1598 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1599 Functional Specification", RFC 2205, September 1997. 1601 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1602 Services", RFC 2210, September 1997. 1604 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1605 and W. Weiss, "An Architecture for Differentiated 1606 Services", RFC 2475, December 1998. 1608 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1609 Authentication", RFC 2747, January 2000. 1611 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 1612 Authentication -- Updated Message Type Value", RFC 3097, 1613 April 2001. 1615 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1616 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1617 October 2008. 1619 8.2. Informative References 1621 [I-D.ietf-dime-diameter-qos] 1622 Zorn, G., "Protocol for Diameter Quality of Service 1623 Application", November 2007. 1625 [I-D.ietf-nsis-qos-nslp] 1626 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 1627 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 1628 (work in progress), January 2010. 1630 [I-D.ietf-sipping-sbc-funcs] 1631 Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 1632 A., and M. Bhatia, "Requirements from SIP (Session 1633 Initiation Protocol) Session Border Control Deployments", 1634 April 2007. 1636 [I-D.ietf-tsvwg-rsvp-proxy-proto] 1637 Faucheur, F., Guillou, A., Manner, J., Malik, H., and A. 1638 Narayanan, "RSVP Extensions for Path-Triggered RSVP 1639 Receiver Proxy", draft-ietf-tsvwg-rsvp-proxy-proto-10 1640 (work in progress), October 2009. 1642 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 1643 Behringer, M. and F. Faucheur, "Applicability of Keying 1644 Methods for RSVP Security", 1645 draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in 1646 progress), June 2009. 1648 [I-D.manner-tsvwg-rsvp-proxy-sig] 1649 Manner, J., "Localized RSVP for Controlling RSVP Proxies", 1650 October 2006. 1652 [I-D.rahman-rtg-router-alert-considerations] 1653 Faucheur, F., "IP Router Alert Considerations and Usage", 1654 draft-rahman-rtg-router-alert-considerations-03 (work in 1655 progress), October 2009. 1657 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1658 Services in the Internet Architecture: an Overview", 1659 RFC 1633, June 1994. 1661 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 1662 February 1997. 1664 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1665 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1667 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1668 "Definition of the Differentiated Services Field (DS 1669 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1670 December 1998. 1672 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1673 RFC 2711, October 1999. 1675 [RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub 1676 Application Identity Policy Element for Use with RSVP", 1677 RFC 2872, June 2000. 1679 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1680 and S. Molendini, "RSVP Refresh Overhead Reduction 1681 Extensions", RFC 2961, April 2001. 1683 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1684 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 1685 RFC 3175, September 2001. 1687 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1688 A., Peterson, J., Sparks, R., Handley, M., and E. 1689 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1690 June 2002. 1692 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 1693 "Integration of Resource Management and Session Initiation 1694 Protocol (SIP)", RFC 3312, October 2002. 1696 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1697 Jacobson, "RTP: A Transport Protocol for Real-Time 1698 Applications", STD 64, RFC 3550, July 2003. 1700 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1701 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1703 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 1704 Moore, "Policy Quality of Service (QoS) Information 1705 Model", RFC 3644, November 2003. 1707 [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session 1708 Initiation Protocol (SIP) Preconditions Framework", 1709 RFC 4032, March 2005. 1711 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1712 Internet Protocol", RFC 4301, December 2005. 1714 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1715 RFC 4303, December 2005. 1717 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1718 Description Protocol", RFC 4566, July 2006. 1720 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 1721 December 2006. 1723 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 1724 Davenport, "Generic Aggregate Resource ReSerVation 1725 Protocol (RSVP) Reservations", RFC 4860, May 2007. 1727 [RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling 1728 in a Nested Virtual Private Network", RFC 4923, 1729 August 2007. 1731 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 1732 Notifications", RFC 5277, July 2008. 1734 [RFC5432] Polk, J., Dhesikan, S., and G. Camarillo, "Quality of 1735 Service (QoS) Mechanism Selection in the Session 1736 Description Protocol (SDP)", RFC 5432, March 2009. 1738 [W3C] "World Wide Web Consortium (W3C) - Web Services 1739 Architecture", . 1741 Appendix A. Use Cases for RSVP Proxies 1743 A.1. RSVP-based VoD Admission Control in Broadband Aggregation Networks 1745 As broadband services for residential are becoming more and more 1746 prevalent, next generation aggregation networks are being deployed in 1747 order to aggregate traffic from broadband users (whether attached via 1748 Digital Subscriber Line technology aka DSL, Fiber To The Home/Curb 1749 aka FTTx, Cable or other broadband access technology). Video on 1750 Demand (VoD) services which may be offered to broadband users present 1751 significant capacity planning challenges for the aggregation network 1752 for a number of reasons. First each VoD stream requires significant 1753 dedicated sustained bandwidth (typically 2-4 Mb/s in Standard 1754 Definition TV and 6-12 Mb/s in High Definition TV). Secondly, the 1755 VoD codec algorithms are very sensitive to packet loss. Finally, the 1756 load resulting from such services is very hard to predict (e.g. It 1757 can vary very suddenly with block-buster titles made available as 1758 well as with promotional offerings). As a result, transport of VoD 1759 streams on the aggregation network usually translate into a strong 1760 requirement for admission control. The admission control solution 1761 protects the quality of established VoD sessions by rejecting the 1762 additional excessive session attempts during unpredictable peaks, 1763 during link or node failures, or combination of those factors. 1765 RSVP can be used in the aggregation network for admission control of 1766 the VoD sessions. However, since Customer Premises equipment such as 1767 Set Top Boxes (which behave as the receiver for VoD streams) often do 1768 not support RSVP, the last IP hop in the aggregation network can 1769 behave as an RSVP Receiver Proxy. This way, RSVP can be used between 1770 VoD Pumps and the last IP hop in the Aggregation network to perform 1771 accurate admission control of VoD streams over the resources set 1772 aside for VoD in the aggregation network (typically a certain 1773 percentage of the bandwidth of any link). As VoD streams are 1774 unidirectional, a simple "Path-Triggered" RSVP Receiver Proxy (as 1775 described in Section 4.1) is all that is required in this use case. 1777 Figure 14 illustrates operation of RSVP-based admission control of 1778 VoD sessions in an aggregation network involving RSVP support on the 1779 VoD Pump (the senders) and RSVP Receiver Proxy on the last IP hop of 1780 the aggregation network. All the customer premises equipment remain 1781 RSVP unaware. 1783 |-------------| 1784 | VoD SRM | 1785 | | 1786 ////////| |\\\\\\\\\\\\\\ 1787 / |-------------| \ 1788 / \ 1789 / \ 1790 / \ 1791 / \ 1792 / \ 1793 |****| *** *** *** |********| |-----| |---| 1794 |VoD |---*r*---*r*---*r*---|RSVP |---|DSLAM|~~~~|STB|--TV 1795 |Pump| *** *** *** |Receiver| |-----| |---| 1796 |****| |Proxy | 1797 |********| 1799 <---Aggregation Net-----------> 1801 ************************************************> 1803 ==============RSVP================> 1805 SRM Session Resource Manager 1807 *** |---| 1808 *r* regular RSVP |STB| Set Top Box 1809 *** router |---| 1811 ***> VoD media flow 1813 ==> segment of flow path protected by RSVP reservation 1815 /\ VoD Application level signaling (e.g. RTSP) 1817 Figure 14: VoD Use Case with Receiver Proxy 1819 In the case where the VoD Pumps are not RSVP-capable, an 1820 Application_Entity-Controlled Sender Proxy via "RSVP over GRE" 1821 approach (as described in Section 4.5.1) can also be implemented on 1822 the VoD Controller or Session Resource Manager (SRM) devices 1823 typically involved in VoD deployments. Figure 15 illustrates 1824 operation of RSVP-based admission control of VoD sessions in an 1825 Aggregation network involving such Application_Entity-Controlled 1826 Source Proxy combined with an RSVP Receiver Proxy on the last IP hop 1827 of the aggregation network. All the customer premises equipment, as 1828 well as the VoD pumps, remain RSVP unaware. 1830 |-------------| 1831 ////| VoD SRM |\\\\\\\\\\\ 1832 / | | \ 1833 / | + | \ 1834 / | RSVP Sender | \ 1835 / |Proxy Control| \ 1836 / |-------------| \ 1837 / /=/ \ 1838 / /=/ \ 1839 / /=/ \ 1840 / /=/ \ 1841 / /=/ \ 1842 |----| |******| *** *** |********| |-----| |---| 1843 | VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV 1844 |Pump| |Sender| *** *** |Receiver| |-----| |---| 1845 |----| |Proxy | |Proxy | 1846 |******| |********| 1848 <---Aggregation Net-------------> 1850 ************************************************> 1852 =========RSVP==============> 1854 SRM Systems Resource Manager 1856 *** |---| 1857 *r* regular RSVP |STB| Set Top Box 1858 *** router |---| 1860 ***> VoD media flow 1862 ==> segment of flow path protected by RSVP reservation 1864 / VoD Application level signaling (e.g. RTSP) 1866 /=/ GRE-tunnelled RSVP (Path messages) 1868 Figure 15: VoD Use Case with Receiver Proxy and SRM-based Sender 1869 Proxy 1871 The RSVP Proxy entities specified in this document play a significant 1872 role here since they allow immediate deployment of an RSVP-based 1873 admission control solution for VoD without requiring any upgrade to 1874 the huge installed base of non-RSVP-capable customer premises 1875 equipment. In one mode described above, they also avoid upgrade of 1876 non-RSVP-capable VoD pumps. In turn, this means that the benefits of 1877 on-path admission control can be offered to VoD services over 1878 broadband aggregation networks without network or VoD Pump upgrade. 1879 Those include accurate bandwidth accounting regardless of topology 1880 (hub-and-spoke, ring, mesh, star, arbitrary combinations) and dynamic 1881 adjustment to any change in topology (such as failure, routing 1882 change, additional links...). 1884 A.2. RSVP-based Voice/Video CAC in Enterprise WAN 1886 More and more enterprises are migrating their telephony and 1887 videoconferencing applications onto IP. When doing so, there is a 1888 need for retaining admission control capabilities of existing TDM- 1889 based systems to ensure the QoS of these applications is maintained 1890 even when transiting through the enterprise's Wide Area Network 1891 (WAN). Since many of the endpoints already deployed (such as IP 1892 Phones or Videoconferencing terminals) are not RSVP capable, RSVP 1893 Proxy approaches are very useful: they allow deployment of an RSVP- 1894 based admission control solution over the WAN without requiring 1895 upgrade of the existing terminals. 1897 A common deployment architecture for such environments relies on the 1898 Application_Entity-Controlled Proxy approach as defined in 1899 Section 4.5. Routers sitting at the edges of the WAN network and 1900 naturally "on-path" for all inter-campus calls (or sessions) and 1901 behave as RSVP Proxies. The RSVP Proxies establish, maintain and 1902 tear-down RSVP reservations over the WAN segment for the calls (or 1903 sessions) under the control of the SIP Server/Proxy. The SIP Server/ 1904 Proxy synchronizes the RSVP reservation status with the status of 1905 end-to-end calls. For example, the called IP phone will only be 1906 instructed to play a ring tone if the RSVP reservations over the 1907 corresponding WAN segment has been successfully established. 1909 This architecture allowing RSVP-based admission control of voice and 1910 video on the Enterprise WAN is illustrated in Figure 16. 1912 |---------| 1913 //////////////| SIP |\\\\\\\\\\\\ 1914 / | Server/ | \ 1915 / | Proxy | \ 1916 / |---------| \ 1917 / // \\ \ 1918 / // \\ \ 1919 / // \\ \ 1920 / // \\ \ 1921 / // \\ \ 1922 |-----| |********| *** *** |********| |-----| 1923 | IP |------| Media |---*r*---*r*---| Media |-------|IP | 1924 |Phone| | Relay | *** *** | Relay | |Phone| 1925 |-----| | + | | + | |-----| 1926 | RSVP | | RSVP | 1927 | Proxy | | Proxy | 1928 |********| |********| 1930 <--campus--> <--campus--> 1931 network network 1933 <---------WAN-----------> 1935 <*************> <***********************> <**************> 1937 <=========RSVP===========> 1939 *** 1940 *r* Regular RSVP router 1941 *** 1943 <***> media flow 1945 <==> segment of flow path protected by RSVP reservation 1947 /\ SIP signaling 1949 // control interface between the SIP Server/Proxy and 1950 RSVP Proxy 1952 Figure 16: CAC on Enterprise WAN Use Case 1954 A.3. RSVP Proxies for Mobile Access Networks 1956 Mobile access networks are increasingly based on IP technology. This 1957 implies that, on the network layer, all traffic, both traditional 1958 data and streamed data like audio or video, is transmitted as 1959 packets. Increasingly popular multimedia applications would benefit 1960 from better than best-effort service from the network, a forwarding 1961 service with strict Quality of Service (QoS) with guaranteed minimum 1962 bandwidth and bounded delay. Other applications, such as electronic 1963 commerce, network control and management, and remote login 1964 applications, would also benefit from a differentiated treatment. 1966 The IETF has two main models for providing differentiated treatment 1967 of packets in routers. The Integrated Services (IntServ) model 1968 [RFC1633] together with the Resource Reservation Protocol (RSVP) 1969 [RFC2205] [RFC2210] [RFC2961] provides per-flow guaranteed end-to-end 1970 transmission service. The Differentiated Services (DiffServ) 1971 framework [RFC2475] provides non-signaled flow differentiation that 1972 usually provides, but does not guarantee, proper transmission 1973 service. 1975 However, these architectures have potential weaknesses for deployment 1976 in Mobile Access Networks. For example, RSVP requires support from 1977 both communication end points, and the protocol may have potential 1978 performance issues in mobile environments. DiffServ can only provide 1979 statistical guarantees and is not well suited for dynamic 1980 environments. 1982 Let us consider a scenario, where a fixed network correspondent node 1983 (CN) would be sending a multimedia stream to an end host behind a 1984 wireless link. If the correspondent node does not support RSVP it 1985 cannot signal its traffic characteristics to the network and request 1986 specific forwarding services. Likewise, if the correspondent node is 1987 not able to mark its traffic with a proper Differentiated Services 1988 codepoint (DSCP) to trigger service differentiation, the multimedia 1989 stream will get only best-effort service which may result in poor 1990 visual and audio quality in the receiving application. Even if the 1991 connecting wired network is over-provisioned, an end host would still 1992 benefit from local resource reservations, especially in wireless 1993 access networks, where the bottleneck resource is most probably the 1994 wireless link. 1996 RSVP proxies would be a very beneficial solution to this problem. It 1997 would allow distinguishing local network reservations from the end- 1998 to-end reservations. The end host does not need to know the access 1999 network topology or the nodes that will reserve the local resources. 2000 The access network would do resource reservations for both incoming 2001 and outgoing flows based on certain criterion, e.g., filters based on 2002 application protocols. Another option is that the mobile end host 2003 makes an explicit reservation that identifies the intention and the 2004 access network will find the correct local access network node(s) to 2005 respond to the reservation. RSVP proxies would, thus, allow resource 2006 reservation over the segment which is the most likely bottleneck, the 2007 wireless connectivity. If the wireless access network uses a local 2008 mobility management mechanism, where the IP address of the mobile 2009 node does not change during handover, RSVP reservations would follow 2010 the mobile node movement. 2012 A.4. RSVP Proxies for Reservations in the presence of IPsec Gateways 2014 [RFC4923] discusses how resource reservation can be supported end-to- 2015 end in a nested VPN environment. At each VPN level, VPN Routers 2016 behave as [RFC4301] security gateways between a plaintext domain and 2017 a cyphertext domain. To achieve end-to-end resource reservation, the 2018 VPN Routers process RSVP signaling on the plaintext side, perform 2019 aggregation of plaintext reservations, and maintain the corresponding 2020 aggregate RSVP reservations on the cyphertext side. Each aggregate 2021 reservation is established on behalf of multiple encrypted end-to-end 2022 sessions sharing the same ingress and egress VPN Routers. These 2023 aggregate reservations can be as specified in [RFC3175] or [RFC4860]. 2025 Section 3 of [RFC4923] discusses the necessary data flows within a 2026 VPN Router to achieve the behavior described in the previous 2027 paragraph. Two mechanisms are described to achieve such data flows. 2028 Section 3.1 presents the case where the VPN Router carries data 2029 across the cryptographic boundary. Section 3.2 discusses the case 2030 where the VPN router uses a Network-Guard. 2032 Where such mechanisms are not supported by the VPN Routers, the 2033 approach for end-to-end reservation presented in [RFC4923] cannot be 2034 deployed. An alternative approach to support resource reservations 2035 within the cyphertext core is to use the "Application_Entity- 2036 Controlled Proxy" approach (as defined in Section 4.5) in the 2037 following way: 2039 o the RSVP Proxies are located inside the cyphertext domain and use 2040 aggregate RSVP reservations, 2042 o the Application Entity exchange application level signaling with 2043 the end systems in the plaintext domain, 2045 o the Application Entity controls the RSVP Proxies in the cyphertext 2046 domain via an RSVP Proxy control interface 2048 This is illustrated in Figure 17 in the case where the application is 2049 SIP-based multimedia communications. 2051 |-------| |-------| 2052 |SIP |///////////////////\\\\\\\\\\\\\\\\\|SIP | 2053 /|Server/| |Server/|\ 2054 / |Proxy | |Proxy | \ 2055 / |-------| |-------| \ 2056 / ^ \\ // ^ \ 2057 / ^ \\ // ^ \ 2058 / ^ \\ // ^ \ 2059 |***| |------| |********| *** *** |********| |------| |***| 2060 | S |---|IPsec |--| ARSVP |---*r*---*r*---| ARSVP |--|IPsec |---| R | 2061 |***| | GW | | Sender | *** *** |Receiver| | GW | |***| 2062 |------| | Proxy | | Proxy | |------| 2063 |********| |********| 2065 ***PT*****> **********************CT****************> ****PT***> 2067 =====> =====> 2068 =====ARSVP======> 2070 |****| RSVP-capable |****| RSVP-capable *** 2071 | S | Sender | R | Receiver *r* regular RSVP 2072 |****| |****| *** router 2074 |------| 2075 |IPsec | IPsec security gateway 2076 | GW | 2077 |------| 2079 ARSVP Aggregate RSVP 2081 ***> media flow 2083 ==> segment of flow path protected by RSVP reservation 2085 / \ SIP signaling 2087 ^ Network management interface between SIP Server/Proxy 2088 and IPsec security gateway 2090 // control interface between SIP Server/Proxy and ARSVP Proxy 2092 PT Plaintext network 2094 CT Cyphertext network 2096 Figure 17: RSVP Proxies for Reservations in the Presence of IPsec 2097 Gateways 2099 Where the sender and receiver are RSVP capable, they may also use 2100 RSVP signaling. This achieves resource reservation on the plaintext 2101 segments of the end-to-end i.e. : 2103 o from the sender to the ingress IPsec gateway and 2105 o from the egress IPsec gateway to the receiver. 2107 In this use case, because the VPN Routers do not support any RSVP 2108 specific mechanism, the end-to-end RSVP signaling is effectively 2109 hidden by the IPsec gateways on the cyphertext segment of the end-to- 2110 end path. 2112 As with the "Application_Entity-Controlled Proxy" approach (defined 2113 in Section 4.5), the solution here for synchronizing RSVP signaling 2114 with application-level signaling is to rely on an application-level 2115 signaling device that controls an on-path RSVP Proxy function. 2116 However, in the present use case, the RSVP Proxies are a component of 2117 a cyphertext network where all user (bearer) traffic is IPsec 2118 encrypted. This has a number of implications including the 2119 following: 2121 1. encrypted flows can not be identified in the cyphertext domain so 2122 that network nodes can only classify traffic based on IP address 2123 and Differentiated Services codepoints (DSCPs). As a result, 2124 only aggregate RSVP reservations (such as those specified in 2125 [RFC3175] or [RFC4860] ) can be used. This is similar to 2126 [RFC4923]. 2128 2. Determining the RSVP Sender proxy and RSVP receiver Proxy to be 2129 used for aggregation of a given flow from sender to receiver 2130 creates a number of challenges. Details on how this may be 2131 achieved are beyond the scope of this document. We observe that, 2132 as illustrated in Figure 17, this may be facilitated by a network 2133 management interface between the application entity and the IPsec 2134 gateways. For example, this interface may be used by the 2135 application entity to obtain information about which IPsec 2136 gateway is on the path of a given end-to-end flow. Then, the 2137 application entity may maintain awareness of which RSVP Proxy is 2138 on the cyphertext path between a given pair of IPsec gateways. 2139 How such awareness is achieved is beyond the scope of this 2140 document. We simply observe that such awareness can be easily 2141 achieved through simple configuration in the particular case 2142 where a single (physical or logical) RSVP Proxy is fronting a 2143 given IPsec gateway. We also observe that when awareness of the 2144 RSVP Receiver Proxy for a particular egress IPsec gateway (or 2145 end-to-end flow) is not available, the aggregate reservation may 2146 be signaled by the RSVP Sender Proxy to the destination address 2147 of the egress IPsec gateway and then proxied by the RSVP Receiver 2148 Proxy. 2150 Different flavors of operations are possible in terms of aggregate 2151 reservation sizing. For example, the application entity can initiate 2152 an aggregate reservation of fixed size a priori and then simply keep 2153 count of the bandwidth used by sessions and reject sessions that 2154 would result in excess usage of an aggregate reservation. The 2155 application entity could also re-size the aggregate reservations on a 2156 session by session basis. Alternatively, the application entity 2157 could re-size the aggregate reservations in step increments typically 2158 corresponding to the bandwidth requirement of multiple sessions. 2160 Authors' Addresses 2162 Francois Le Faucheur 2163 Cisco Systems 2164 Greenside, 400 Avenue de Roumanille 2165 Sophia Antipolis 06410 2166 France 2168 Phone: +33 4 97 23 26 19 2169 Email: flefauch@cisco.com 2171 Jukka Manner 2172 Helsinki University of Technology (TKK) 2173 P.O. Box 3000 2174 Espoo FIN-02015 TKK 2175 Finland 2177 Phone: +358 9 451 2481 2178 Email: jukka.manner@tkk.fi 2179 URI: http://www.netlab.tkk.fi/~jmanner/ 2181 Dan Wing 2182 Cisco Systems 2183 170 West Tasman Drive 2184 San Jose, CA 95134 2185 United States 2187 Email: dwing@cisco.com 2188 Allan Guillou 2189 SFR 2190 40-42 Quai du Point du Jour 2191 Boulogne-Billancourt, 92659 2192 France 2194 Phone: 2195 Fax: 2196 Email: allan.guillou@sfr.com 2197 URI: