idnits 2.17.1 draft-ietf-tsvwg-rsvp-dste-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1097. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1079. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1085. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([KEYWORDS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 24 has weird spacing: '... and may be...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2006) is 6431 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BCP 78' is defined on line 957, but no explicit reference was found in the text == Unused Reference: 'BCP 79' is defined on line 960, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3978 (ref. 'BCP 78') (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 3668 (ref. 'BCP 79') (Obsoleted by RFC 3979) ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DIFFSERV') ** Downref: Normative reference to an Informational RFC: RFC 2998 (ref. 'INT-DIFF') ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. 'INT-SERV') ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'MPLS-TE') == Outdated reference: A later version (-02) exists of draft-vasseur-ccamp-automesh-00 Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RSVP Aggregation over MPLS TE tunnels September 2006 3 Internet Draft Francois Le Faucheur 4 Editor 5 Cisco Systems, Inc. 7 draft-ietf-tsvwg-rsvp-dste-05.txt 8 Expires: March 2007 September 2006 10 Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 RFC 3175 specifies aggregation of RSVP end-to-end reservations over 37 aggregate RSVP reservations. This document specifies aggregation of 38 RSVP end-to-end reservations over MPLS Traffic Engineering (TE) 39 tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) 40 Tunnels. This approach is based on RFC 3175 and simply modifies the 41 corresponding procedures for operations over MPLS TE tunnels instead 42 of aggregate RSVP reservations. This approach can be used to achieve 43 admission control of a very large number of flows in a scalable 44 manner since the devices in the core of the network are unaware of 45 the end-to-end RSVP reservations and are only aware of the MPLS TE 46 tunnels. 48 RSVP Aggregation over MPLS TE tunnels September 2006 50 Copyright Notice 51 Copyright (C) The Internet Society (2006). 53 Specification of Requirements 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [KEYWORDS]. 59 Table of Contents 61 1. Introduction...................................................2 62 2. Contributing Authors...........................................6 63 3. Definitions....................................................7 64 4. Operations of RSVP Aggregation over TE with pre-established 65 Tunnels...........................................................8 66 4.1. Reference Model...........................................9 67 4.2. Receipt of E2E Path message By the Aggregator............10 68 4.3. Handling of E2E Path message By Transit LSRs.............11 69 4.4. Receipt of E2E Path Message by Deaggregator..............12 70 4.5. Handling of E2E Resv Message by Deaggregator.............12 71 4.6. Handling of E2E Resv Message by the Aggregator...........13 72 4.7. Forwarding of E2E traffic by Aggregator..................14 73 4.8. Removal of E2E reservations..............................14 74 4.9. Removal of TE Tunnel.....................................15 75 4.10. Example Signaling Flow..................................16 76 5. IPv4 and IPv6 Applicability...................................17 77 6. E2E Reservations Applicability................................17 78 7. Example Deployment Scenarios..................................17 79 7.1. Voice and Video Reservations Scenario....................17 80 7.2. PSTN/3G Voice Trunking Scenario..........................18 81 8. Security Considerations.......................................19 82 9. IANA Considerations...........................................20 83 10. Acknowledgments..............................................21 84 11. Normative References.........................................21 85 12. Informative References.......................................22 86 13. Editor's Address:............................................23 87 Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator.......24 88 Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels for 89 VoIP Call Admission Control (CAC)................................26 91 1. Introduction 93 RSVP Aggregation over MPLS TE tunnels September 2006 95 The Integrated Services (Intserv) [INT-SERV] architecture provides a 96 means for the delivery of end-to-end Quality of Service (QoS) to 97 applications over heterogeneous networks. 99 [RSVP] defines the Resource reSerVation Protocol which can be used by 100 applications to request resources from the network. The network 101 responds by explicitely admitting or rejecting these RSVP requests. 102 Certain applications that have quantifiable resource requirements 103 express these requirements using Intserv parameters as defined in the 104 appropriate Intserv service specifications ([GUARANTEED], 105 [CONTROLLED]). 107 The Differentiated Services (DiffServ) architecture ([DIFFSERV]) was 108 then developed to support differentiated treatment of packets in very 109 large scale environments. In contrast to the per-flow orientation of 110 Intserv and RSVP, Diffserv networks classify packets into one of a 111 small number of aggregated flows or "classes", based on the Diffserv 112 codepoint (DSCP) in the packet IP header. At each Diffserv router, 113 packets are subjected to a "per-hop behavior" (PHB), which is invoked 114 by the DSCP. The primary benefit of Diffserv is its scalability. 115 Diffserv eliminates the need for per-flow state and per-flow 116 processing and therefore scales well to large networks. 118 However, DiffServ does not include any mechanism for communication 119 between applications and the network. Thus, as detailed in [INT-DIFF], 120 significant benefits can be achieved by using Intserv over Diffserv 121 including resource based admission control, policy based admission 122 control, assistance in traffic identification /classification and 123 traffic conditioning. As discussed in [INT-DIFF], Intserv can operate 124 over Diffserv in multiple ways. For example, the Diffserv region may 125 be statically provisioned or may be RSVP aware. When it is RSVP aware, 126 several mechanisms may be used to support dynamic provisioning and 127 topology aware admission control including aggregate RSVP 128 reservations, per flow RSVP or a bandwidth broker. The advantage of 129 using aggregate RSVP reservations is that it offers dynamic, 130 topology-aware admission control over the Diffserv region without 131 per-flow reservations and the associated level of RSVP signaling in 132 the Diffserv core. In turn, this allows dynamic, topology aware 133 admission control of flows requiring QoS reservations over the 134 Diffserv core even when the total number of such flows carried over 135 the Diffserv core is extremely large. 137 [RSVP-AGG] describes in detail how to perform such aggregation of end 138 to end RSVP reservations over aggregate RSVP reservations in a 139 Diffserv cloud. It establishes an architecture where multiple end-to- 140 end RSVP reservations sharing the same ingress router (Aggregator) 141 and the same egress router (Deaggregator) at the edges of an 142 "aggregation region", can be mapped onto a single aggregate 143 reservation within the aggregation region. This considerably reduces 145 RSVP Aggregation over MPLS TE tunnels September 2006 147 the amount of reservation state that needs to be maintained by 148 routers within the aggregation region. Furthermore, traffic belonging 149 to aggregate reservations is classified in the data path purely using 150 Diffserv marking. 152 [MPLS-TE] describes how MPLS Traffic Engineering (TE) Tunnels can be 153 used to carry arbitrary aggregates of traffic for the purposes of 154 traffic engineering. [RSVP-TE] specifies how such MPLS TE Tunnels can 155 be established using RSVP-TE signaling. MPLS TE uses Constraint Based 156 Routing to compute the path for a TE tunnel. Then, Admission Control 157 is performed during the establishment of TE Tunnels to ensure they 158 are granted their requested resources. 160 [DSTE-REQ] presents the Service Providers requirements for support of 161 Diff-Serv-aware MPLS Traffic Engineering (DS-TE). With DS-TE, 162 separate DS-TE tunnels can be used to carry different Diffserv 163 classes of traffic and different resource constraints can be enforced 164 for these different classes. [DSTE-PROTO] specifies RSVP-TE signaling 165 extensions as well as OSPF and ISIS extensions for support of DS-TE. 167 In the rest of this document we will refer to both TE tunnels and DS- 168 TE tunnels simply as "TE tunnels". 170 TE tunnels have much in common with the aggregate RSVP reservations 171 used in [RSVP-AGG]: 172 - a TE tunnel is subject to Admission Control and thus is 173 effectively an aggregate bandwidth reservation 174 - In the data plane, packet scheduling relies exclusively on 175 Diff-Serv classification and PHBs 176 - Both TE tunnels and aggregate RSVP reservations are controlled 177 by "intelligent" devices on the edge of the "aggregation core" 178 (Head-end and Tail-end in the case of TE tunnels, Aggregator 179 and Deaggregator in the case of aggregate RSVP reservations 180 - Both TE tunnels and aggregate RSVP reservations are signaled 181 using the RSVP protocol (with some extensions defined in [RSVP- 182 TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE 183 tunnels). 185 This document provides a detailed specification for performing 186 aggregation of end-to-end RSVP reservations over MPLS TE tunnels 187 (which act as aggregate reservations in the core). This document 188 builds on the RSVP Aggregation procedures defined in [RSVP-AGG], and 189 only changes those where necessary to operate over TE tunnels. With 190 [RSVP-AGG], a lot of responsibilities (such as mapping end-to-end 191 reservations to Aggregate reservations and resizing the Aggregate 192 reservations) are assigned to the Deaggregator (which is the 193 equivalent of the Tunnel Tail-end) while with TE, the tunnels are 194 controlled by the Tunnel Head-end. Hence, the main change over the 195 RSVP Aggregations procedures defined in [RSVP-AGG] is to modify these 197 RSVP Aggregation over MPLS TE tunnels September 2006 199 procedures to reassign responsibilities from the Deaggregator to the 200 Aggregator (i.e. the tunnel Head-end). 202 [LSP-HIER] defines how to aggregate MPLS TE Label Switched Paths 203 (LSPs) by creating a hierarchy of such LSPs. This involves nesting of 204 end-to-end LSPs into an aggregate LSP in the core (by using the label 205 stack construct). Since end-to-end TE LSPs are themselves signaled 206 with RSVP-TE and reserve resources at every hop, this can be looked 207 at as a form of aggregation of RSVP(-TE) reservations over MPLS TE 208 Tunnels. This document capitalizes on the similarities between 209 nesting of TE LSPs over TE tunnels and RSVP aggregation over TE 210 tunnels and reuses the procedures of [LSP-HIER] wherever possible. 212 This document also builds on the "RSVP over Tunnels" concepts of RFC 213 2746 [RSVP-TUN]. It differs from that specification in the following 214 ways 215 - Whereas RFC 2746 describes operation with IP tunnels, this 216 document describes operation over MPLS tunnels. One consequence 217 of this difference is the need to deal with penultimate hop 218 popping (PHP). 219 - MPLS-TE tunnels inherently reserve resources, whereas the 220 tunnels in RFC 2746 do not have resource reservations by 221 default. This leads to some simplifications in the current 222 document. 223 - This document builds on the fact that there is exactly one 224 aggregate reservation per MPLS-TE tunnel, whereas RFC 2746 225 permits a model where one reservation is established on the 226 tunnel path for each end-to-end flow. 227 - We have assumed in the current document that a given MPLS-TE 228 tunnel will carry reserved traffic and nothing but reserved 229 traffic, which negates the requirement of RFC 2746 to 230 distinguish reserved and non-reserved traffic traversing the 231 same tunnel by using distinct encapsulations. 232 - There may be several MPLS-TE tunnels that share common head and 233 tail end routers, with head-end policy determining which tunnel 234 is appropriate for a particular flow. This scenario does not 235 appear to be addressed in RFC 2746. 237 At the same time, this document does have many similarities with RFC 238 2746. MPLS-TE tunnels are "type 2 tunnels" in the nomenclature of RFC 239 2746: 240 " 241 The (logical) link may be able to promise that some overall 242 level of resources is available to carry traffic, but not to 243 allocate resources specifically to individual data flows. 244 " 246 RSVP Aggregation over MPLS TE tunnels September 2006 248 Aggregation of end-to-end RSVP reservations over TE tunnels combines 249 the benefits of [RSVP-AGG] with the benefits of MPLS including the 250 following: 251 - applications can benefit from dynamic, topology-aware resource- 252 based admission control over any segment of the end to end path 253 including the core 254 - as per regular RSVP behavior, RSVP does not impose any burden 255 on routers where such admission control is not needed (for 256 example if the links upstream and downstream of the MPLS TE 257 core are vastly over-engineered compared to the core capacity, 258 admission control is not required on these over-engineered 259 links and RSVP need not be processed on the corresponding 260 router hops) 261 - the core scalability is not affected (relative to the 262 traditional MPLS TE deployment model) since the core remains 263 unaware of end-to-end RSVP reservations and only has to 264 maintain aggregate TE tunnels and since the datapath 265 classification and scheduling in the core relies purely on 266 Diffserv mechanism (or more precisely MPLS Diffserv mechanisms 267 as specified in [DIFF-MPLS]) 268 - the aggregate reservation (and thus the traffic from the 269 corresponding end to end reservations) can be network 270 engineered via the use of Constraint based routing (e.g. 271 affinity, optimization on different metrics) and when needed 272 can take advantage of resources on other paths than the 273 shortest path 274 - the aggregate reservations (and thus the traffic from the 275 corresponding end to end reservations) can be protected against 276 failure through the use of MPLS Fast Reroute 278 This document, like [RSVP-AGG], covers aggregation of unicast 279 sessions. Aggregation of multicast sessions is for further study. 281 2. Contributing Authors 283 This document was the collective work of several authors. The text 284 and content were contributed by the editor and the co-authors listed 285 below. (The contact information for the editor appears in the 286 Editor's Address section.) 288 Michael DiBiasio 289 Cisco Systems, Inc. 290 300 Beaver Brook Road 291 Boxborough, MA 01719 292 USA 293 Email: dibiasio@cisco.com 295 RSVP Aggregation over MPLS TE tunnels September 2006 297 Bruce Davie 298 Cisco Systems, Inc. 299 300 Beaver Brook Road 300 Boxborough, MA 01719 301 USA 302 Email: bdavie@cisco.com 304 Christou Christou 305 Booz Allen Hamilton 306 8283 Greensboro Drive 307 McLean, VA 22102 308 USA 309 Email: christou_chris@bah.com 311 Michael Davenport 312 Booz Allen Hamilton 313 8283 Greensboro Drive 314 McLean, VA 22102 315 USA 316 Email: davenport_michael@bah.com 318 Jerry Ash 319 AT&T 320 200 Laurel Avenue 321 Middletown, NJ 07748, USA 322 USA 323 Email: gash@att.com 325 Bur Goode 326 AT&T 327 32 Old Orchard Drive 328 Weston, CT 06883 329 USA 330 Email: bgoode@att.com 332 3. Definitions 334 For readability, a number of definitions from [RSVP-AGG] as well as 335 definitions for commonly used MPLS TE terms are provided here: 337 Aggregator This is the process in (or associated with) the router 338 at the ingress edge of the aggregation region (with 340 RSVP Aggregation over MPLS TE tunnels September 2006 342 respect to the end to end RSVP reservation) and 343 behaving in accordance with [RSVP-AGG]. In this 344 document, it is also the TE Tunnel Head-end. 346 Deaggregator This is the process in (or associated with) the router 347 at the egress edge of the aggregation region (with 348 respect to the end to end RSVP reservation) and 349 behaving in accordance with [RSVP-AGG]. In this 350 document, it is also the TE Tunnel Tail-end 352 E2E End to end 354 E2E reservation This is an RSVP reservation such that: 355 (i) corresponding Path messages are initiated 356 upstream of the Aggregator and terminated 357 downstream of the Deaggregator, and 358 (ii) corresponding Resv messages are initiated 359 downstream of the Deaggregator and 360 terminated upstream of the Aggregator, and 361 (iii) this RSVP reservation is to be aggregated 362 over an MPLS TE tunnel between the 363 Aggregator and Deaggregator. 364 An E2E RSVP reservation may be a per-flow 365 reservation. Alternatively, the E2E reservation 366 may itself be an aggregate reservation of various 367 types (e.g. Aggregate IP reservation, Aggregate 368 IPsec reservation). See section 5 and 6 for more 369 details on the types of E2E RSVP reservations. As 370 per regular RSVP operations, E2E RSVP reservations 371 are unidirectional. 373 Head-end 374 This is the Label Switch Router responsible for 375 establishing, maintaining and tearing down a given TE 376 tunnel. 378 Tail-end 379 This is the Label Switch Router responsible for 380 terminating a given TE tunnel 382 Transit LSR This is a Label Switch router that is on the path of a 383 given TE tunnel and is neither the Head-end nor the 384 Tail-end 386 4. Operations of RSVP Aggregation over TE with pre-established Tunnels 388 [RSVP-AGG] supports operations both in the case where aggregate RSVP 389 reservations are pre-established and in the case where Aggregators 390 and Deaggregators have to dynamically discover each other and 391 dynamically establish the necessary aggregate RSVP reservations. 393 RSVP Aggregation over MPLS TE tunnels September 2006 395 Similarly, RSVP Aggregation over TE tunnels could operate both in the 396 case where the TE tunnels are pre-established and in the case where 397 the tunnels need to be dynamically established. 399 In this document we provide a detailed description of the procedures 400 in the case where TE tunnels are already established. These 401 procedures are based on those defined in [LSP-HIER]. The routing 402 aspects discussed in section 3 of [LSP-HIER] are not relevant here 403 because those aim at allowing the constraint based routing of end-to- 404 end TE LSPs to take into account the (aggregate) TE tunnels. In the 405 present document, the end-to-end RSVP reservations to be aggregated 406 over the TE tunnels rely on regular SPF routing. However, as already 407 mentioned in [LSP-HIER], we note that a TE Tunnel may be advertised 408 into ISIS or OSPF, to be used in normal SPF by nodes upstream of the 409 Aggregator. This would affect SPF routing and thus routing of end-to- 410 end RSVP reservations. The control of aggregation boundaries 411 discussed in section 6 of [LSP-HIER] is also not relevant here. This 412 uses information exchanged in GMPLS protocols to dynamically discover 413 the aggregation boundary. In this document, TE tunnels are pre- 414 established, so that the aggregation boundary can be easily inferred. 415 The signaling aspects discussed in section 6.2 of [LSP-HIER] apply to 416 the establishment/termination of the aggregate TE tunnels when this 417 is triggered by GMPLS mechanisms (e.g. as a result of an end-to-end 418 TE LSP establishment request received at the aggregation boundary) . 419 As this document assumes pre-established tunnels, those aspects are 420 not relevant here. The signaling aspects discussed in section 6.1 of 421 [LSP-HIER] relate to the establishment/maintenance of the end-to-end 422 TE LSPs over the aggregate TE tunnel. This document describes how to 423 use the same procedures as those specified in section 6.1 of [LSP- 424 HIER], but for the establishment of end-to-end RSVP reservations 425 (instead of end-to-end TE LSPs) over the TE tunnels. This is covered 426 further in section 4 of the present document. 428 Pre-establishment of the TE tunnels may be triggered by any 429 mechanisms including for example manual configuration or automatic 430 establishment of a TE tunnel mesh through dynamic discovery of TE 431 Mesh membership as allowed in [AUTOMESH]. 433 Procedures in the case of dynamically established TE tunnels are for 434 further studies. 436 4.1. Reference Model 438 |----| |----| 439 H--| R |\ |-----| |------| /| R |--H 440 H--| |\\| | |---| | |//| |--H 441 |----| \| He/ | | T | | Te/ |/ |----| 442 | Agg |=======================| Deag | 444 RSVP Aggregation over MPLS TE tunnels September 2006 446 /| | | | | |\ 447 H--------//| | |---| | |\\--------H 448 H--------/ |-----| |------| \--------H 450 H = Host requesting end-to-end RSVP reservations 451 R = RSVP router 452 He/Agg = TE tunnel Head-end/Aggregator 453 Te/Deag = TE tunnel Tail-end/Deaggregator 454 T = Transit LSR 456 -- = E2E RSVP reservation 457 == = TE Tunnel 459 4.2. Receipt of E2E Path message By the Aggregator 461 The first event is the arrival of the E2E Path message at the 462 Aggregator. The Aggregator MUST follow traditional RSVP procedures 463 for processing of this E2E path message augmented with the extensions 464 documented in this section. 466 The Aggregator MUST first attempt to map the E2E reservation onto a 467 TE tunnel. This decision is made in accordance with routing 468 information as well as any local policy information that may be 469 available at the Aggregator. Examples of such policies appear in the 470 following paragraphs. Just for illustration purposes, among many 471 other criteria, such mapping policies might take into account the 472 Intserv service type, the Application Identity [RSVP-APPID] and/or 473 the signaled preemption [RSVP-PREEMP] of the E2E reservation (for 474 example, the aggregator may take into account the E2E reservations 475 RSVP preemption priority and the MPLS TE Tunnel set-up and/or hold 476 priorities when mapping the E2E reservation onto an MPLS TE tunnel). 478 There are situations where the Aggregator is able to make a final 479 mapping decision. That would be the case, for example, if there is a 480 single TE tunnel towards the destination and if the policy is to map 481 any E2E RSVP reservation onto TE Tunnels. 483 There are situations where the Aggregator is not able to make a final 484 determination. That would be the case, for example, if routing 485 identifies two DS-TE tunnels towards the destination, one belonging 486 to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to 487 map Intserv Guaranteed Services reservations to a Class-Type 1 tunnel 488 and Intserv Controlled Load reservations to a Class-Type 0 tunnel, 489 and if the E2E RSVP Path message advertises both Guaranteed Service 490 and Controlled Load. 492 RSVP Aggregation over MPLS TE tunnels September 2006 494 Whether final or tentative, the Aggregator makes a mapping decision 495 and selects a TE tunnel. Before forwarding the E2E Path message 496 towards the receiver, the Aggregator SHOULD update the ADSPEC inside 497 the E2E Path message to reflect the impact of the MPLS TE cloud onto 498 the QoS achievable by the E2E flow. This update is a local matter and 499 may be based on configured information, on information available in 500 the MPLS TE topology database, on the current TE tunnel path, on 501 information collected via RSVP-TE signaling, or combinations of those. 502 Updating the ADSPEC allow receivers that take into account the 503 information collected in the ADSPEC within the network (such as delay 504 and bandwidth estimates) to make more informed reservation decisions. 506 The Aggregator MUST then forward the E2E Path message to the 507 Deaggregator (which is the tail-end of the selected TE tunnel). In 508 accordance with [LSP-HIER], the Aggregator MUST send the E2E Path 509 message with an IF_ID RSVP_HOP object instead of an RSVP_HOP object. 510 The data interface identification MUST identify the TE Tunnel. 512 To send the E2E Path message, the Aggregator MUST address it directly 513 to the Deaggregator by setting the destination address in the IP 514 Header of the E2E Path message to the Deaggregator address. The 515 Router Alert is not set in the E2E Path message. 517 Optionally, the Aggregator MAY also encapsulate the E2E Path message 518 in an IP tunnel or in the TE tunnel itself. 520 Regardless of the encapsulation method, the Router Alert is not set. 521 Thus, the E2E Path message will not be visible to routers along the 522 path from the Aggregator to the Deaggregator. Therefore, in contrast 523 to the procedures of [RSVP-AGG], the IP Protocol number need not be 524 modified to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating 525 "RSVP") by the Aggregator. 527 In some environments, the Aggregator and Deaggregator MAY also act as 528 IPsec Security Gateways in order to provide IPsec protection to E2E 529 traffic when it transits between the Aggregator and the Deaggregator. 530 In that case, to transmit the E2E Path message to the Deaggregator, 531 the Aggregator MUST send the E2E Path message into the relevant IPsec 532 tunnel terminating on the Deaggregator. 534 E2E PathTear and ResvConf messages MUST be forwarded by the 535 Aggregator to the Deaggregator exactly like Path messages. 537 4.3. Handling of E2E Path message By Transit LSRs 539 Since the E2E Path message is addressed directly to the Deaggregator 540 and does not have Router Alert set, it is hidden from all transit 541 LSRs. 543 RSVP Aggregation over MPLS TE tunnels September 2006 545 4.4. Receipt of E2E Path Message by Deaggregator 547 On receipt of the E2E Path message addressed to it, the Deaggregator 548 will notice that the IP Protocol number is set to "RSVP" and will 549 thus perform RSVP processing of the E2E Path message. 551 As with [LSP-HIER], the IP TTL vs. RSVP TTL check MUST NOT be made. 552 The Deaggregator is informed that this check is not to be made 553 because of the presence of the IF_ID RSVP HOP object. 555 The Deaggregator MAY support the option to perform the following 556 checks (defined in [LSP-HIER]) by the receiver Y of the IF_ID 557 RSVP_HOP object: 559 1. Make sure that the data interface identified in the IF_ID 560 RSVP_HOP object actually terminates on Y. 561 2. Find the "other end" of the above data interface, say X. 562 Make sure that the PHOP in the IF_ID RSVP_HOP object is a 563 control channel address that belongs to the same node as X. 565 The information necessary to perform these checks may not always be 566 available to the Deaggregator. Hence, the Deaggregator MUST support 567 operations in such environments where the checks cannot be made. 569 The Deaggregator MUST forward the E2E Path downstream towards the 570 receiver. In doing so, the Deaggregator sets the destination address 571 in the IP header of the E2E Path message to the IP address found in 572 the destination address field of the Session object. The Deaggregator 573 also sets the Router Alert. 575 An E2E PathErr sent by the Deaggregator in response to the E2E Path 576 message (which contains an IF_ID RSVP_HOP object) SHOULD contain an 577 IF_ID RSVP_HOP object. 579 4.5. Handling of E2E Resv Message by Deaggregator 581 As per regular RSVP operations, after receipt of the E2E Path, the 582 receiver generates an E2E Resv message which travels upstream hop-by- 583 hop towards the sender. 585 On receipt of the E2E Resv, the Deaggregator MUST follow traditional 586 RSVP procedures on receipt of the E2E Resv message. This includes 587 performing admission control for the segment downstream of the 588 Deaggregator and forwarding the E2E Resv message to the PHOP signaled 589 earlier in the E2E Path message and which identifies the Aggregator. 590 Since the E2E Resv message is directly addressed to the Aggregator 592 RSVP Aggregation over MPLS TE tunnels September 2006 594 and does not carry the Router Alert option (as per traditional RSVP 595 Resv procedures), the E2E Resv message is hidden from the routers 596 between the Deaggregator and the Aggregator which, therefore, handle 597 the E2E Resv message as a regular IP packet. 599 If the Aggregator and Deaggregator are also acting as IPsec Security 600 Gateways, the Deaggregator MUST send the E2E Resv message into the 601 relevant IPsec tunnel terminating on the Aggregator. 603 4.6. Handling of E2E Resv Message by the Aggregator 605 The Aggregator is responsible for ensuring that there is sufficient 606 bandwidth available and reserved over the appropriate TE tunnel to 607 the Deaggregator for the E2E reservation. 609 On receipt of the E2E Resv message, the Aggregator MUST first perform 610 the final mapping onto the final TE tunnel (if the previous mapping 611 was only a tentative one). 613 If the tunnel did not change during the final mapping, the Aggregator 614 continues processing of the E2E Resv as described in the four 615 following paragraphs. 617 The aggregator calculates the size of the resource request using 618 traditional RSVP procedures. That is, it follows the procedures in 619 [RSVP] to determine the resource requirements from the Sender Tspec 620 and the Flowspec contained in the Resv. Then it compares the resource 621 request with the available resources of the selected TE tunnel. 623 If sufficient bandwidth is available on the final TE tunnel, the 624 Aggregator MUST update its internal understanding of how much of the 625 TE Tunnel is in use and MUST forward the E2E Resv messages to the 626 corresponding PHOP. 628 As noted in [RSVP-AGG], a range of policies MAY be applied to the re- 629 sizing of the aggregate reservation (in this case, the TE tunnel.) 630 For example, the policy may be that the reserved bandwidth of the 631 tunnel can only be changed by configuration. More dynamic policies 632 are also possible, whereby the aggregator may attempt to increase the 633 reserved bandwidth of the tunnel in response to the amount of 634 allocated bandwidth that has been used by E2E reservations. 635 Furthermore, to avoid the delay associated with the increase of the 636 Tunnel size, the Aggregator may attempt to anticipate the increases 637 in demand and adjust the TE tunnel size ahead of actual needs by E2E 638 reservations. In order to reduce disruptions, the aggregator SHOULD 639 use "make-before-break" procedures as described in [RSVP-TE] to alter 640 the TE tunnel bandwidth. 642 RSVP Aggregation over MPLS TE tunnels September 2006 644 If sufficient bandwidth is not available on the final TE Tunnel, the 645 Aggregator MUST follow the normal RSVP procedure for a reservation 646 being placed with insufficient bandwidth to support this reservation. 647 That is, the reservation is not installed and a ResvError is sent 648 back towards the receiver. 650 If the tunnel did change during the final mapping, the Aggregator 651 MUST first resend to the Deaggregator an E2E Path message with the 652 IF_ID RSVP_HOP data interface identification identifying the final TE 653 Tunnel. If needed, the ADSPEC information in this E2E Path message 654 SHOULD be updated. Then the Aggregator MUST 655 - either drop the E2E Resv message 656 - or proceed with the processing of the E2E Resv in the same 657 manner as in the case where the tunnel did not change and 658 described above. 659 In the former case, admission control over the final TE tunnel (and 660 forwarding of E2E Resv message upstream towards the sender) would 661 only occur when the Aggregator receives the subsequent E2E Resv 662 message (that will be sent by the Deaggregator in response to the 663 resent E2E Path). In the latter case, admission control over the 664 final Tunnel is carried out by Aggregator right away and if 665 successful the E2E Resv message is generated upstream towards the 666 sender. 668 On receipt of an E2E ResvConf from the Aggregator, the Deaggregator 669 MUST forward the E2E ResvConf downstream towards the receiver. In 670 doing so, the Deaggregator sets the destination address in the IP 671 header of the E2E ResvConf message to the IP address found in the 672 RESV_CONFIRM object of the corresponding Resv. The Deaggregator also 673 sets the Router Alert. 675 4.7. Forwarding of E2E traffic by Aggregator 677 When the Aggregator receives a data packet belonging to an E2E 678 reservations currently mapped over a given TE tunnel, the Aggregator 679 MUST encapsulate the packet into that TE tunnel. 681 If the Aggregator and Deaggregator are also acting as IPsec Security 682 Gateways, the Aggregator MUST also encapsulate the data packet into 683 the relevant IPsec tunnel terminating on the Deaggregator before 684 transmission into the MPLS TE tunnel. 686 4.8. Removal of E2E reservations 688 E2E reservations are removed in the usual way via PathTear, ResvTear, 689 timeout, or as the result of an error condition. When a reservation 690 is removed, the Aggregator MUST update its local view of the 692 RSVP Aggregation over MPLS TE tunnels September 2006 694 resources available on the corresponding TE tunnel accordingly. 696 4.9. Removal of TE Tunnel 698 Should a TE Tunnel go away (presumably due to a configuration change, 699 route change, or policy event), the aggregator behaves much like a 700 conventional RSVP router in the face of a link failure. That is, it 701 may try to forward the Path messages onto another tunnel, if routing 702 and policy permit, or it may send Path_Error messages to the sender 703 if no suitable tunnel exists. In case the Path messages are forwarded 704 onto another tunnel which terminates on a different Deaggregator, or 705 the reservation is torn-down via Path Error messages, the reservation 706 state established on the router acting as the Deaggregator before the 707 TE tunnel went away, will time out since it will no longer be 708 refreshed. 710 RSVP Aggregation over MPLS TE tunnels September 2006 712 4.10. Example Signaling Flow 714 Aggregator Deaggregator 716 (*) 717 RSVP-TE Path 718 =========================> 720 RSVP-TE Resv 721 <========================= 722 (**) 724 E2E Path 725 --------------> 726 (1) 727 E2E Path 728 -------------------------------> 729 (2) 730 E2E Path 731 -----------> 733 E2E Resv 734 <----------- 735 (3) 736 E2E Resv 737 <----------------------------- 738 (4) 739 E2E Resv 740 <------------- 742 (*) Aggregator is triggered to pre-establish the TE Tunnel(s) 744 (**) TE Tunnel(s) are pre-established 746 (1) Aggregator tentatively selects the TE tunnel and forwards 747 E2E path to Deaggregator 749 (2) Deaggregator forwards the E2E Path towards receiver 751 (3) Deaggregator forwards the E2E Resv to the Aggregator 753 (4) Aggregator selects final TE tunnel, checks that there is 754 sufficient bandwidth on TE tunnel and forwards E2E Resv to 756 RSVP Aggregation over MPLS TE tunnels September 2006 758 PHOP. If final tunnel is different from tunnel tentatively 759 selected, the Aggregator re-sends an E2E Path. 761 5. IPv4 and IPv6 Applicability 763 The procedures defined in this document are applicable to all the 764 following cases: 766 (1) Aggregation of E2E IPv4 RSVP reservations over IPv4 TE 767 Tunnels 768 (2) Aggregation of E2E IPv6 RSVP reservations over IPv6 TE 769 Tunnels 770 (3) Aggregation of E2E IPv6 RSVP reservations over IPv4 TE 771 tunnels, provided a mechanism such as [6PE] is used by the 772 Aggregator and Deaggregator for routing of IPv6 traffic over 773 an IPv4 MPLS core, 774 (4) Aggregation of E2E IPv4 RSVP reservations over IPv6 TE 775 tunnels, provided a mechanism is used by the Aggregator and 776 Deaggregator for routing IPv4 traffic over IPv6 MPLS. 778 6. E2E Reservations Applicability 780 The procedures defined in this document are applicable to many types 781 of E2E RSVP reservations including the following cases: 782 (1) the E2E RSVP reservation is a per-flow reservation where the 783 flow is characterized by the usual 5-tuple 784 (2) the E2E reservation is an aggregate reservation for multiple 785 flows as described in [RSVP-AGG] or [RSVP-GEN-AGG] where the 786 set of flows is characterized by the 788 (3) the E2E reservation is a reservation for an IPsec protected 789 flow. For example, where the flow is characterized by the 790 as described in 791 [RSVP-IPSEC]. 793 7. Example Deployment Scenarios 795 7.1. Voice and Video Reservations Scenario 797 An example application of the procedures specified in this document 798 is admission control of voice and video in environments with very 799 high numbers of hosts. In the example illustrated below, hosts 800 generate end-to-end per-flow reservations for each of their video 801 streams associated with a video-conference, each of their audio 802 streams associated with a video-conference and each of their voice 803 calls. These reservations are aggregated over MPLS DS-TE tunnels over 805 RSVP Aggregation over MPLS TE tunnels September 2006 807 the packet core. The mapping policy defined by the user maybe that 808 all the reservations for audio and voice streams are mapped onto DS- 809 TE tunnels of Class-Type 1 while reservations for video streams are 810 mapped onto DS-TE tunnels of Class-Type 0. 812 ------ ------ 813 | H |# ------- -------- #| H | 814 | |\#| | ----- | |#/| | 815 -----| \| Agg | | T | | Deag |/ ------ 816 | |==========================| | 817 ------ /| |::::::::::| |:::::::::::| |\ ------ 818 | H |/#| | ----- | |#\| H | 819 | |# ------- -------- #| | 820 ------ ------ 822 H = Host 823 Agg = Aggregator (TE Tunnel Head-end) 824 Deagg = Deaggregator (TE Tunnel Tail-end) 825 T = Transit LSR 827 / = E2E RSVP reservation for a Voice flow 828 # = E2E RSVP reservation for a Video flow 829 == = DS-TE Tunnel from Class-Type 1 830 :: = DS-TE Tunnel from Class-Type 0 832 7.2. PSTN/3G Voice Trunking Scenario 834 An example application of the procedures specified in this document 835 is voice call admission control in large scale telephony trunking 836 environments. A Trunk VoIP Gateway may generate one aggregate RSVP 837 reservation for all the calls in place towards another given remote 838 Trunk VoIP Gateway (with resizing of this aggregate reservation in a 839 step function depending on current number of calls). In turn, these 840 reservations may be aggregated over MPLS TE tunnels over the packet 841 core so that tunnel Head-ends act as Aggregators and perform 842 admission control of Trunk Gateway reservations into MPLS TE Tunnels. 843 The MPLS TE tunnels may be protected by MPLS Fast Reroute. 844 This scenario is illustrated below: 846 RSVP Aggregation over MPLS TE tunnels September 2006 848 ------ ------ 849 | GW |\ ------- -------- /| GW | 850 | |\\| | ----- | |//| | 851 -----| \| Agg | | T | | Deag |/ ------ 852 | |==========================| | 853 ------ /| | | | | |\ ------ 854 | GW |//| | ----- | |\\| GW | 855 | |/ ------- -------- \| | 856 ------ ------ 858 GW = VoIP Gateway 859 Agg = Aggregator (TE Tunnel Head-end) 860 Deagg = Deaggregator (TE Tunnel Tail-end) 861 T = Transit LSR 863 / = Aggregate Gateway to Gateway E2E RSVP reservation 864 == = TE Tunnel 866 8. Security Considerations 868 In the environments concerned by this document, RSVP messages are 869 used to control resource reservations for E2E flows outside the MPLS 870 region as well as to control resource reservations for MPLS TE 871 Tunnels inside the MPLS region. To ensure the integrity of the 872 associated reservation and admission control mechanisms, the 873 mechanisms defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] can be used. 874 Those protect RSVP messages integrity hop-by-hop and provide node 875 authentication, thereby protecting against corruption and spoofing of 876 RSVP messages. These hop-by-hop integrity mechanisms can naturally be 877 used to protect the RSVP messages used for E2E reservations outside 878 the MPLS region, to protect RSVP messages used for MPLS TE Tunnels 879 inside the MPLS region, or for both. These hop-by-hop RSVP integrity 880 mechanisms can also be used to protect RSVP messages used for E2E 881 reservations when those transit through the MPLS region. This is 882 because the Aggregator and Deaggregator behave as RSVP neighbors from 883 the viewpoint of the E2E flows (even if they are not necessarily IP 884 neighbors nor RSVP-TE neighbors). It that case, the Aggregator and 885 Deaggregator need to use a pre-shared secret. 887 As discussed in section 6 of [RSVP-TE], filtering of traffic 888 associated with an MPLS TE Tunnel can only be done on the basis of an 889 MPLS label, instead of the 5-tuple of conventional RSVP reservation 890 as per [RSVP]. Thus, as explained in [RSVP-TE], an administrator may 891 wish to limit the domain over which TE Tunnels (which are used for 892 aggregation of RSVP E2E reservations as per this specification) can 894 RSVP Aggregation over MPLS TE tunnels September 2006 896 be established. See section 6 of [RSVP-TE] for a description of how 897 filtering of RSVP messages associated with MPLS TE Tunnels can be 898 deployed to that end. 900 This document is based in part on [RSVP-AGG] which specifies 901 aggregation of RSVP reservations. Section 5 of [RSVP-AGG] raises the 902 point that because many E2E flows may share an aggregate reservation, 903 if the security of an aggregate reservation is compromised, there is 904 a multiplying effect in the sense that it can in turn compromise the 905 security of many E2E reservations whose quality of service depends on 906 the aggregate reservation. This concern applies also to RSVP 907 Aggregation over TE Tunnels as specified in the present document. 908 However, the integrity of MPLS TE Tunnels operation can be protected 909 using the mechanisms discussed in the previous paragraphs. Also, 910 while [RSVP-AGG] specifies RSVP Aggregation over dynamically 911 established aggregate reservations, the present document restricts 912 itself to RSVP Aggregation over pre-established TE Tunnels. This 913 further reduces the security risks. 915 In the case where the Aggregators dynamically resize the TE tunnels 916 based on the current level of reservation, there are risks that the 917 TE tunnels used for RSVP aggregation hog resources in the core which 918 could prevent other TE Tunnels from being established. There are also 919 potential risks that such resizing results in significant computation 920 and signaling as well as churn on tunnel paths. Such risks can be 921 mitigated by configuration options allowing control of TE tunnel 922 dynamic resizing (maximum TE tunnel size, maximum resizing 923 frequency, ...) and/or possibly by the use of TE preemption. 925 Section 5 of [RSVP-AGG] also discusses a security issue specific to 926 RSVP aggregation related to the necessary modification of the IP 927 Protocol number in RSVP E2E Path messages that traverses the 928 aggregation region. This security issue does not apply to the present 929 document since aggregation of RSVP reservation over TE Tunnels does 930 not use this approach of changing the protocol number in RSVP 931 messages. 933 Section 7 of [LSP-HIER] discusses security considerations stemming 934 from the fact that the implicit assumption of a binding between data 935 interface and the interface over which a control message is sent is 936 no longer valid. These security considerations are equally applicable 937 to the present document. 939 If the Aggregator and Deaggregator are also acting as IPsec Security 940 Gateways, the Security Considerations of [SEC-ARCH] apply. 942 9. IANA Considerations 944 RSVP Aggregation over MPLS TE tunnels September 2006 946 This document has no actions for IANA. 948 10. Acknowledgments 950 This document builds on the [RSVP-AGG], [RSVP-TUN] and [LSP-HIER] 951 specifications. Also, we would like to thank Tom Phelan, John Drake, 952 Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol 953 Iturralde and James Gibson for their input into this document. 955 11. Normative References 957 [BCP 78], S. Bradner, IETF Rights in Contributions, RFC3978, BCP 78, 958 March 2005. 960 [BCP 79] S. Bradner, Intellectual Property Rights in IETF Technology, 961 RFC 3668, BCP 79, February 2004. 963 [CONTROLLED] Wroclawski, Specification of the Controlled-Load Network 964 Element Service, RFC2211 966 [DIFFSERV] Blake et al., An Architecture for Differentiated Services, 967 RFC 2475 969 [DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of 970 Diff-Serv-aware MPLS Traffic Engineering, RFC 4124, June 2005. 972 [GUARANTEED] Shenker et al., Specification of Guaranteed Quality of 973 Service, RFC2212 975 [INT-DIFF] A Framework for Integrated Services Operation over 976 Diffserv Networks, RFC 2998, November 2000. 978 [INT-SERV] Braden, R., Clark, D. and S. Shenker, Integrated Services 979 in the Internet Architecture: an Overview, RFC 1633, June 1994. 981 [KEYWORDS] S. Bradner, Key words for use in RFCs to Indicate 982 Requirement Levels, RFC2119, March 1997. 984 [LSP-HIER] Kompella et al, Label Switched Paths (LSP) Hierarchy with 985 Generalized Multi-Protocol Label Switching (GMPLS) Traffic 986 Engineering (TE), RFC 4206, October 2005 988 [MPLS-TE] Awduche et al., "Requirements for Traffic Engineering over 989 MPLS", RFC 2702, September 1999. 991 [RSVP] Braden et al., Resource ReSerVation Protocol (RSVP) -- Version 992 1 Functional Specification, RFC 2205, September 1997. 994 RSVP Aggregation over MPLS TE tunnels September 2006 996 [RSVP-AGG] Baker et al, Aggregation of RSVP for IPv4 and IPv6 997 Reservations, RFC 3175, September 2001. 999 [RSVP-CRYPTO1] Baker at al, RSVP Cryptographic Authentication, RFC 1000 2747, January 2000. 1002 [RSVP-CRYPTO2] Braden and Zhang, RSVP Cryptographic Authentication - 1003 Updated Message Type Value, RFC 3097, April 2001. 1005 [RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels, 1006 RFC 3209, December 2001. 1008 [SEC-ARCH] Kent and Seo, Security Architecture for the Internet 1009 Protocol, RFC 4301, December 2005 1011 12. Informative References 1013 [6PE] De Clercq et al, Connecting IPv6 Islands over IPv4 MPLS using 1014 IPv6 Provider Edge Routers (6PE), work in progress 1016 [AUTOMESH] Vasseur and Leroux, Routing extensions for discovery of 1017 Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering 1018 (TE) mesh membership, draft-vasseur-ccamp-automesh-00.txt, work in 1019 progress. 1021 [DIFF-MPLS] Le Faucheur et al, MPLS Support of Diff-Serv, RFC3270, 1022 May 2002. 1024 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 1025 aware MPLS Traffic Engineering, RFC3564, July 2003. 1027 [L-RSVP] Manner et al., Localized RSVP, draft-manner-lrsvp-04.txt, 1028 work in progress. 1030 [RSVP-APPID] Bernet et al., Identity Representation for RSVP, RFC 1031 3182. 1033 [RSVP-GEN-AGG] Le Faucheur et al, Generic Aggregate RSVP Reservations, 1034 draft-ietf-tsvwg-rsvp-ipsec, work in progress 1036 [RSVP-IPSEC] Berger et al, RSVP Extensions for IPSEC Data Flows, RFC 1037 2207 1039 [RSVP-PREEMP] Herzog, Signaled Preemption Priority Policy Element, 1040 RFC 3181 1042 RSVP Aggregation over MPLS TE tunnels September 2006 1044 [RSVP-PROXY] Gai et al., RSVP Proxy, draft-ietf-rsvp-proxy-03.txt 1045 (expired), work in progress. 1047 [RSVP-TUN] Terzis et al., RSVP Operation Over IP Tunnels, RFC 2746, 1048 January 2000 1050 [SIP-RSVP] Camarillo, Integration of Resource Management and Session 1051 Initiation Protocol (SIP), RFC 3312 1053 13. Editor's Address: 1055 Francois Le Faucheur 1056 Cisco Systems, Inc. 1057 Village d'Entreprise Green Side - Batiment T3 1058 400, Avenue de Roumanille 1059 06410 Biot Sophia-Antipolis 1060 France 1061 Email: flefauch@cisco.com 1063 IPR Statements 1065 The IETF takes no position regarding the validity or scope of any 1066 Intellectual Property Rights or other rights that might be claimed to 1067 pertain to the implementation or use of the technology described in 1068 this document or the extent to which any license under such rights 1069 might or might not be available; nor does it represent that it has 1070 made any independent effort to identify any such rights. Information 1071 on the procedures with respect to rights in RFC documents can be 1072 found in BCP 78 and BCP 79. 1074 Copies of IPR disclosures made to the IETF Secretariat and any 1075 assurances of licenses to be made available, or the result of an 1076 attempt made to obtain a general license or permission for the use of 1077 such proprietary rights by implementers or users of this 1078 specification can be obtained from the IETF on-line IPR repository at 1079 http://www.ietf.org/ipr. 1081 The IETF invites any interested party to bring to its attention any 1082 copyrights, patents or patent applications, or other proprietary 1083 rights that may cover technology that may be required to implement 1084 this standard. 1085 Please address the information to the IETF at ietf-ipr@ietf.org. 1087 Disclaimer of Validity 1089 RSVP Aggregation over MPLS TE tunnels September 2006 1091 This document and the information contained herein are provided on an 1092 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1093 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1094 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1095 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1096 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1097 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1099 Copyright Notice 1101 Copyright (C) The Internet Society (2006). This document is subject 1102 to the rights, licenses and restrictions contained in BCP 78, and 1103 except as set forth therein, the authors retain all their rights. 1105 Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator 1107 A number of approaches ([RSVP-PROXY], [L-RSVP]) have been, or are 1108 being, discussed in the IETF in order to allow a network node to 1109 behave as an RSVP proxy which: 1110 - originates the Resv Message (in response to the Path message) on 1111 behalf of the destination node 1112 - originates the Path message (in response to some trigger) on 1113 behalf of the source node. 1115 We observe that such approaches may optionally be used in conjunction 1116 with the aggregation of RSVP reservations over MPLS TE tunnels as 1117 specified in this document. In particular, we consider the case where 1118 the RSVP Aggregator/Deaggregator also behaves as the RSVP proxy. 1120 The information is this Appendix is purely informational and 1121 illustrative. 1123 As discussed in [RSVP-PROXY]: 1125 "The proxy functionality does not imply merely generating a single 1126 Resv message. Proxying the Resv involves installing state in the node 1127 doing the proxy i.e. the proxying node should act as if it had 1128 received a Resv from the true endpoint. This involves reserving 1129 resources (if required), sending periodic refreshes of the Resv 1130 message and tearing down the reservation if the Path is torn down." 1132 Hence, when behaving as the RSVP Proxy, the RSVP Aggregator may 1133 effectively perform resource reservation over the MPLS TE Tunnel (and 1134 hence over the whole segment between the RSVP Aggregator and the RSVP 1135 Deaggregator) even if the RSVP signaling only takes place upstream of 1136 the MPLS TE Tunnel (i.e. between the host and the RSVP aggregator). 1138 RSVP Aggregation over MPLS TE tunnels September 2006 1140 Also, the RSVP Proxy can generate the Path message on behalf of the 1141 remote source host in order to achieve reservation in the return 1142 direction (i.e. from RSVP aggregator/Deaggregator to host). 1144 The resulting Signaling Flow is illustrated below, covering 1145 reservations for both directions: 1147 |----| |--------------| |------| |--------------| |----| 1148 | | | Aggregator/ | | MPLS | | Aggregator/ | | | 1149 |Host| | Deaggregator/| | cloud| | Deaggregator/| |Host| 1150 | | | RSVP Proxy | | | | RSVP Proxy | | | 1151 |----| |--------------| |------| |--------------| |----| 1153 ==========TE Tunnel==========> 1154 <========= TE Tunnel========== 1156 Path Path 1157 ------------> (1)-\ /-(i) <---------- 1158 Resv | | Resv 1159 <------------ (2)-/ \-(ii) ------------> 1160 Path Path 1161 <------------ (3) (iii) ------------> 1162 Resv Resv 1163 ------------> <------------ 1165 (1)(i) : Aggregator/Deaggregator/Proxy receives Path message, 1166 selects the TE tunnel, performs admission control over the TE Tunnel. 1167 (1) and (i) happens independently of each other. 1169 (2)(ii) : Aggregator/Deaggregator/Proxy generates the Resv message 1170 towards Host. (2) is triggered by (1) and (ii) is triggered by (i). 1171 Before generating this Resv message, the Aggregator/Proxy performs 1172 admission control of the corresponding reservation over the TE tunnel 1173 that will eventually carry the corresponding traffic. 1175 (3)(iii) : Aggregator/Deaggregator/Proxy generates the Path message 1176 towards Host for reservation in return direction. The actual trigger 1177 for this depends on the actual RSVP proxy solution. As an example, 1178 (3) and (iii) may simply be triggered respectively by (1) and (i). 1180 Note that the details of the signaling flow may vary slightly 1181 depending on the actual approach used for RSVP Proxy. For example, if 1182 the [L-RSVP] approach was used instead of [RSVP-PROXY], an additional 1183 PathRequest message would be needed from host to 1184 Aggregator/Deaggregator/Proxy in order to trigger the generation of 1185 the Path message for return direction. 1187 RSVP Aggregation over MPLS TE tunnels September 2006 1189 But regardless of the details of the call flow and of the actual RSVP 1190 Proxy approach, RSVP proxy may optionally be deployed in combination 1191 with RSVP Aggregation over MPLS TE Tunnels, in such a way which 1192 ensures (when used on both the Host-Aggregator and Deaggregator-Host 1193 sides, and when both end systems support RSVP) that: 1195 (i) admission control and resource reservation is performed on 1196 every segment of the end-to-end path (i.e. between source 1197 host and Aggregator, over the TE Tunnel between the 1198 Aggregator and Deaggregator which itself has been subject 1199 to admission control by MPLS TE, between Deaggregator and 1200 destination host) 1202 (ii) this is achieved in both direction 1204 (iii) RSVP signaling is localized between hosts and 1205 Aggregator/Deaggregator, which may result in significant 1206 reduction in reservation establishment delays (and in turn 1207 in post dial delay in the case where these reservations 1208 are pre-conditions for voice call establishment), 1209 particularly in the case where the MPLS TE tunnels span 1210 long distances with high propagation delays. 1212 Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels for 1213 VoIP Call Admission Control (CAC) 1215 This Appendix presents an example scenario where the mechanisms 1216 described in this document are used, in combination with other 1217 mechanisms specified by the IETF, to achieve Call Admission Control 1218 (CAC) of Voice over IP (VoIP) traffic over the packet core. 1220 The information is that Appendix is purely informational and 1221 illustrative. 1223 Consider the scenario depicted in Figure A1. VoIP Gateways GW1 and 1224 GW2 are both signaling and media gateways. They are connected to an 1225 MPLS network via edge routers PE1 and PE2, respectively. In each 1226 direction, a DSTE tunnel passes from the head-end edge router, 1227 through core network P routers, to the tail-end edge router. GW1 and 1228 GW2 are RSVP-enabled. The RSVP reservations established by GW1 and 1229 GW2 are aggregated by PE1 and PE2 over the DS-TE tunnels. For 1230 reservations going from GW1 to GW2, PE1 serves as the 1231 aggregator/head-end and PE2 serves as the de-aggregator/tail-end. For 1232 reservations going from GW2 to GW2, PE2 serves as the 1233 aggregator/head-end and PE1 serves as the de-aggregator/tail-end. 1235 RSVP Aggregation over MPLS TE tunnels September 2006 1237 To determine whether there is sufficient bandwidth in the MPLS core 1238 to complete a connection, the originating and destination GWs each 1239 send for each connection a Resource Reservation Protocol (RSVP) 1240 bandwidth request to the network PE router to which it is connected. 1241 As part of its Aggregator role, the PE router effectively performs 1242 admission control of the bandwidth request generated by the GW onto 1243 the resources of the corresponding DS-TE tunnel. 1245 In this example, in addition to behaving as Aggregator/Deaggregator, 1246 PE1 and PE2 behave as RSVP proxy. So when a PE receives a Path 1247 message from a GW, it does not propagate the Path message any further. 1248 Rather, the PE performs admission control of the bandwidth signaled 1249 in the Path message over the DSTE tunnel towards the destination. 1250 Assuming there is enough bandwidth available on that tunnel, the PE 1251 adjusts its book-keeping of remaining available bandwidth on the 1252 tunnel and generates a Resv message back towards the GW to confirm 1253 resources have been reserved over the DSTE tunnel. 1255 ,-. ,-. 1256 _.---' `---' `-+ 1257 ,-'' +------------+ : 1258 ( | | `. 1259 \ ,' CCA `. : 1260 \ ,' | | `. ; 1261 ;' +------------+ `._ 1262 ,'+ ; `. 1263 ,' -+ Application Layer' `. 1264 SIP,' `---+ | ; `.SIP 1265 ,' `------+---' `. 1266 ,' `. 1267 ,' `. 1268 ,' ,-. ,-. `. 1269 ,' ,--+ `--+--'- --'\ `._ 1270 +-`--+_____+------+ { +----+ +----+ `. +------+_____+----+ 1271 |GW1 | RSVP| |______| P |___| P |______| | RSVP|GW2 | 1272 | |-----| PE1 | { +----+ +----+ /+| PE2 |-----| | 1273 | | | |==========================>| | | | 1274 +-:--+ RTP | |<==========================| | RTP +-:--+ 1275 _|..__ +------+ { DSTE Tunnels ; +------+ __----|--. 1276 _,' \-| ./ -'._ / | 1277 | Access \ / +----+ \, |_ Access | 1278 | Network | \_ | P | | / Network | 1279 | / `| +----+ / | ' 1280 `--. ,.__,| | IP/MPLS Network / '---'- ----' 1281 '`' '' ' .._,,'`.__ _/ '---' | 1282 | '`''' | 1283 C1 C2 1285 Figure A1. Integration of SIP Resource Management, DSTE 1287 RSVP Aggregation over MPLS TE tunnels September 2006 1289 and RSVP Aggregation 1291 [SIP-RSVP] discusses how network quality of service can be made a 1292 precondition for establishment of sessions initiated by the Session 1293 Initiation Protocol (SIP). These preconditions require that the 1294 participant reserve network resources before continuing with the 1295 session. The reservation of network resources are performed through a 1296 signaling protocol such as RSVP. 1298 Our example environment relies of [SIP-RSVP] to synchronize RSVP 1299 bandwidth reservations with SIP. For example, the RSVP bandwidth 1300 requests may be integrated into the call setup flow as follows (See 1301 call setup flow diagram in Figure A2): 1303 - Caller C1 initiates a call by sending a SIP INVITE to VoIP 1304 gateway GW1, which passes the INVITE along to the call control 1305 agent (CCA). The INVITE message may contain a list of codecs 1306 that the calling phone can support. 1308 - VoIP gateway GW2, chooses a compatible codec from the list and 1309 responds with a SIP message 183 Session Progress. 1311 - When GW1 receives the SIP response message with the SDP, it 1312 determines how much bandwidth is required for the call. 1314 - GW1 sends an RSVP Path message to PE1, requesting bandwidth for 1315 the call. 1317 - GW2 also sends an RSVP Path message to PE2. 1319 - Assuming that the tunnel (from left to right) has sufficient 1320 bandwidth, PE1 responds to GW1 with a Resv message 1322 - Again assuming the tunnel (from right to left) has sufficient 1323 bandwidth, PE2 responds to GW2 with a Resv message 1325 - GW2 sends a SIP 200 OK message to GW1. 1327 - GW1 sends a SIP UPDATE message to GW2. 1329 - Upon receiving the UPDATE, GW2 sends the INVITE to the 1330 destination phone, which responds with SIP message 180 RINGING. 1332 - When (and if) the called party answers, the destination phone 1333 responds with another SIP 200 OK which completes the connection 1334 and tells the calling party that there is now reserved 1335 bandwidth in both directions so that conversation can begin. 1337 RSVP Aggregation over MPLS TE tunnels September 2006 1339 - RTP media streams in both directions pass through the DSTE 1340 tunnels as they traverse the MPLS network. 1342 RSVP Aggregation over MPLS TE tunnels September 2006 1344 IP-Phone/ IP-Phone/ 1345 TA-C1 GW1 PE1 CCA PE2 GW2 TA-C2 1346 | INVITE|(SDP1) | INVITE | INVITE | | | 1347 |---------->|-------|---------->|------------|------->| | 1348 | 100|TRYING | | | | | 1349 |<----------|-------|-----------| | | | 1350 | 183|(SDP2) | | | | | 1351 |<----------|-------|-----------|------------|--------| | 1352 | | PATH | | | PATH | | 1353 | |------>| | |<-------| | 1354 | | RESV | | | RESV | | 1355 | |<------| | |------->| | 1356 | | | UPDATE|(SDP3) | | | 1357 | |-------|-----------|------------|------->| | 1358 | | | 200 OK|(SDP4) | | | 1359 | |<------|-----------|------------|--------| INVITE | 1360 | | | | | |---------->| 1361 |180 RINGING| | 180|RINGING | |180 RINGING| 1362 |<----------|<------|-----------|------------|--------|<----------| 1363 | 200 OK | 200|OK | 200|OK | 200 OK | 1364 |<----------|<------|-----------|<-----------|--------|<----------| 1365 | | | | | | | 1366 | | | DSTE|TUNNEL | | | 1367 | RTP|MEDIA |-----------|------------| | | 1368 |===========|=======|===========|============|========|==========>| 1369 | | |-----------|------------| | | 1370 | | | | | | | 1371 | | |-----------|------------| | | 1372 |<==========|=======|===========|============|========|===========| 1373 | | |-----------|------------| | | 1374 DSTE TUNNEL 1376 Figure A2. VoIP QoS CAC using SIP with Preconditions 1378 Through the collaboration between SIP resource management, RSVP 1379 signaling, RSVP Aggregation and DS-TE as described above, we see 1380 that: 1381 a) the PE and GW collaborate to determine whether there is enough 1382 bandwidth on the tunnel between the calling and called GWs to 1383 accommodate the connection, 1384 b) the corresponding accept/reject decision is communicated to the 1385 GWs on a connection-by-connection basis, and 1386 c) the PE can optimize network resources by dynamically adjusting 1387 the bandwidth of each tunnel according to the load over that tunnel. 1388 For example, if a tunnel is operating near capacity, the network may 1389 dynamically adjust the tunnel size within a set of parameters. 1391 RSVP Aggregation over MPLS TE tunnels September 2006 1393 We note that admission Control of voice calls over the core network 1394 capacity is achieved in a hierarchical manner whereby: 1395 - DSTE tunnels are subject to Admission Control over the 1396 resources of the MPLS TE core 1397 - Voice calls are subject to CAC over the DSTE tunnel bandwidth 1398 This hierarchy is a key element in the scalability of this CAC 1399 solution for voice calls over an MPLS Core. 1401 It is also possible for the GWs to use aggregate RSVP reservations 1402 themselves instead of per-call RSVP reservations. For example, 1403 instead of setting one reservation for each call GW1 has in place 1404 towards GW2, GW1 may establish one (or a small number of) aggregate 1405 reservations as defined in [RSVP-AGG] which is used for all (or a 1406 subset of all) the calls towards GW2. This effectively provides an 1407 additional level of hierarchy whereby: 1408 - 1409 DSTE tunnels are subject to Admission Control over the 1410 resources of the MPLS TE core 1411 - Aggregate RSVP reservations (for the calls from one GW to 1412 another GW) are subject to Admission Control over the DSTE 1413 tunnels (as per the "RSVP Aggregation over TE Tunnels" 1414 procedures defined in this document) 1415 - Voice calls are subject to CAC by the GW over the aggregate 1416 reservation towards the appropriate destination GW. 1417 This pushes even further the scalability limits of this voice CAC 1418 architecture.