idnits 2.17.1 draft-ietf-tsvwg-rsvp-dste-03.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1083. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1068. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1074. ** 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 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2119]), 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 22 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 (June 2006) is 6524 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: 'RFC3668' is defined on line 959, but no explicit reference was found in the text == Unused Reference: 'BCP-78' is defined on line 962, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) ** Obsolete normative reference: RFC 3978 (ref. 'BCP-78') (Obsoleted by RFC 5378) ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. 'INT-SERV') ** 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 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 Internet Draft Francois Le Faucheur 2 Editor 3 Cisco Systems, Inc. 5 draft-ietf-tsvwg-rsvp-dste-03.txt 6 Expires: December 2006 June 2006 8 Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 RFC 3175 specifies aggregation of RSVP end-to-end reservations over 35 aggregate RSVP reservations. This document specifies aggregation of 36 RSVP end-to-end reservations over MPLS Traffic Engineering (TE) 37 tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) 38 Tunnels. This approach is based on RFC 3175 and simply modifies the 39 corresponding procedures for operations over MPLS TE tunnels instead 40 of aggregate RSVP reservations. This approach can be used to achieve 41 admission control of a very large number of flows in a scalable 42 manner since the devices in the core of the network are unaware of 43 the end-to-end RSVP reservations and are only aware of the MPLS TE 44 tunnels. 46 Copyright Notice 47 Copyright (C) The Internet Society (2006). 49 Specification of Requirements 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in [RFC2119]. 55 Table of Contents 57 1. Introduction...................................................2 58 2. Contributing Authors...........................................6 59 3. Definitions....................................................7 60 4. Operations of RSVP Aggregation over TE with pre-established 61 Tunnels...........................................................8 62 4.1. Reference Model...........................................9 63 4.2. Receipt of E2E Path message By the Aggregator............10 64 4.3. Handling of E2E Path message By Transit LSRs.............11 65 4.4. Receipt of E2E Path Message by Deaggregator..............11 66 4.5. Handling of E2E Resv Message by Deaggregator.............12 67 4.6. Handling of E2E Resv Message by the Aggregator...........13 68 4.7. Forwarding of E2E traffic by Aggregator..................14 69 4.8. Removal of E2E reservations..............................14 70 4.9. Removal of TE Tunnel.....................................15 71 4.10. Example Signaling Flow..................................16 72 5. IPv4 and IPv6 Applicability...................................17 73 6. E2E Reservations Applicability................................17 74 7. Example Deployment Scenarios..................................17 75 7.1. Voice and Video Reservations Scenario....................17 76 7.2. PSTN/3G Voice Trunking Scenario..........................18 77 8. Optional Use of RSVP Proxy on RSVP Aggregator.................19 78 9. Security Considerations.......................................21 79 10. IANA Considerations..........................................22 80 11. Acknowledgments..............................................22 81 12. Normative References.........................................22 82 13. Informative References.......................................23 83 14. Editor's Address:............................................24 84 Appendix A - Example Usage of RSVP Aggregation over DSTE Tunnels for 85 VoIP Call Admission Control (CAC)................................25 87 1. Introduction 88 The Integrated Services (Intserv) [INT-SERV] architecture provides a 89 means for the delivery of end-to-end Quality of Service (QoS) to 90 applications over heterogeneous networks. 92 [RSVP] defines the Resource reSerVation Protocol which can be used by 93 applications to request resources from the network. The network 94 responds by explicitely admitting or rejecting these RSVP requests. 95 Certain applications that have quantifiable resource requirements 96 express these requirements using Intserv parameters as defined in the 97 appropriate Intserv service specifications ([GUARANTEED], 98 [CONTROLLED]). 100 The Differentiated Services (DiffServ) architecture ([DIFFSERV]) was 101 then developed to support differentiated treatment of packets in very 102 large scale environments. In contrast to the per-flow orientation of 103 Intserv and RSVP, Diffserv networks classify packets into one of a 104 small number of aggregated flows or "classes", based on the Diffserv 105 codepoint (DSCP) in the packet IP header. At each Diffserv router, 106 packets are subjected to a "per-hop behavior" (PHB), which is invoked 107 by the DSCP. The primary benefit of Diffserv is its scalability. 108 Diffserv eliminates the need for per-flow state and per-flow 109 processing and therefore scales well to large networks. 111 However, DiffServ does not include any mechanism for communication 112 between applications and the network. Thus, as detailed in [INT-DIFF], 113 significant benefits can be achieved by using Intserv over Diffserv 114 including resource based admission control, policy based admission 115 control, assistance in traffic identification /classification and 116 traffic conditioning. As discussed in [INT-DIFF], Intserv can operate 117 over Diffserv in multiple ways. For example, the Diffserv region may 118 be statically provisioned or may be RSVP aware. When it is RSVP aware, 119 several mechanisms may be used to support dynamic provisioning and 120 topology aware admission control including aggregate RSVP 121 reservations, per flow RSVP or a bandwidth broker. The advantage of 122 using aggregate RSVP reservations is that it offers dynamic, 123 topology-aware admission control over the Diffserv region without 124 per-flow reservations and the associated level of RSVP signaling in 125 the Diffserv core. In turn, this allows dynamic, topology aware 126 admission control of flows requiring QoS reservations over the 127 Diffserv core even when the total number of such flows carried over 128 the Diffserv core is extremely large. 130 [RSVP-AGG] describes in detail how to perform such aggregation of end 131 to end RSVP reservations over aggregate RSVP reservations in a 132 Diffserv cloud. It establishes an architecture where multiple end-to- 133 end RSVP reservations sharing the same ingress router (Aggregator) 134 and the same egress router (Deaggregator) at the edges of an 135 "aggregation region", can be mapped onto a single aggregate 136 reservation within the aggregation region. This considerably reduces 137 the amount of reservation state that needs to be maintained by 138 routers within the aggregation region. Furthermore, traffic belonging 139 to aggregate reservations is classified in the data path purely using 140 Diffserv marking. 142 [MPLS-TE] describes how MPLS Traffic Engineering (TE) Tunnels can be 143 used to carry arbitrary aggregates of traffic for the purposes of 144 traffic engineering. [RSVP-TE] specifies how such MPLS TE Tunnels can 145 be established using RSVP-TE signaling. MPLS TE uses Constraint Based 146 Routing to compute the path for a TE tunnel. Then, Admission Control 147 is performed during the establishment of TE Tunnels to ensure they 148 are granted their requested resources. 150 [DSTE-REQ] presents the Service Providers requirements for support of 151 Diff-Serv-aware MPLS Traffic Engineering (DS-TE). With DS-TE, 152 separate DS-TE tunnels can be used to carry different Diffserv 153 classes of traffic and different resource constraints can be enforced 154 for these different classes. [DSTE-PROTO] specifies RSVP-TE signaling 155 extensions as well as OSPF and ISIS extensions for support of DS-TE. 157 In the rest of this document we will refer to both TE tunnels and DS- 158 TE tunnels simply as "TE tunnels". 160 TE tunnels have much in common with the aggregate RSVP reservations 161 used in [RSVP-AGG]: 162 - a TE tunnel is subject to Admission Control and thus is 163 effectively an aggregate bandwidth reservation 164 - In the data plane, packet scheduling relies exclusively on 165 Diff-Serv classification and PHBs 166 - Both TE tunnels and aggregate RSVP reservations are controlled 167 by "intelligent" devices on the edge of the "aggregation core" 168 (Head-end and Tail-end in the case of TE tunnels, Aggregator 169 and Deaggregator in the case of aggregate RSVP reservations 170 - Both TE tunnels and aggregate RSVP reservations are signaled 171 using the RSVP protocol (with some extensions defined in [RSVP- 172 TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE 173 tunnels). 175 This document provides a detailed specification for performing 176 aggregation of end-to-end RSVP reservations over MPLS TE tunnels 177 (which act as aggregate reservations in the core). This document 178 builds on the RSVP Aggregation procedures defined in [RSVP-AGG], and 179 only changes those where necessary to operate over TE tunnels. With 180 [RSVP-AGG], a lot of responsibilities (such as mapping end-to-end 181 reservations to Aggregate reservations and resizing the Aggregate 182 reservations) are assigned to the Deaggregator (which is the 183 equivalent of the Tunnel Tail-end) while with TE, the tunnels are 184 controlled by the Tunnel Head-end. Hence, the main change over the 185 RSVP Aggregations procedures defined in [RSVP-AGG] is to modify these 186 procedures to reassign responsibilities from the Deaggregator to the 187 Aggregator (i.e. the tunnel Head-end). 189 [LSP-HIER] defines how to aggregate MPLS TE Label Switched Paths 190 (LSPs) by creating a hierarchy of such LSPs. This involves nesting of 191 end-to-end LSPs into an aggregate LSP in the core (by using the label 192 stack construct). Since end-to-end TE LSPs are themselves signaled 193 with RSVP-TE and reserve resources at every hop, this can be looked 194 at as a form of aggregation of RSVP(-TE) reservations over MPLS TE 195 Tunnels. This document capitalizes on the similarities between 196 nesting of TE LSPs over TE tunnels and RSVP aggregation over TE 197 tunnels and reuses the procedures of [LSP-HIER] wherever possible. 199 This document also builds on the "RSVP over Tunnels" concepts of RFC 200 2746 [RSVP-TUN]. It differs from that specification in the following 201 ways 202 - Whereas RFC 2746 describes operation with IP tunnels, this 203 document describes operation over MPLS tunnels. One consequence 204 of this difference is the need to deal with penultimate hop 205 popping (PHP). 206 - MPLS-TE tunnels inherently reserve resources, whereas the 207 tunnels in RFC 2746 do not have resource reservations by 208 default. This leads to some simplifications in the current 209 document. 210 - There is exactly one reservation per MPLS-TE tunnel, whereas 211 RFC 2746 permits many reservations per tunnel. 212 - We have assumed in the current document that a given MPLS-TE 213 tunnel will carry reserved traffic and nothing but reserved 214 traffic, which negates the requirement of RFC 2746 to 215 distinguish reserved and non-reserved traffic traversing the 216 same tunnel by using distinct encapsulations. 217 - There may be several MPLS-TE tunnels that share common head and 218 tail end routers, with head-end policy determining which tunnel 219 is appropriate for a particular flow. This scenario does not 220 appear to be addressed in RFC 2746. 222 At the same time, this document does have many similarities with RFC 223 2746. MPLS-TE tunnels are "type 2 tunnels" in the nomenclature of RFC 224 2746: 225 " 226 The (logical) link may be able to promise that some overall 227 level of resources is available to carry traffic, but not to 228 allocate resources specifically to individual data flows. 229 " 231 Aggregation of end-to-end RSVP reservations over TE tunnels combines 232 the benefits of [RSVP-AGG] with the benefits of MPLS including the 233 following: 235 - applications can benefit from dynamic, topology-aware resource- 236 based admission control over any segment of the end to end path 237 including the core 238 - as per regular RSVP behavior, RSVP does not impose any burden 239 on routers where such admission control is not needed (for 240 example if the links upstream and downstream of the MPLS TE 241 core are vastly over-engineered compared to the core capacity, 242 admission control is not required on these over-engineered 243 links and RSVP need not be processed on the corresponding 244 router hops) 245 - the core scalability is not affected (relative to the 246 traditional MPLS TE deployment model) since the core remains 247 unaware of end-to-end RSVP reservations and only has to 248 maintain aggregate TE tunnels and since the datapath 249 classification and scheduling in the core relies purely on 250 Diffserv mechanism (or more precisely MPLS Diffserv mechanisms 251 as specified in [DIFF-MPLS]) 252 - the aggregate reservation (and thus the traffic from the 253 corresponding end to end reservations) can be network 254 engineered via the use of Constraint based routing (e.g. 255 affinity, optimization on different metrics) and when needed 256 can take advantage of resources on other paths than the 257 shortest path 258 - the aggregate reservations (and thus the traffic from the 259 corresponding end to end reservations) can be protected against 260 failure through the use of MPLS Fast Reroute 262 This document, like [RSVP-AGG], covers aggregation of unicast 263 sessions. Aggregation of multicast sessions is for further study. 265 2. Contributing Authors 267 This document was the collective work of several authors. The text 268 and content were contributed by the editor and the co-authors listed 269 below. (The contact information for the editor appears in the 270 Editor's Address section.) 272 Michael DiBiasio 273 Cisco Systems, Inc. 274 300 Beaver Brook Road 275 Boxborough, MA 01719 276 USA 277 Email: dibiasio@cisco.com 279 Bruce Davie 280 Cisco Systems, Inc. 282 300 Beaver Brook Road 283 Boxborough, MA 01719 284 USA 285 Email: bdavie@cisco.com 287 Christou Christou 288 Booz Allen Hamilton 289 8283 Greensboro Drive 290 McLean, VA 22102 291 USA 292 Email: christou_chris@bah.com 294 Michael Davenport 295 Booz Allen Hamilton 296 8283 Greensboro Drive 297 McLean, VA 22102 298 USA 299 Email: davenport_michael@bah.com 301 Jerry Ash 302 AT&T 303 200 Laurel Avenue 304 Middletown, NJ 07748, USA 305 USA 306 Email: gash@att.com 308 Bur Goode 309 AT&T 310 32 Old Orchard Drive 311 Weston, CT 06883 312 USA 313 Email: bgoode@att.com 315 3. Definitions 317 For readability, a number of definitions from [RSVP-AGG] as well as 318 definitions for commonly used MPLS TE terms are provided here: 320 Aggregator This is the process in (or associated with) the router 321 at the ingress edge of the aggregation region (with 322 respect to the end to end RSVP reservation) and 323 behaving in accordance with [RSVP-AGG]. In this 324 document, it is also the TE Tunnel Head-end. 326 Deaggregator This is the process in (or associated with) the router 327 at the egress edge of the aggregation region (with 328 respect to the end to end RSVP reservation) and 329 behaving in accordance with [RSVP-AGG]. In this 330 document, it is also the TE Tunnel Tail-end 332 E2E End to end 334 E2E reservation This is an RSVP reservation such that: 335 (i) corresponding Path messages are initiated 336 upstream of the Aggregator and terminated 337 downstream of the Deaggregator, and 338 (ii) corresponding Resv messages are initiated 339 downstream of the Deaggregator and 340 terminated upstream of the Aggregator, and 341 (iii) this RSVP reservation is to be aggregated 342 over an MPLS TE tunnel between the 343 Aggregator and Deaggregator. 344 An E2E RSVP reservation may be a per-flow 345 reservation. Alternatively, the E2E reservation 346 may itself be an aggregate reservation of various 347 types (e.g. Aggregate IP reservation, Aggregate 348 IPsec reservation). See section 5 and 6 for more 349 details on the types of E2E RSVP reservations. As 350 per regular RSVP operations, E2E RSVP reservations 351 are unidirectional. 353 Head-end 354 This is the Label Switch Router responsible for 355 establishing, maintaining and tearing down a given TE 356 tunnel. 358 Tail-end 359 This is the Label Switch Router responsible for 360 terminating a given TE tunnel 362 Transit LSR This is a Label Switch router that is on the path of a 363 given TE tunnel and is neither the Head-end nor the 364 Tail-end 366 4. Operations of RSVP Aggregation over TE with pre-established Tunnels 368 [RSVP-AGG] supports operations both in the case where aggregate RSVP 369 reservations are pre-established and in the case where Aggregators 370 and Deaggregators have to dynamically discover each other and 371 dynamically establish the necessary aggregate RSVP reservations. 373 Similarly, RSVP Aggregation over TE tunnels could operate both in the 374 case where the TE tunnels are pre-established and in the case where 375 the tunnels need to be dynamically established. 377 In this document we provide a detailed description of the procedures 378 in the case where TE tunnels are already established. These 379 procedures are based on those defined in [LSP-HIER]. The routing 380 aspects discussed in section 3 of [LSP-HIER] are not relevant here 381 because those aim at allowing the constraint based routing of end-to- 382 end TE LSPs to take into account the (aggregate) TE tunnels. In the 383 present document, the end-to-end RSVP reservations to be aggregated 384 over the TE tunnels rely on regular SPF routing. However, as already 385 mentioned in [LSP-HIER], we note that a TE Tunnel may be advertised 386 into ISIS or OSPF, to be used in normal SPF by nodes upstream of the 387 Aggregator. This would affect SPF routing and thus routing of end-to- 388 end RSVP reservations. The control of aggregation boundaries 389 discussed in section 6 of [LSP-HIER] is also not relevant here. This 390 uses information exchanged in GMPLS protocols to dynamically discover 391 the aggregation boundary. In this document, TE tunnels are pre- 392 established, so that the aggregation boundary can be easily inferred. 393 The signaling aspects discussed in section 6.2 of [LSP-HIER] apply to 394 the establishment/termination of the aggregate TE tunnels when this 395 is triggered by GMPLS mechanisms (e.g. as a result of an end-to-end 396 TE LSP establishment request received at the aggregation boundary) . 397 As this document assumes pre-established tunnels, those aspects are 398 not relevant here. The signaling aspects discussed in section 6.1 of 399 [LSP-HIER] relate to the establishment/maintenance of the end-to-end 400 TE LSPs over the aggregate TE tunnel. This document describes how to 401 use the same procedures as those specified in section 6.1 of [LSP- 402 HIER], but for the establishment of end-to-end RSVP reservations 403 (instead of end-to-end TE LSPs) over the TE tunnels. This is covered 404 further in section 4 of the present document. 406 Pre-establishment of the TE tunnels may be triggered by any 407 mechanisms including for example manual configuration or automatic 408 establishment of a TE tunnel mesh through dynamic discovery of TE 409 Mesh membership as allowed in [AUTOMESH]. 411 Procedures in the case of dynamically established TE tunnels are for 412 further studies. 414 4.1. Reference Model 416 I----I I----I 417 H--I R I\ I-----I I------I /I R I--H 418 H--I I\\I I I---I I I//I I--H 419 I----I \I He/ I I T I I Te/ I/ I----I 420 I Agg I=======================I Deag I 421 /I I I I I I\ 423 H--------//I I I---I I I\\--------H 424 H--------/ I-----I I------I \--------H 426 H = Host requesting end-to-end RSVP reservations 427 R = RSVP router 428 He/Agg = TE tunnel Head-end/Aggregator 429 Te/Deag = TE tunnel Tail-end/Deaggregator 430 T = Transit LSR 432 -- = E2E RSVP reservation 433 == = TE Tunnel 435 4.2. Receipt of E2E Path message By the Aggregator 437 The first event is the arrival of the E2E Path message at the 438 Aggregator. The Aggregator MUST follow traditional RSVP procedures 439 for processing of this E2E path message augmented with the extensions 440 documented in this section. 442 The Aggregator MUST first attempt to map the E2E reservation onto a 443 TE tunnel. This decision is made in accordance with routing 444 information as well as any local policy information that may be 445 available at the Aggregator. Examples of such policies appear in the 446 following paragraphs. Just for illustration purposes, among many 447 other criteria, such mapping policies might take into account the 448 Intserv service type, the Application Identity [RSVP-APPID] and/or 449 the signaled preemption [RSVP-PREEMP] of the E2E reservation (for 450 example, the aggregator may take into account the E2E reservations 451 RSVP preemption priority and the MPLS TE Tunnel set-up and/or hold 452 priorities when mapping the E2E reservation onto an MPLS TE tunnel). 454 There are situations where the Aggregator is able to make a final 455 mapping decision. That would be the case, for example, if there is a 456 single TE tunnel towards the destination and if the policy is to map 457 any E2E RSVP reservation onto TE Tunnels. 459 There are situations where the Aggregator is not able to make a final 460 determination. That would be the case, for example, if routing 461 identifies two DS-TE tunnels towards the destination, one belonging 462 to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to 463 map Intserv Guaranteed Services reservations to a Class-Type 1 tunnel 464 and Intserv Controlled Load reservations to a Class-Type 0 tunnel, 465 and if the E2E RSVP Path message advertises both Guaranteed Service 466 and Controlled Load. 468 Whether final or tentative, the Aggregator makes a mapping decision 469 and selects a TE tunnel. Before forwarding the E2E Path message 470 towards the receiver, the Aggregator SHOULD update the ADSPEC inside 471 the E2E Path message to reflect the impact of the MPLS TE cloud onto 472 the QoS achievable by the E2E flow. This update is a local matter and 473 may be based on configured information, on information available in 474 the MPLS TE topology database, on the current TE tunnel path, on 475 information collected via RSVP-TE signaling, or combinations of those. 477 The Aggregator MUST then forward the E2E Path message to the 478 Deaggregator (which is the tail-end of the selected TE tunnel). In 479 accordance with [LSP-HIER], the Aggregator MUST send the E2E Path 480 message with an IF_ID RSVP_HOP object instead of an RSVP_HOP object. 481 The data interface identification MUST identify the TE Tunnel. 483 To send the E2E Path message, the Aggregator MUST address it directly 484 to the Deaggregator by setting the destination address in the IP 485 Header of the E2E Path message to the Deaggregator address. The 486 Router Alert is not set in the E2E Path message. 488 Optionally, the Aggregator MAY also encapsulate the E2E Path message 489 in an IP tunnel or in the TE tunnel itself. 491 Regardless of the encapsulation method, the Router Alert is not set. 492 Thus, the E2E Path message will not be visible to routers along the 493 path from the Aggregator to the Deaggregator. Therefore, in contrast 494 to the procedures of [RSVP-AGG], the IP Protocol number need not be 495 modified to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating 496 "RSVP") by the Aggregator. 498 In some environments, the Aggregator and Deaggregator MAY also act as 499 IPsec Security Gateways in order to provide IPsec protection to E2E 500 traffic when it transits between the Aggregator and the Deaggregator. 501 In that case, to transmit the E2E Path message to the Deaggregator, 502 the Aggregator MUST send the E2E Path message into the relevant IPsec 503 tunnel terminating on the Deaggregator. 505 E2E PathTear and ResvConf messages MUST be forwarded by the 506 Aggregator to the Deaggregator exactly like Path messages. 508 4.3. Handling of E2E Path message By Transit LSRs 510 Since the E2E Path message is addressed directly to the Deaggregator 511 and does not have Router Alert set, it is hidden from all transit 512 LSRs. 514 4.4. Receipt of E2E Path Message by Deaggregator 515 On receipt of the E2E Path message addressed to it, the Deaggregator 516 will notice that the IP Protocol number is set to "RSVP" and will 517 thus perform RSVP processing of the E2E Path message. 519 As with [LSP-HIER], the IP TTL vs. RSVP TTL check MUST NOT be made. 520 The Deaggregator is informed that this check is not to be made 521 because of the presence of the IF_ID RSVP HOP object. 523 The Deaggregator MAY support the option to perform the following 524 checks (defined in [LSP-HIER]) by the receiver Y of the IF_ID 525 RSVP_HOP object: 527 1. Make sure that the data interface identified in the IF_ID 528 RSVP_HOP object actually terminates on Y. 529 2. Find the "other end" of the above data interface, say X. 530 Make sure that the PHOP in the IF_ID RSVP_HOP object is a 531 control channel address that belongs to the same node as X. 533 The information necessary to perform these checks may not always be 534 available to the Deaggregator. Hence, the Deaggregator MUST support 535 operations in such environments where the checks cannot be made. 537 The Deaggregator MUST forward the E2E Path downstream towards the 538 receiver. In doing so, the Deaggregator sets the destination address 539 in the IP header of the E2E Path message to the IP address found in 540 the destination address field of the Session object. The Deaggregator 541 also sets the Router Alert. 543 An E2E PathErr sent by the Deaggregator in response to the E2E Path 544 message (which contains an IF_ID RSVP_HOP object) SHOULD contain an 545 IF_ID RSVP_HOP object. 547 4.5. Handling of E2E Resv Message by Deaggregator 549 As per regular RSVP operations, after receipt of the E2E Path, the 550 receiver generates an E2E Resv message which travels upstream hop-by- 551 hop towards the sender. 553 On receipt of the E2E Resv, the Deaggregator MUST follow traditional 554 RSVP procedures on receipt of the E2E Resv message. This includes 555 performing admission control for the segment downstream of the 556 Deaggregator and forwarding the E2E Resv message to the PHOP signaled 557 earlier in the E2E Path message and which identifies the Aggregator. 558 Since the E2E Resv message is directly addressed to the Aggregator 559 and does not carry the Router Alert option (as per traditional RSVP 560 Resv procedures), the E2E Resv message is hidden from the routers 561 between the Deaggregator and the Aggregator which, therefore, handle 562 the E2E Resv message as a regular IP packet. 564 If the Aggregator and Deaggregator are also acting as IPsec Security 565 Gateways, the Deaggregator MUST send the E2E Resv message into the 566 relevant IPsec tunnel terminating on the Aggregator. 568 4.6. Handling of E2E Resv Message by the Aggregator 570 The Aggregator is responsible for ensuring that there is sufficient 571 bandwidth available and reserved over the appropriate TE tunnel to 572 the Deaggregator for the E2E reservation. 574 On receipt of the E2E Resv message, the Aggregator MUST first perform 575 the final mapping onto the final TE tunnel (if the previous mapping 576 was only a tentative one). 578 If the tunnel did not change during the final mapping, the Aggregator 579 continues processing of the E2E Resv as described in the four 580 following paragraphs. 582 The aggregator calculates the size of the resource request using 583 traditional RSVP procedures. That is, it follows the procedures in 584 [RSVP] to determine the resource requirements from the Sender Tspec 585 and the Flowspec contained in the Resv. Then it compares the resource 586 request with the available resources of the selected TE tunnel. 588 If sufficient bandwidth is available on the final TE tunnel, the 589 Aggregator MUST update its internal understanding of how much of the 590 TE Tunnel is in use and MUST forward the E2E Resv messages to the 591 corresponding PHOP. 593 As noted in [RSVP-AGG], a range of policies MAY be applied to the re- 594 sizing of the aggregate reservation (in this case, the TE tunnel.) 595 For example, the policy may be that the reserved bandwidth of the 596 tunnel can only be changed by configuration. More dynamic policies 597 are also possible, whereby the aggregator may attempt to increase the 598 reserved bandwidth of the tunnel in response to the amount of 599 allocated bandwidth that has been used by E2E reservations. 600 Furthermore, to avoid the delay associated with the increase of the 601 Tunnel size, the Aggregator may attempt to anticipate the increases 602 in demand and adjust the TE tunnel size ahead of actual needs by E2E 603 reservations. In order to reduce disruptions, the aggregator SHOULD 604 use "make-before-break" procedures as described in [RSVP-TE] to alter 605 the TE tunnel bandwidth". 607 If sufficient bandwidth is not available on the final TE Tunnel, the 608 Aggregator MUST follow the normal RSVP procedure for a reservation 609 being placed with insufficient bandwidth to support this reservation. 611 That is, the reservation is not installed and a ResvError is sent 612 back towards the receiver. 614 If the tunnel did change during the final mapping, the Aggregator 615 MUST first resend to the Deaggregator an E2E Path message with the 616 IF_ID RSVP_HOP data interface identification identifying the final TE 617 Tunnel. If needed, the ADSPEC information in this E2E Path message 618 SHOULD be updated. Then the Aggregator MUST 619 - either drop the E2E Resv message 620 - or proceed with the processing of the E2E Resv in the same 621 manner as in the case where the tunnel did not change and 622 described above. 623 In the former case, admission control over the final TE tunnel (and 624 forwarding of E2E Resv message upstream towards the sender) would 625 only occur when the Aggregator receives the subsequent E2E Resv 626 message (that will be sent by the Deaggregator in response to the 627 resent E2E Path). In the latter case, admission control over the 628 final Tunnel is carried out by Aggregator right away and if 629 successful the E2E Resv message is generated upstream towards the 630 sender. 632 On receipt of an E2E ResvConf from the Aggregator, the Deaggregator 633 MUST forward the E2E ResvConf downstream towards the receiver. In 634 doing so, the Deaggregator sets the destination address in the IP 635 header of the E2E ResvConf message to the IP address found in the 636 RESV_CONFIRM object of the corresponding Resv. The Deaggregator also 637 sets the Router Alert. 639 4.7. Forwarding of E2E traffic by Aggregator 641 When the Aggregator receives a data packet belonging to an E2E 642 reservations currently mapped over a given TE tunnel, the Aggregator 643 MUST encapsulate the packet into that TE tunnel. 645 If the Aggregator and Deaggregator are also acting as IPsec Security 646 Gateways, the Aggregator MUST also encapsulate the data packet into 647 the relevant IPsec tunnel terminating on the Deaggregator before 648 transmission into the MPLS TE tunnel. 650 4.8. Removal of E2E reservations 652 E2E reservations are removed in the usual way via PathTear, ResvTear, 653 timeout, or as the result of an error condition. When a reservation 654 is removed, the Aggregator MUST update its local view of the 655 resources available on the corresponding TE tunnel accordingly. 657 4.9. Removal of TE Tunnel 659 Should a TE Tunnel go away (presumably due to a configuration change, 660 route change, or policy event), the aggregator behaves much like a 661 conventional RSVP router in the face of a link failure. That is, it 662 may try to forward the Path messages onto another tunnel, if routing 663 and policy permit, or it may send Path_Error messages to the sender 664 if no suitable tunnel exists. In case the Path messages are forwarded 665 onto another tunnel which terminates on a different Deaggregator, or 666 the reservation is torn-down via Path Error messages, the reservation 667 state established on the router acting as the Deaggregator before the 668 TE tunnel went away, will time out since it will no longer be 669 refreshed. 671 4.10. Example Signaling Flow 673 Aggregator Deaggregator 675 (*) 676 RSVP-TE Path 677 =========================> 679 RSVP-TE Resv 680 <========================= 681 (**) 683 E2E Path 684 --------------> 685 (1) 686 E2E Path 687 -------------------------------> 688 (2) 689 E2E Path 690 -----------> 692 E2E Resv 693 <----------- 694 (3) 695 E2E Resv 696 <----------------------------- 697 (4) 698 E2E Resv 699 <------------- 701 (*) Aggregator is triggered to pre-establish the TE Tunnel(s) 703 (**) TE Tunnel(s) are pre-established 705 (1) Aggregator tentatively selects the TE tunnel and forwards 706 E2E path to Deaggregator 708 (2) Deaggregator forwards the E2E Path towards receiver 710 (3) Deaggregator forwards the E2E Resv to the Aggregator 712 (4) Aggregator selects final TE tunnel, checks that there is 713 sufficient bandwidth on TE tunnel and forwards E2E Resv to 714 PHOP. If final tunnel is different from tunnel tentatively 715 selected, the Aggregator re-sends an E2E Path. 717 5. IPv4 and IPv6 Applicability 719 The procedures defined in this document are applicable to all the 720 following cases: 722 (1) Aggregation of E2E IPv4 RSVP reservations over IPv4 TE 723 Tunnels 724 (2) Aggregation of E2E IPv6 RSVP reservations over IPv6 TE 725 Tunnels 726 (3) Aggregation of E2E IPv6 RSVP reservations over IPv4 TE 727 tunnels, provided a mechanism such as [6PE] is used by the 728 Aggregator and Deaggregator for routing of IPv6 traffic over 729 an IPv4 MPLS core, 730 (4) Aggregation of E2E IPv4 RSVP reservations over IPv6 TE 731 tunnels, provided a mechanism is used by the Aggregator and 732 Deaggregator for routing IPv4 traffic over IPv6 MPLS. 734 6. E2E Reservations Applicability 736 The procedures defined in this document are applicable to many types 737 of E2E RSVP reservations including the following cases: 738 (1) the E2E RSVP reservation is a per-flow reservation where the 739 flow is characterized by the usual 5-tuple 740 (2) the E2E reservation is an aggregate reservation for multiple 741 flows as described in [RSVP-AGG] or [RSVP-GEN-AGG] where the 742 set of flows is characterized by the 744 (3) the E2E reservation is a reservation for an IPsec protected 745 flow. For example, where the flow is characterized by the 746 as described in 747 [RSVP-IPSEC]. 749 7. Example Deployment Scenarios 751 7.1. Voice and Video Reservations Scenario 753 An example application of the procedures specified in this document 754 is admission control of voice and video in environments with very 755 high numbers of hosts. In the example illustrated below, hosts 756 generate end-to-end per-flow reservations for each of their video 757 streams associated with a video-conference, each of their audio 758 streams associated with a video-conference and each of their voice 759 calls. These reservations are aggregated over MPLS DS-TE tunnels over 760 the packet core. The mapping policy defined by the user maybe that 761 all the reservations for audio and voice streams are mapped onto DS- 762 TE tunnels of Class-Type 1 while reservations for video streams are 763 mapped onto DS-TE tunnels of Class-Type 0. 765 ------ ------ 766 I H I# ------- -------- #I H I 767 I I\#I I ----- I I#/I I 768 -----I \I Agg I I T I I Deag I/ ------ 769 I I==========================I I 770 ------ /I I::::::::::I I:::::::::::I I\ ------ 771 I H I/#I I ----- I I#\I H I 772 I I# ------- -------- #I I 773 ------ ------ 775 H = Host 776 Agg = Aggregator (TE Tunnel Head-end) 777 Deagg = Deaggregator (TE Tunnel Tail-end) 778 T = Transit LSR 780 / = E2E RSVP reservation for a Voice flow 781 # = E2E RSVP reservation for a Video flow 782 == = DS-TE Tunnel from Class-Type 1 783 :: = DS-TE Tunnel from Class-Type 0 785 7.2. PSTN/3G Voice Trunking Scenario 787 An example application of the procedures specified in this document 788 is voice call admission control in large scale telephony trunking 789 environments. A Trunk VoIP Gateway may generate one aggregate RSVP 790 reservation for all the calls in place towards another given remote 791 Trunk VoIP Gateway (with resizing of this aggregate reservation in a 792 step function depending on current number of calls). In turn, these 793 reservations may be aggregated over MPLS TE tunnels over the packet 794 core so that tunnel Head-ends act as Aggregators and perform 795 admission control of Trunk Gateway reservations into MPLS TE Tunnels. 796 The MPLS TE tunnels may be protected by MPLS Fast Reroute. 797 This scenario is illustrated below: 799 ------ ------ 800 I GW I\ ------- -------- /I GW I 801 I I\\I I ----- I I//I I 802 -----I \I Agg I I T I I Deag I/ ------ 803 I I==========================I I 804 ------ /I I I I I I\ ------ 805 I GW I//I I ----- I I\\I GW I 806 I I/ ------- -------- \I I 807 ------ ------ 809 GW = VoIP Gateway 810 Agg = Aggregator (TE Tunnel Head-end) 811 Deagg = Deaggregator (TE Tunnel Tail-end) 812 T = Transit LSR 814 / = Aggregate Gateway to Gateway E2E RSVP reservation 815 == = TE Tunnel 817 8. Optional Use of RSVP Proxy on RSVP Aggregator 819 A number of approaches ([RSVP-PROXY], [L-RSVP]) have been, or are 820 being, discussed in the IETF in order to allow a network node to 821 behave as an RSVP proxy which: 822 - originates the Resv Message (in response to the Path message) on 823 behalf of the destination node 824 - originates the Path message (in response to some trigger) on 825 behalf of the source node. 827 We observe that such approaches may optionally be used in conjunction 828 with the aggregation of RSVP reservations over MPLS TE tunnels as 829 specified in this document. In particular, we consider the case where 830 the RSVP Aggregator/Deaggregator also behaves as the RSVP proxy. 832 As discussed in [RSVP-PROXY]: 834 "The proxy functionality does not imply merely generating a single 835 Resv message. Proxying the Resv involves installing state in the node 836 doing the proxy i.e. the proxying node should act as if it had 837 received a Resv from the true endpoint. This involves reserving 838 resources (if required), sending periodic refreshes of the Resv 839 message and tearing down the reservation if the Path is torn down." 841 Hence, when behaving as the RSVP Proxy, the RSVP Aggregator may 842 effectively perform resource reservation over the MPLS TE Tunnel (and 843 hence over the whole segment between the RSVP Aggregator and the RSVP 844 Deaggregator) even if the RSVP signaling only takes place upstream of 845 the MPLS TE Tunnel (i.e. between the host and the RSVP aggregator). 847 Also, the RSVP Proxy can generate the Path message on behalf of the 848 remote source host in order to achieve reservation in the return 849 direction (i.e. from RSVP aggregator/Deaggregator to host). 851 The resulting Signaling Flow is illustrated below, covering 852 reservations for both directions: 854 I----I I--------------I I------I I--------------I I----I 855 I I I Aggregator/ I I MPLS I I Aggregator/ I I I 856 IHostI I Deaggregator/I I cloudI I Deaggregator/I IHostI 857 I I I RSVP Proxy I I I I RSVP Proxy I I I 858 I----I I--------------I I------I I--------------I I----I 860 ==========TE Tunnel==========> 861 <========= TE Tunnel========== 863 Path Path 864 ------------> (1)-\ /-(i) <---------- 865 Resv I I Resv 866 <------------ (2)-/ \-(ii) ------------> 867 Path Path 868 <------------ (3) (iii) ------------> 869 Resv Resv 870 ------------> <------------ 872 (1)(i) : Aggregator/Deaggregator/Proxy receives Path message, 873 selects the TE tunnel, performs admission control over the TE Tunnel. 874 (1) and (i) happens independently of each other. 876 (2)(ii) : Aggregator/Deaggregator/Proxy generates the Resv message 877 towards Host. (2) is triggered by (1) and (ii) is triggered by (i). 878 Before generating this Resv message, the Aggregator/Proxy performs 879 admission control of the corresponding reservation over the TE tunnel 880 that will eventually carry the corresponding traffic. 882 (3)(iii) : Aggregator/Deaggregator/Proxy generates the Path message 883 towards Host for reservation in return direction. The actual trigger 884 for this depends on the actual RSVP proxy solution. As an example, 885 (3) and (iii) may simply be triggered respectively by (1) and (i). 887 Note that the details of the signaling flow may vary slightly 888 depending on the actual approach used for RSVP Proxy. For example, if 889 the [L-RSVP] approach was used instead of [RSVP-PROXY], an additional 890 PathRequest message would be needed from host to 891 Aggregator/Deaggregator/Proxy in order to trigger the generation of 892 the Path message for return direction. 894 But regardless of the details of the call flow and of the actual RSVP 895 Proxy approach, RSVP proxy may optionally be deployed in combination 896 with RSVP Aggregation over MPLS TE Tunnels, in such a way which 897 ensures (when used on both the Host-Aggregator and Deaggregator-Host 898 sides, and when both end systems support RSVP) that: 900 (i) admission control and resource reservation is performed on 901 every segment of the end-to-end path (i.e. between source 902 host and Aggregator, over the TE Tunnel between the 903 Aggregator and Deaggregator which itself has been subject 904 to admission control by MPLS TE, between Deaggregator and 905 destination host) 907 (ii) this is achieved in both direction 909 (iii) RSVP signaling is localized between hosts and 910 Aggregator/Deaggregator, which may result in significant 911 reduction in reservation establishment delays (and in turn 912 in post dial delay in the case where these reservations 913 are pre-conditions for voice call establishment), 914 particularly in the case where the MPLS TE tunnels span 915 long distances with high propagation delays. 917 9. Security Considerations 919 The security issues inherent to the use of RSVP, RSVP Aggregation and 920 MPLS TE apply. Those can be addressed as discussed in [RSVP], [RSVP- 921 AGG] and [RSVP-TE]. 923 Section 7 of [LSP-HIER] discusses security considerations stemming 924 from the fact that the implicit assumption of a binding between data 925 interface and the interface over which a control message is sent is 926 no longer valid. These security considerations are equally applicable 927 to the present document. 929 In addition, in the case where the Aggregators dynamically resize the 930 TE tunnels based on the current level of reservation, there are risks 931 that the TE tunnels used for RSVP aggregation hog resources in the 932 core which could prevent other TE Tunnels from being established. 933 There are also potential risks that such resizing results in 934 significant computation and signaling as well as churn on tunnel 935 paths. Such risks can be mitigated by configuration options allowing 936 control of TE tunnel dynamic resizing (maximum Te tunnel size, 937 maximum resizing frequency,...) and/or possibly by the use of TE 938 preemption. 940 If the Aggregator and Deaggregator are also acting as IPsec Security 941 Gateways, the Security Considerations of [SEC-ARCH] apply. 943 10. IANA Considerations 945 This document has no actions for IANA. 947 11. Acknowledgments 949 This document builds on the [RSVP-AGG], [RSVP-TUN] and [LSP-HIER] 950 specifications. Also, we would like to thank Tom Phelan, John Drake, 951 Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol 952 Iturralde and James Gibson for their input into this document. 954 12. Normative References 956 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 957 Requirement Levels, RFC2119, March 1997. 959 [RFC3668] S. Bradner, Intellectual Property Rights in IETF Technology, 960 RFC 3668, February 2004. 962 [BCP-78], S. Bradner, IETF Rights in Contributions, RFC3978, March 963 2005. 965 [RSVP] Braden et al., Resource ReSerVation Protocol (RSVP) -- Version 966 1 Functional Specification, RFC 2205, September 1997. 968 [INT-SERV] Braden, R., Clark, D. and S. Shenker, Integrated Services 969 in the Internet Architecture: an Overview, RFC 1633, June 1994. 971 [GUARANTEED] Shenker et al., Specification of Guaranteed Quality of 972 Service, RFC2212 974 [CONTROLLED] Wroclawski, Specification of the Controlled-Load Network 975 Element Service, RFC2211 977 [DIFFSERV] Blake et al., An Architecture for Differentiated Services, 978 RFC 2475 980 [INT-DIFF] A Framework for Integrated Services Operation over 981 Diffserv Networks, RFC 2998, November 2000. 983 [RSVP-AGG] Baker et al, Aggregation of RSVP for IPv4 and IPv6 984 Reservations, RFC 3175, September 2001. 986 [MPLS-TE] Awduche et al., "Requirements for Traffic Engineering over 987 MPLS", RFC 2702, September 1999. 989 [RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels, 990 RFC 3209, December 2001. 992 [DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of 993 Diff-Serv-aware MPLS Traffic Engineering, RFC 4124, June 2005. 995 [LSP-HIER] Kompella et al, Label Switched Paths (LSP) Hierarchy with 996 Generalized Multi-Protocol Label Switching (GMPLS) Traffic 997 Engineering (TE), RFC 4206, October 2005 999 [SEC-ARCH] Kent and Seo, Security Architecture for the Internet 1000 Protocol, RFC 4301, December 2005 1002 13. Informative References 1004 [DIFF-MPLS] Le Faucheur et al, MPLS Support of Diff-Serv, RFC3270, 1005 May 2002. 1007 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 1008 aware MPLS Traffic Engineering, RFC3564, July 2003. 1010 [6PE] De Clercq et al, Connecting IPv6 Islands over IPv4 MPLS using 1011 IPv6 Provider Edge Routers (6PE), work in progress 1013 [RSVP-IPSEC] Berger et al, RSVP Extensions for IPSEC Data Flows, RFC 1014 2207 1016 [RSVP-GEN-AGG] Le Faucheur et al, Generic Aggregate RSVP Reservations, 1017 draft-ietf-tsvwg-rsvp-ipsec, work in progress 1019 [RSVP-TUN] Terzis et al., RSVP Operation Over IP Tunnels, RFC 2746, 1020 January 2000 1022 [RSVP-PREEMP] Herzog, Signaled Preemption Priority Policy Element, 1023 RFC 3181 1025 [L-RSVP] Manner et al., Localized RSVP, draft-manner-lrsvp-04.txt, 1026 work in progress. 1028 [RSVP-PROXY] Gai et al., RSVP Proxy, draft-ietf-rsvp-proxy-03.txt 1029 (expired), work in progress. 1031 [RSVP-APPID] Bernet et al., Identity Representation for RSVP, RFC 1032 3182. 1034 [AUTOMESH] Vasseur and Leroux, Routing extensions for discovery of 1035 Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering 1036 (TE) mesh membership, draft-vasseur-ccamp-automesh-00.txt, work in 1037 progress. 1039 [SIP-RSVP] Camarillo, Integration of Resource Management and Session 1040 Initiation Protocol (SIP), RFC 3312 1042 14. Editor's Address: 1044 Francois Le Faucheur 1045 Cisco Systems, Inc. 1046 Village d'Entreprise Green Side - Batiment T3 1047 400, Avenue de Roumanille 1048 06410 Biot Sophia-Antipolis 1049 France 1050 Email: flefauch@cisco.com 1052 IPR Statements 1054 The IETF takes no position regarding the validity or scope of any 1055 Intellectual Property Rights or other rights that might be claimed to 1056 pertain to the implementation or use of the technology described in 1057 this document or the extent to which any license under such rights 1058 might or might not be available; nor does it represent that it has 1059 made any independent effort to identify any such rights. Information 1060 on the procedures with respect to rights in RFC documents can be 1061 found in BCP 78 and BCP 79. 1063 Copies of IPR disclosures made to the IETF Secretariat and any 1064 assurances of licenses to be made available, or the result of an 1065 attempt made to obtain a general license or permission for the use of 1066 such proprietary rights by implementers or users of this 1067 specification can be obtained from the IETF on-line IPR repository at 1068 http://www.ietf.org/ipr. 1070 The IETF invites any interested party to bring to its attention any 1071 copyrights, patents or patent applications, or other proprietary 1072 rights that may cover technology that may be required to implement 1073 this standard. 1074 Please address the information to the IETF at ietf-ipr@ietf.org. 1076 Disclaimer of Validity 1077 This document and the information contained herein are provided on an 1078 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1079 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1080 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1081 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1082 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1083 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1085 Copyright Notice 1087 Copyright (C) The Internet Society (2006). This document is subject 1088 to the rights, licenses and restrictions contained in BCP 78, and 1089 except as set forth therein, the authors retain all their rights. 1091 Appendix A - Example Usage of RSVP Aggregation over DSTE Tunnels for 1092 VoIP Call Admission Control (CAC) 1094 This Appendix presents an example scenario where the mechanisms 1095 described in this document are used, in combination with other 1096 mechanisms specified by the IETF, to achieve Call Admission Control 1097 (CAC) of Voice over IP (VoIP) traffic over the packet core. 1099 The information is that Appendix is purely informational and 1100 illustrative. 1102 Consider the scenario depicted in Figure A1. VoIP Gateways GW1 and 1103 GW2 are both signaling and media gateways. They are connected to an 1104 MPLS network via edge routers PE1 and PE2, respectively. In each 1105 direction, a DSTE tunnel passes from the head-end edge router, 1106 through core network P routers, to the tail-end edge router. GW1 and 1107 GW2 are RSVP-enabled. The RSVP reservations established by GW1 and 1108 GW2 are aggregated by PE1 and PE2 over the DS-TE tunnels. For 1109 reservations going from GW1 to GW2, PE1 serves as the 1110 aggregator/head-end and PE2 serves as the de-aggregator/tail-end. For 1111 reservations going from GW2 to GW2, PE2 serves as the 1112 aggregator/head-end and PE1 serves as the de-aggregator/tail-end. 1114 To determine whether there is sufficient bandwidth in the MPLS core 1115 to complete a connection, the originating and destination GWs each 1116 send for each connection a Resource Reservation Protocol (RSVP) 1117 bandwidth request to the network PE router to which it is connected. 1118 The bandwidth request takes into account VoIP header compression, 1119 where applicable. As part of its Aggregator role, the PE router 1120 effectively performs admission control of the bandwidth request 1121 generated by the GW onto the resources of the corresponding DS-TE 1122 tunnel. 1124 In this example, in addition to behaving as Aggregator/Deaggregator, 1125 PE1 and PE2 behave as RSVP proxy. So when a PE receives a Path 1126 message from a GW, it does not propagate the Path message any further. 1127 Rather, the PE performs admission control of the bandwidth signaled 1128 in the Path message over the DSTE tunnel towards the destination. 1129 Assuming there is enough bandwidth available on that tunnel, the PE 1130 adjusts its book-keeping of remaining available bandwidth on the 1131 tunnel and generates a Resv message back towards the GW to confirm 1132 resources have been reserved over the DSTE tunnel. 1134 ,-. ,-. 1135 _.---' `---' `-+ 1136 ,-'' +------------+ : 1137 ( | | `. 1138 \ ,' CCA `. : 1139 \ ,' | | `. ; 1140 ;' +------------+ `._ 1141 ,'+ ; `. 1142 ,' -+ Application Layer' `. 1143 SIP,' `---+ | ; `.SIP 1144 ,' `------+---' `. 1145 ,' `. 1146 ,' `. 1147 ,' ,-. ,-. `. 1148 ,' ,--+ `--+--'- --'\ `._ 1149 +-`--+_____+------+ { +----+ +----+ `. +------+_____+----+ 1150 |GW1 | RSVP| |______| P |___| P |______| | RSVP|GW2 | 1151 | |-----| PE1 | { +----+ +----+ /+| PE2 |-----| | 1152 | | | |==========================>| | | | 1153 +-:--+ RTP | |<==========================| | RTP +-:--+ 1154 _|..__ +------+ { DSTE Tunnels ; +------+ __----|--. 1155 _,' \-| ./ -'._ / | 1156 | Access \ / +----+ \, |_ Access | 1157 | Network | \_ | P | | / Network | 1158 | / `| +----+ / | ' 1159 `--. ,.__,| | IP/MPLS Network / '---'- ----' 1160 '`' '' ' .._,,'`.__ _/ '---' | 1161 | '`''' | 1162 C1 C2 1164 Figure A1. Integration of SIP Resource Management, DSTE 1165 and RSVP Aggregation 1167 [SIP-RSVP] discusses how network quality of service can be made a 1168 precondition for establishment of sessions initiated by the Session 1169 Initiation Protocol (SIP). These preconditions require that the 1170 participant reserve network resources before continuing with the 1171 session. The reservation of network resources are performed through a 1172 signaling protocol such as RSVP. 1174 Our example environment relies of [SIP-RSVP] to synchronize RSVP 1175 bandwidth reservations with SIP. For example, the RSVP bandwidth 1176 requests may be integrated into the call setup flow as follows (See 1177 call setup flow diagram in Figure A2): 1179 - Caller C1 initiates a call by sending a SIP INVITE to VoIP 1180 gateway GW1, which passes the INVITE along to the call control 1181 agent (CCA). The INVITE message may contain a list of codecs 1182 that the calling phone can support. 1184 - VoIP gateway GW2, chooses a compatible codec from the list and 1185 responds with a SIP message 183 Session Progress. 1187 - When GW1 receives the SIP response message and learns the codec 1188 to be used, it knows how much bandwidth is required for the 1189 call. 1191 - GW1 sends an RSVP Path message to PE1, requesting bandwidth for 1192 the call. 1194 - GW2 also sends an RSVP Path message to PE2. 1196 - Assuming that the tunnel (from left to right) has sufficient 1197 bandwidth, PE1 responds to GW1 with a Resv message 1199 - Again assuming the tunnel (from right to left) has sufficient 1200 bandwidth, PE2 responds to GW2 with a Resv message 1202 - GW2 sends a SIP 200 OK message to GW1. 1204 - GW1 sends a SIP UPDATE message to GW2. 1206 - Upon receiving the UPDATE, GW2 sends the INVITE to the 1207 destination phone, which responds with SIP message 180 RINGING. 1209 - When (and if) the called party answers, the destination phone 1210 responds with another SIP 200 OK which completes the connection 1211 and tells the calling party that there is now reserved 1212 bandwidth in both directions so that conversation can begin. 1214 - RTP media streams in both directions pass through the DSTE 1215 tunnels as they traverse the MPLS network. 1217 IP-Phone/ IP-Phone/ 1218 TA-C1 GW1 PE1 CCA PE2 GW2 TA-C2 1219 | INVITE|(SDP1) | INVITE | INVITE | | | 1220 |---------->|-------|---------->|------------|------->| | 1221 | 100|TRYING | | | | | 1222 |<----------|-------|-----------| | | | 1223 | 183|(SDP2) | | | | | 1224 |<----------|-------|-----------|------------|--------| | 1225 | | PATH | | | PATH | | 1226 | |------>| | |<-------| | 1227 | | RESV | | | RESV | | 1228 | |<------| | |------->| | 1229 | | | UPDATE|(SDP3) | | | 1230 | |-------|-----------|------------|------->| | 1231 | | | 200 OK|(SDP4) | | | 1232 | |<------|-----------|------------|--------| INVITE | 1233 | | | | | |---------->| 1234 |180 RINGING| | 180|RINGING | |180 RINGING| 1235 |<----------|<------|-----------|------------|--------|<----------| 1236 | 200 OK | 200|OK | 200|OK | 200 OK | 1237 |<----------|<------|-----------|<-----------|--------|<----------| 1238 | | | | | | | 1239 | | | DSTE|TUNNEL | | | 1240 | RTP|MEDIA |-----------|------------| | | 1241 |===========|=======|===========|============|========|==========>| 1242 | | |-----------|------------| | | 1243 | | | | | | | 1244 | | |-----------|------------| | | 1245 |<==========|=======|===========|============|========|===========| 1246 | | |-----------|------------| | | 1247 DSTE TUNNEL 1249 Figure A2. VoIP QoS CAC using SIP with Preconditions 1251 Through the collaboration between SIP resource management, RSVP 1252 signaling, RSVP Aggregation and DS-TE as described above, we see 1253 that: 1254 a) the PE and GW collaborate to determine whether there is enough 1255 bandwidth on the tunnel between the calling and called GWs to 1256 accommodate the connection, 1257 b) the corresponding accept/reject decision is communicated to the 1258 GWs on a connection-by-connection basis, and 1259 c) the PE can optimize network resources by dynamically adjusting 1260 the bandwidth of each tunnel according to the load over that tunnel. 1261 For example, if a tunnel is operating near capacity, the network may 1262 dynamically adjust the tunnel size within a set of parameters. 1264 We note that admission Control of voice calls over the core network 1265 capacity is achieved in a hierarchical manner whereby: 1266 - DSTE tunnels are subject to Admission Control over the 1267 resources of the MPLS TE core 1268 - Voice calls are subject to CAC over the DSTE tunnel bandwidth 1269 This hierarchy is a key element in the scalability of this CAC 1270 solution for voice calls over an MPLS Core. 1272 It is also possible for the GWs to use aggregate RSVP reservations 1273 themselves instead of per-call RSVP reservations. For example, 1274 instead of setting one reservation for each call GW1 has in place 1275 towards GW2, GW1 may establish one (or a small number of) aggregate 1276 reservations as defined in [RSVP-AGG] which is used for all (or a 1277 subset of all) the calls towards GW2. This effectively provides an 1278 additional level of hierarchy whereby: 1279 - 1280 DSTE tunnels are subject to Admission Control over the 1281 resources of the MPLS TE core 1282 - Aggregate RSVP reservations (for the calls from one GW to 1283 another GW) are subject to Admission Control over the DSTE 1284 tunnels (as per the "RSVP Aggregation over TE Tunnels" 1285 procedures defined in this document) 1286 - Voice calls are subject to CAC by the GW over the aggregate 1287 reservation towards the appropriate destination GW. 1288 This pushes even further the scalability limits of this voice CAC 1289 architecture.