idnits 2.17.1 draft-ietf-tsvwg-rsvp-dste-04.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 985. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 962. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 969. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 975. ** 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 30 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 (July 2006) is 6495 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 860, but no explicit reference was found in the text == Unused Reference: 'BCP-78' is defined on line 863, 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-04.txt 6 Expires: January 2007 July 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..............12 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. Security Considerations.......................................19 78 9. IANA Considerations...........................................20 79 10. Acknowledgments..............................................20 80 11. Normative References.........................................20 81 12. Informative References.......................................21 82 13. Editor's Address:............................................22 83 Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator.......23 84 Appendix B - 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 - This document builds on the fact that there is exactly one 211 aggregate reservation per MPLS-TE tunnel, whereas RFC 2746 212 permits a model where one reservation is established on the 213 tunnel path for each end-to-end flow. 214 - We have assumed in the current document that a given MPLS-TE 215 tunnel will carry reserved traffic and nothing but reserved 216 traffic, which negates the requirement of RFC 2746 to 217 distinguish reserved and non-reserved traffic traversing the 218 same tunnel by using distinct encapsulations. 219 - There may be several MPLS-TE tunnels that share common head and 220 tail end routers, with head-end policy determining which tunnel 221 is appropriate for a particular flow. This scenario does not 222 appear to be addressed in RFC 2746. 224 At the same time, this document does have many similarities with RFC 225 2746. MPLS-TE tunnels are "type 2 tunnels" in the nomenclature of RFC 226 2746: 227 " 228 The (logical) link may be able to promise that some overall 229 level of resources is available to carry traffic, but not to 230 allocate resources specifically to individual data flows. 231 " 232 Aggregation of end-to-end RSVP reservations over TE tunnels combines 233 the benefits of [RSVP-AGG] with the benefits of MPLS including the 234 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 278 Bruce Davie 279 Cisco Systems, Inc. 280 300 Beaver Brook Road 281 Boxborough, MA 01719 282 USA 283 Email: bdavie@cisco.com 285 Christou Christou 286 Booz Allen Hamilton 287 8283 Greensboro Drive 288 McLean, VA 22102 289 USA 290 Email: christou_chris@bah.com 292 Michael Davenport 293 Booz Allen Hamilton 294 8283 Greensboro Drive 295 McLean, VA 22102 296 USA 297 Email: davenport_michael@bah.com 299 Jerry Ash 300 AT&T 301 200 Laurel Avenue 302 Middletown, NJ 07748, USA 303 USA 304 Email: gash@att.com 306 Bur Goode 307 AT&T 308 32 Old Orchard Drive 309 Weston, CT 06883 310 USA 311 Email: bgoode@att.com 313 3. Definitions 315 For readability, a number of definitions from [RSVP-AGG] as well as 316 definitions for commonly used MPLS TE terms are provided here: 318 Aggregator This is the process in (or associated with) the router 319 at the ingress edge of the aggregation region (with 320 respect to the end to end RSVP reservation) and 321 behaving in accordance with [RSVP-AGG]. In this 322 document, it is also the TE Tunnel Head-end. 324 Deaggregator This is the process in (or associated with) the router 325 at the egress edge of the aggregation region (with 326 respect to the end to end RSVP reservation) and 327 behaving in accordance with [RSVP-AGG]. In this 328 document, it is also the TE Tunnel Tail-end 330 E2E End to end 332 E2E reservation This is an RSVP reservation such that: 333 (i) corresponding Path messages are initiated 334 upstream of the Aggregator and terminated 335 downstream of the Deaggregator, and 336 (ii) corresponding Resv messages are initiated 337 downstream of the Deaggregator and 338 terminated upstream of the Aggregator, and 339 (iii) this RSVP reservation is to be aggregated 340 over an MPLS TE tunnel between the 341 Aggregator and Deaggregator. 342 An E2E RSVP reservation may be a per-flow 343 reservation. Alternatively, the E2E reservation 344 may itself be an aggregate reservation of various 345 types (e.g. Aggregate IP reservation, Aggregate 346 IPsec reservation). See section 5 and 6 for more 347 details on the types of E2E RSVP reservations. As 348 per regular RSVP operations, E2E RSVP reservations 349 are unidirectional. 351 Head-end 352 This is the Label Switch Router responsible for 353 establishing, maintaining and tearing down a given TE 354 tunnel. 356 Tail-end 357 This is the Label Switch Router responsible for 358 terminating a given TE tunnel 360 Transit LSR This is a Label Switch router that is on the path of a 361 given TE tunnel and is neither the Head-end nor the 362 Tail-end 364 4. Operations of RSVP Aggregation over TE with pre-established Tunnels 366 [RSVP-AGG] supports operations both in the case where aggregate RSVP 367 reservations are pre-established and in the case where Aggregators 368 and Deaggregators have to dynamically discover each other and 369 dynamically establish the necessary aggregate RSVP reservations. 371 Similarly, RSVP Aggregation over TE tunnels could operate both in the 372 case where the TE tunnels are pre-established and in the case where 373 the tunnels need to be dynamically established. 375 In this document we provide a detailed description of the procedures 376 in the case where TE tunnels are already established. These 377 procedures are based on those defined in [LSP-HIER]. The routing 378 aspects discussed in section 3 of [LSP-HIER] are not relevant here 379 because those aim at allowing the constraint based routing of end-to- 380 end TE LSPs to take into account the (aggregate) TE tunnels. In the 381 present document, the end-to-end RSVP reservations to be aggregated 382 over the TE tunnels rely on regular SPF routing. However, as already 383 mentioned in [LSP-HIER], we note that a TE Tunnel may be advertised 384 into ISIS or OSPF, to be used in normal SPF by nodes upstream of the 385 Aggregator. This would affect SPF routing and thus routing of end-to- 386 end RSVP reservations. The control of aggregation boundaries 387 discussed in section 6 of [LSP-HIER] is also not relevant here. This 388 uses information exchanged in GMPLS protocols to dynamically discover 389 the aggregation boundary. In this document, TE tunnels are pre- 390 established, so that the aggregation boundary can be easily inferred. 391 The signaling aspects discussed in section 6.2 of [LSP-HIER] apply to 392 the establishment/termination of the aggregate TE tunnels when this 393 is triggered by GMPLS mechanisms (e.g. as a result of an end-to-end 394 TE LSP establishment request received at the aggregation boundary) . 395 As this document assumes pre-established tunnels, those aspects are 396 not relevant here. The signaling aspects discussed in section 6.1 of 397 [LSP-HIER] relate to the establishment/maintenance of the end-to-end 398 TE LSPs over the aggregate TE tunnel. This document describes how to 399 use the same procedures as those specified in section 6.1 of [LSP- 400 HIER], but for the establishment of end-to-end RSVP reservations 401 (instead of end-to-end TE LSPs) over the TE tunnels. This is covered 402 further in section 4 of the present document. 404 Pre-establishment of the TE tunnels may be triggered by any 405 mechanisms including for example manual configuration or automatic 406 establishment of a TE tunnel mesh through dynamic discovery of TE 407 Mesh membership as allowed in [AUTOMESH]. 409 Procedures in the case of dynamically established TE tunnels are for 410 further studies. 412 4.1. Reference Model 414 I----I I----I 415 H--I R I\ I-----I I------I /I R I--H 416 H--I I\\I I I---I I I//I I--H 417 I----I \I He/ I I T I I Te/ I/ I----I 418 I Agg I=======================I Deag I 420 /I I I I I I\ 421 H--------//I I I---I I I\\--------H 422 H--------/ I-----I I------I \--------H 424 H = Host requesting end-to-end RSVP reservations 425 R = RSVP router 426 He/Agg = TE tunnel Head-end/Aggregator 427 Te/Deag = TE tunnel Tail-end/Deaggregator 428 T = Transit LSR 430 -- = E2E RSVP reservation 431 == = TE Tunnel 433 4.2. Receipt of E2E Path message By the Aggregator 435 The first event is the arrival of the E2E Path message at the 436 Aggregator. The Aggregator MUST follow traditional RSVP procedures 437 for processing of this E2E path message augmented with the extensions 438 documented in this section. 440 The Aggregator MUST first attempt to map the E2E reservation onto a 441 TE tunnel. This decision is made in accordance with routing 442 information as well as any local policy information that may be 443 available at the Aggregator. Examples of such policies appear in the 444 following paragraphs. Just for illustration purposes, among many 445 other criteria, such mapping policies might take into account the 446 Intserv service type, the Application Identity [RSVP-APPID] and/or 447 the signaled preemption [RSVP-PREEMP] of the E2E reservation (for 448 example, the aggregator may take into account the E2E reservations 449 RSVP preemption priority and the MPLS TE Tunnel set-up and/or hold 450 priorities when mapping the E2E reservation onto an MPLS TE tunnel). 452 There are situations where the Aggregator is able to make a final 453 mapping decision. That would be the case, for example, if there is a 454 single TE tunnel towards the destination and if the policy is to map 455 any E2E RSVP reservation onto TE Tunnels. 457 There are situations where the Aggregator is not able to make a final 458 determination. That would be the case, for example, if routing 459 identifies two DS-TE tunnels towards the destination, one belonging 460 to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to 461 map Intserv Guaranteed Services reservations to a Class-Type 1 tunnel 462 and Intserv Controlled Load reservations to a Class-Type 0 tunnel, 463 and if the E2E RSVP Path message advertises both Guaranteed Service 464 and Controlled Load. 466 Whether final or tentative, the Aggregator makes a mapping decision 467 and selects a TE tunnel. Before forwarding the E2E Path message 468 towards the receiver, the Aggregator SHOULD update the ADSPEC inside 469 the E2E Path message to reflect the impact of the MPLS TE cloud onto 470 the QoS achievable by the E2E flow. This update is a local matter and 471 may be based on configured information, on information available in 472 the MPLS TE topology database, on the current TE tunnel path, on 473 information collected via RSVP-TE signaling, or combinations of those. 474 Updating the ADSPEC allow receivers that take into account the 475 information collected in the ADSPEC within the network (such as delay 476 and bandwidth estimates) to make more informed reservation decisions. 478 The Aggregator MUST then forward the E2E Path message to the 479 Deaggregator (which is the tail-end of the selected TE tunnel). In 480 accordance with [LSP-HIER], the Aggregator MUST send the E2E Path 481 message with an IF_ID RSVP_HOP object instead of an RSVP_HOP object. 482 The data interface identification MUST identify the TE Tunnel. 484 To send the E2E Path message, the Aggregator MUST address it directly 485 to the Deaggregator by setting the destination address in the IP 486 Header of the E2E Path message to the Deaggregator address. The 487 Router Alert is not set in the E2E Path message. 489 Optionally, the Aggregator MAY also encapsulate the E2E Path message 490 in an IP tunnel or in the TE tunnel itself. 492 Regardless of the encapsulation method, the Router Alert is not set. 493 Thus, the E2E Path message will not be visible to routers along the 494 path from the Aggregator to the Deaggregator. Therefore, in contrast 495 to the procedures of [RSVP-AGG], the IP Protocol number need not be 496 modified to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating 497 "RSVP") by the Aggregator. 499 In some environments, the Aggregator and Deaggregator MAY also act as 500 IPsec Security Gateways in order to provide IPsec protection to E2E 501 traffic when it transits between the Aggregator and the Deaggregator. 502 In that case, to transmit the E2E Path message to the Deaggregator, 503 the Aggregator MUST send the E2E Path message into the relevant IPsec 504 tunnel terminating on the Deaggregator. 506 E2E PathTear and ResvConf messages MUST be forwarded by the 507 Aggregator to the Deaggregator exactly like Path messages. 509 4.3. Handling of E2E Path message By Transit LSRs 511 Since the E2E Path message is addressed directly to the Deaggregator 512 and does not have Router Alert set, it is hidden from all transit 513 LSRs. 515 4.4. Receipt of E2E Path Message by Deaggregator 517 On receipt of the E2E Path message addressed to it, the Deaggregator 518 will notice that the IP Protocol number is set to "RSVP" and will 519 thus perform RSVP processing of the E2E Path message. 521 As with [LSP-HIER], the IP TTL vs. RSVP TTL check MUST NOT be made. 522 The Deaggregator is informed that this check is not to be made 523 because of the presence of the IF_ID RSVP HOP object. 525 The Deaggregator MAY support the option to perform the following 526 checks (defined in [LSP-HIER]) by the receiver Y of the IF_ID 527 RSVP_HOP object: 529 1. Make sure that the data interface identified in the IF_ID 530 RSVP_HOP object actually terminates on Y. 531 2. Find the "other end" of the above data interface, say X. 532 Make sure that the PHOP in the IF_ID RSVP_HOP object is a 533 control channel address that belongs to the same node as X. 535 The information necessary to perform these checks may not always be 536 available to the Deaggregator. Hence, the Deaggregator MUST support 537 operations in such environments where the checks cannot be made. 539 The Deaggregator MUST forward the E2E Path downstream towards the 540 receiver. In doing so, the Deaggregator sets the destination address 541 in the IP header of the E2E Path message to the IP address found in 542 the destination address field of the Session object. The Deaggregator 543 also sets the Router Alert. 545 An E2E PathErr sent by the Deaggregator in response to the E2E Path 546 message (which contains an IF_ID RSVP_HOP object) SHOULD contain an 547 IF_ID RSVP_HOP object. 549 4.5. Handling of E2E Resv Message by Deaggregator 551 As per regular RSVP operations, after receipt of the E2E Path, the 552 receiver generates an E2E Resv message which travels upstream hop-by- 553 hop towards the sender. 555 On receipt of the E2E Resv, the Deaggregator MUST follow traditional 556 RSVP procedures on receipt of the E2E Resv message. This includes 557 performing admission control for the segment downstream of the 558 Deaggregator and forwarding the E2E Resv message to the PHOP signaled 559 earlier in the E2E Path message and which identifies the Aggregator. 560 Since the E2E Resv message is directly addressed to the Aggregator 561 and does not carry the Router Alert option (as per traditional RSVP 562 Resv procedures), the E2E Resv message is hidden from the routers 563 between the Deaggregator and the Aggregator which, therefore, handle 564 the E2E Resv message as a regular IP packet. 566 If the Aggregator and Deaggregator are also acting as IPsec Security 567 Gateways, the Deaggregator MUST send the E2E Resv message into the 568 relevant IPsec tunnel terminating on the Aggregator. 570 4.6. Handling of E2E Resv Message by the Aggregator 572 The Aggregator is responsible for ensuring that there is sufficient 573 bandwidth available and reserved over the appropriate TE tunnel to 574 the Deaggregator for the E2E reservation. 576 On receipt of the E2E Resv message, the Aggregator MUST first perform 577 the final mapping onto the final TE tunnel (if the previous mapping 578 was only a tentative one). 580 If the tunnel did not change during the final mapping, the Aggregator 581 continues processing of the E2E Resv as described in the four 582 following paragraphs. 584 The aggregator calculates the size of the resource request using 585 traditional RSVP procedures. That is, it follows the procedures in 586 [RSVP] to determine the resource requirements from the Sender Tspec 587 and the Flowspec contained in the Resv. Then it compares the resource 588 request with the available resources of the selected TE tunnel. 590 If sufficient bandwidth is available on the final TE tunnel, the 591 Aggregator MUST update its internal understanding of how much of the 592 TE Tunnel is in use and MUST forward the E2E Resv messages to the 593 corresponding PHOP. 595 As noted in [RSVP-AGG], a range of policies MAY be applied to the re- 596 sizing of the aggregate reservation (in this case, the TE tunnel.) 597 For example, the policy may be that the reserved bandwidth of the 598 tunnel can only be changed by configuration. More dynamic policies 599 are also possible, whereby the aggregator may attempt to increase the 600 reserved bandwidth of the tunnel in response to the amount of 601 allocated bandwidth that has been used by E2E reservations. 602 Furthermore, to avoid the delay associated with the increase of the 603 Tunnel size, the Aggregator may attempt to anticipate the increases 604 in demand and adjust the TE tunnel size ahead of actual needs by E2E 605 reservations. In order to reduce disruptions, the aggregator SHOULD 606 use "make-before-break" procedures as described in [RSVP-TE] to alter 607 the TE tunnel bandwidth". 609 If sufficient bandwidth is not available on the final TE Tunnel, the 610 Aggregator MUST follow the normal RSVP procedure for a reservation 611 being placed with insufficient bandwidth to support this reservation. 612 That is, the reservation is not installed and a ResvError is sent 613 back towards the receiver. 615 If the tunnel did change during the final mapping, the Aggregator 616 MUST first resend to the Deaggregator an E2E Path message with the 617 IF_ID RSVP_HOP data interface identification identifying the final TE 618 Tunnel. If needed, the ADSPEC information in this E2E Path message 619 SHOULD be updated. Then the Aggregator MUST 620 - either drop the E2E Resv message 621 - or proceed with the processing of the E2E Resv in the same 622 manner as in the case where the tunnel did not change and 623 described above. 624 In the former case, admission control over the final TE tunnel (and 625 forwarding of E2E Resv message upstream towards the sender) would 626 only occur when the Aggregator receives the subsequent E2E Resv 627 message (that will be sent by the Deaggregator in response to the 628 resent E2E Path). In the latter case, admission control over the 629 final Tunnel is carried out by Aggregator right away and if 630 successful the E2E Resv message is generated upstream towards the 631 sender. 633 On receipt of an E2E ResvConf from the Aggregator, the Deaggregator 634 MUST forward the E2E ResvConf downstream towards the receiver. In 635 doing so, the Deaggregator sets the destination address in the IP 636 header of the E2E ResvConf message to the IP address found in the 637 RESV_CONFIRM object of the corresponding Resv. The Deaggregator also 638 sets the Router Alert. 640 4.7. Forwarding of E2E traffic by Aggregator 642 When the Aggregator receives a data packet belonging to an E2E 643 reservations currently mapped over a given TE tunnel, the Aggregator 644 MUST encapsulate the packet into that TE tunnel. 646 If the Aggregator and Deaggregator are also acting as IPsec Security 647 Gateways, the Aggregator MUST also encapsulate the data packet into 648 the relevant IPsec tunnel terminating on the Deaggregator before 649 transmission into the MPLS TE tunnel. 651 4.8. Removal of E2E reservations 653 E2E reservations are removed in the usual way via PathTear, ResvTear, 654 timeout, or as the result of an error condition. When a reservation 655 is removed, the Aggregator MUST update its local view of the 656 resources available on the corresponding TE tunnel accordingly. 658 4.9. Removal of TE Tunnel 660 Should a TE Tunnel go away (presumably due to a configuration change, 661 route change, or policy event), the aggregator behaves much like a 662 conventional RSVP router in the face of a link failure. That is, it 663 may try to forward the Path messages onto another tunnel, if routing 664 and policy permit, or it may send Path_Error messages to the sender 665 if no suitable tunnel exists. In case the Path messages are forwarded 666 onto another tunnel which terminates on a different Deaggregator, or 667 the reservation is torn-down via Path Error messages, the reservation 668 state established on the router acting as the Deaggregator before the 669 TE tunnel went away, will time out since it will no longer be 670 refreshed. 672 4.10. Example Signaling Flow 674 Aggregator Deaggregator 676 (*) 677 RSVP-TE Path 678 =========================> 680 RSVP-TE Resv 681 <========================= 682 (**) 684 E2E Path 685 --------------> 686 (1) 687 E2E Path 688 -------------------------------> 689 (2) 690 E2E Path 691 -----------> 693 E2E Resv 694 <----------- 695 (3) 696 E2E Resv 697 <----------------------------- 698 (4) 699 E2E Resv 700 <------------- 702 (*) Aggregator is triggered to pre-establish the TE Tunnel(s) 704 (**) TE Tunnel(s) are pre-established 706 (1) Aggregator tentatively selects the TE tunnel and forwards 707 E2E path to Deaggregator 709 (2) Deaggregator forwards the E2E Path towards receiver 711 (3) Deaggregator forwards the E2E Resv to the Aggregator 713 (4) Aggregator selects final TE tunnel, checks that there is 714 sufficient bandwidth on TE tunnel and forwards E2E Resv to 715 PHOP. If final tunnel is different from tunnel tentatively 716 selected, the Aggregator re-sends an E2E Path. 718 5. IPv4 and IPv6 Applicability 720 The procedures defined in this document are applicable to all the 721 following cases: 723 (1) Aggregation of E2E IPv4 RSVP reservations over IPv4 TE 724 Tunnels 725 (2) Aggregation of E2E IPv6 RSVP reservations over IPv6 TE 726 Tunnels 727 (3) Aggregation of E2E IPv6 RSVP reservations over IPv4 TE 728 tunnels, provided a mechanism such as [6PE] is used by the 729 Aggregator and Deaggregator for routing of IPv6 traffic over 730 an IPv4 MPLS core, 731 (4) Aggregation of E2E IPv4 RSVP reservations over IPv6 TE 732 tunnels, provided a mechanism is used by the Aggregator and 733 Deaggregator for routing IPv4 traffic over IPv6 MPLS. 735 6. E2E Reservations Applicability 737 The procedures defined in this document are applicable to many types 738 of E2E RSVP reservations including the following cases: 739 (1) the E2E RSVP reservation is a per-flow reservation where the 740 flow is characterized by the usual 5-tuple 741 (2) the E2E reservation is an aggregate reservation for multiple 742 flows as described in [RSVP-AGG] or [RSVP-GEN-AGG] where the 743 set of flows is characterized by the 745 (3) the E2E reservation is a reservation for an IPsec protected 746 flow. For example, where the flow is characterized by the 747 as described in 748 [RSVP-IPSEC]. 750 7. Example Deployment Scenarios 752 7.1. Voice and Video Reservations Scenario 754 An example application of the procedures specified in this document 755 is admission control of voice and video in environments with very 756 high numbers of hosts. In the example illustrated below, hosts 757 generate end-to-end per-flow reservations for each of their video 758 streams associated with a video-conference, each of their audio 759 streams associated with a video-conference and each of their voice 760 calls. These reservations are aggregated over MPLS DS-TE tunnels over 761 the packet core. The mapping policy defined by the user maybe that 762 all the reservations for audio and voice streams are mapped onto DS- 763 TE tunnels of Class-Type 1 while reservations for video streams are 764 mapped onto DS-TE tunnels of Class-Type 0. 766 ------ ------ 767 I H I# ------- -------- #I H I 768 I I\#I I ----- I I#/I I 769 -----I \I Agg I I T I I Deag I/ ------ 770 I I==========================I I 771 ------ /I I::::::::::I I:::::::::::I I\ ------ 772 I H I/#I I ----- I I#\I H I 773 I I# ------- -------- #I I 774 ------ ------ 776 H = Host 777 Agg = Aggregator (TE Tunnel Head-end) 778 Deagg = Deaggregator (TE Tunnel Tail-end) 779 T = Transit LSR 781 / = E2E RSVP reservation for a Voice flow 782 # = E2E RSVP reservation for a Video flow 783 == = DS-TE Tunnel from Class-Type 1 784 :: = DS-TE Tunnel from Class-Type 0 786 7.2. PSTN/3G Voice Trunking Scenario 788 An example application of the procedures specified in this document 789 is voice call admission control in large scale telephony trunking 790 environments. A Trunk VoIP Gateway may generate one aggregate RSVP 791 reservation for all the calls in place towards another given remote 792 Trunk VoIP Gateway (with resizing of this aggregate reservation in a 793 step function depending on current number of calls). In turn, these 794 reservations may be aggregated over MPLS TE tunnels over the packet 795 core so that tunnel Head-ends act as Aggregators and perform 796 admission control of Trunk Gateway reservations into MPLS TE Tunnels. 797 The MPLS TE tunnels may be protected by MPLS Fast Reroute. 798 This scenario is illustrated below: 800 ------ ------ 801 I GW I\ ------- -------- /I GW I 802 I I\\I I ----- I I//I I 803 -----I \I Agg I I T I I Deag I/ ------ 804 I I==========================I I 805 ------ /I I I I I I\ ------ 806 I GW I//I I ----- I I\\I GW I 807 I I/ ------- -------- \I I 808 ------ ------ 810 GW = VoIP Gateway 811 Agg = Aggregator (TE Tunnel Head-end) 812 Deagg = Deaggregator (TE Tunnel Tail-end) 813 T = Transit LSR 815 / = Aggregate Gateway to Gateway E2E RSVP reservation 816 == = TE Tunnel 818 8. Security Considerations 820 The security issues inherent to the use of RSVP, RSVP Aggregation and 821 MPLS TE apply. Those can be addressed as discussed in [RSVP], [RSVP- 822 AGG] and [RSVP-TE]. 824 Section 7 of [LSP-HIER] discusses security considerations stemming 825 from the fact that the implicit assumption of a binding between data 826 interface and the interface over which a control message is sent is 827 no longer valid. These security considerations are equally applicable 828 to the present document. 830 In addition, in the case where the Aggregators dynamically resize the 831 TE tunnels based on the current level of reservation, there are risks 832 that the TE tunnels used for RSVP aggregation hog resources in the 833 core which could prevent other TE Tunnels from being established. 834 There are also potential risks that such resizing results in 835 significant computation and signaling as well as churn on tunnel 836 paths. Such risks can be mitigated by configuration options allowing 837 control of TE tunnel dynamic resizing (maximum Te tunnel size, 838 maximum resizing frequency,...) and/or possibly by the use of TE 839 preemption. 841 If the Aggregator and Deaggregator are also acting as IPsec Security 842 Gateways, the Security Considerations of [SEC-ARCH] apply. 844 9. IANA Considerations 846 This document has no actions for IANA. 848 10. Acknowledgments 850 This document builds on the [RSVP-AGG], [RSVP-TUN] and [LSP-HIER] 851 specifications. Also, we would like to thank Tom Phelan, John Drake, 852 Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol 853 Iturralde and James Gibson for their input into this document. 855 11. Normative References 857 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 858 Requirement Levels, RFC2119, March 1997. 860 [RFC3668] S. Bradner, Intellectual Property Rights in IETF Technology, 861 RFC 3668, February 2004. 863 [BCP-78], S. Bradner, IETF Rights in Contributions, RFC3978, March 864 2005. 866 [RSVP] Braden et al., Resource ReSerVation Protocol (RSVP) -- Version 867 1 Functional Specification, RFC 2205, September 1997. 869 [INT-SERV] Braden, R., Clark, D. and S. Shenker, Integrated Services 870 in the Internet Architecture: an Overview, RFC 1633, June 1994. 872 [GUARANTEED] Shenker et al., Specification of Guaranteed Quality of 873 Service, RFC2212 875 [CONTROLLED] Wroclawski, Specification of the Controlled-Load Network 876 Element Service, RFC2211 878 [DIFFSERV] Blake et al., An Architecture for Differentiated Services, 879 RFC 2475 881 [INT-DIFF] A Framework for Integrated Services Operation over 882 Diffserv Networks, RFC 2998, November 2000. 884 [RSVP-AGG] Baker et al, Aggregation of RSVP for IPv4 and IPv6 885 Reservations, RFC 3175, September 2001. 887 [MPLS-TE] Awduche et al., "Requirements for Traffic Engineering over 888 MPLS", RFC 2702, September 1999. 890 [RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels, 891 RFC 3209, December 2001. 893 [DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of 894 Diff-Serv-aware MPLS Traffic Engineering, RFC 4124, June 2005. 896 [LSP-HIER] Kompella et al, Label Switched Paths (LSP) Hierarchy with 897 Generalized Multi-Protocol Label Switching (GMPLS) Traffic 898 Engineering (TE), RFC 4206, October 2005 900 [SEC-ARCH] Kent and Seo, Security Architecture for the Internet 901 Protocol, RFC 4301, December 2005 903 12. Informative References 905 [DIFF-MPLS] Le Faucheur et al, MPLS Support of Diff-Serv, RFC3270, 906 May 2002. 908 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 909 aware MPLS Traffic Engineering, RFC3564, July 2003. 911 [6PE] De Clercq et al, Connecting IPv6 Islands over IPv4 MPLS using 912 IPv6 Provider Edge Routers (6PE), work in progress 914 [RSVP-IPSEC] Berger et al, RSVP Extensions for IPSEC Data Flows, RFC 915 2207 917 [RSVP-GEN-AGG] Le Faucheur et al, Generic Aggregate RSVP Reservations, 918 draft-ietf-tsvwg-rsvp-ipsec, work in progress 920 [RSVP-TUN] Terzis et al., RSVP Operation Over IP Tunnels, RFC 2746, 921 January 2000 923 [RSVP-PREEMP] Herzog, Signaled Preemption Priority Policy Element, 924 RFC 3181 926 [L-RSVP] Manner et al., Localized RSVP, draft-manner-lrsvp-04.txt, 927 work in progress. 929 [RSVP-PROXY] Gai et al., RSVP Proxy, draft-ietf-rsvp-proxy-03.txt 930 (expired), work in progress. 932 [RSVP-APPID] Bernet et al., Identity Representation for RSVP, RFC 933 3182. 935 [AUTOMESH] Vasseur and Leroux, Routing extensions for discovery of 936 Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering 937 (TE) mesh membership, draft-vasseur-ccamp-automesh-00.txt, work in 938 progress. 940 [SIP-RSVP] Camarillo, Integration of Resource Management and Session 941 Initiation Protocol (SIP), RFC 3312 943 13. Editor's Address: 945 Francois Le Faucheur 946 Cisco Systems, Inc. 947 Village d'Entreprise Green Side - Batiment T3 948 400, Avenue de Roumanille 949 06410 Biot Sophia-Antipolis 950 France 951 Email: flefauch@cisco.com 953 IPR Statements 955 The IETF takes no position regarding the validity or scope of any 956 Intellectual Property Rights or other rights that might be claimed to 957 pertain to the implementation or use of the technology described in 958 this document or the extent to which any license under such rights 959 might or might not be available; nor does it represent that it has 960 made any independent effort to identify any such rights. Information 961 on the procedures with respect to rights in RFC documents can be 962 found in BCP 78 and BCP 79. 964 Copies of IPR disclosures made to the IETF Secretariat and any 965 assurances of licenses to be made available, or the result of an 966 attempt made to obtain a general license or permission for the use of 967 such proprietary rights by implementers or users of this 968 specification can be obtained from the IETF on-line IPR repository at 969 http://www.ietf.org/ipr. 971 The IETF invites any interested party to bring to its attention any 972 copyrights, patents or patent applications, or other proprietary 973 rights that may cover technology that may be required to implement 974 this standard. 975 Please address the information to the IETF at ietf-ipr@ietf.org. 977 Disclaimer of Validity 979 This document and the information contained herein are provided on an 980 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 981 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 982 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 983 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 984 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 985 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 987 Copyright Notice 989 Copyright (C) The Internet Society (2006). This document is subject 990 to the rights, licenses and restrictions contained in BCP 78, and 991 except as set forth therein, the authors retain all their rights. 993 Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator 995 A number of approaches ([RSVP-PROXY], [L-RSVP]) have been, or are 996 being, discussed in the IETF in order to allow a network node to 997 behave as an RSVP proxy which: 998 - originates the Resv Message (in response to the Path message) on 999 behalf of the destination node 1000 - originates the Path message (in response to some trigger) on 1001 behalf of the source node. 1003 We observe that such approaches may optionally be used in conjunction 1004 with the aggregation of RSVP reservations over MPLS TE tunnels as 1005 specified in this document. In particular, we consider the case where 1006 the RSVP Aggregator/Deaggregator also behaves as the RSVP proxy. 1008 The information is this Appendix is purely informational and 1009 illustrative. 1011 As discussed in [RSVP-PROXY]: 1013 "The proxy functionality does not imply merely generating a single 1014 Resv message. Proxying the Resv involves installing state in the node 1015 doing the proxy i.e. the proxying node should act as if it had 1016 received a Resv from the true endpoint. This involves reserving 1017 resources (if required), sending periodic refreshes of the Resv 1018 message and tearing down the reservation if the Path is torn down." 1020 Hence, when behaving as the RSVP Proxy, the RSVP Aggregator may 1021 effectively perform resource reservation over the MPLS TE Tunnel (and 1022 hence over the whole segment between the RSVP Aggregator and the RSVP 1023 Deaggregator) even if the RSVP signaling only takes place upstream of 1024 the MPLS TE Tunnel (i.e. between the host and the RSVP aggregator). 1026 Also, the RSVP Proxy can generate the Path message on behalf of the 1027 remote source host in order to achieve reservation in the return 1028 direction (i.e. from RSVP aggregator/Deaggregator to host). 1030 The resulting Signaling Flow is illustrated below, covering 1031 reservations for both directions: 1033 I----I I--------------I I------I I--------------I I----I 1034 I I I Aggregator/ I I MPLS I I Aggregator/ I I I 1035 IHostI I Deaggregator/I I cloudI I Deaggregator/I IHostI 1036 I I I RSVP Proxy I I I I RSVP Proxy I I I 1037 I----I I--------------I I------I I--------------I I----I 1039 ==========TE Tunnel==========> 1040 <========= TE Tunnel========== 1042 Path Path 1043 ------------> (1)-\ /-(i) <---------- 1044 Resv I I Resv 1045 <------------ (2)-/ \-(ii) ------------> 1046 Path Path 1047 <------------ (3) (iii) ------------> 1048 Resv Resv 1049 ------------> <------------ 1051 (1)(i) : Aggregator/Deaggregator/Proxy receives Path message, 1052 selects the TE tunnel, performs admission control over the TE Tunnel. 1053 (1) and (i) happens independently of each other. 1055 (2)(ii) : Aggregator/Deaggregator/Proxy generates the Resv message 1056 towards Host. (2) is triggered by (1) and (ii) is triggered by (i). 1057 Before generating this Resv message, the Aggregator/Proxy performs 1058 admission control of the corresponding reservation over the TE tunnel 1059 that will eventually carry the corresponding traffic. 1061 (3)(iii) : Aggregator/Deaggregator/Proxy generates the Path message 1062 towards Host for reservation in return direction. The actual trigger 1063 for this depends on the actual RSVP proxy solution. As an example, 1064 (3) and (iii) may simply be triggered respectively by (1) and (i). 1066 Note that the details of the signaling flow may vary slightly 1067 depending on the actual approach used for RSVP Proxy. For example, if 1068 the [L-RSVP] approach was used instead of [RSVP-PROXY], an additional 1069 PathRequest message would be needed from host to 1070 Aggregator/Deaggregator/Proxy in order to trigger the generation of 1071 the Path message for return direction. 1073 But regardless of the details of the call flow and of the actual RSVP 1074 Proxy approach, RSVP proxy may optionally be deployed in combination 1075 with RSVP Aggregation over MPLS TE Tunnels, in such a way which 1076 ensures (when used on both the Host-Aggregator and Deaggregator-Host 1077 sides, and when both end systems support RSVP) that: 1079 (i) admission control and resource reservation is performed on 1080 every segment of the end-to-end path (i.e. between source 1081 host and Aggregator, over the TE Tunnel between the 1082 Aggregator and Deaggregator which itself has been subject 1083 to admission control by MPLS TE, between Deaggregator and 1084 destination host) 1086 (ii) this is achieved in both direction 1088 (iii) RSVP signaling is localized between hosts and 1089 Aggregator/Deaggregator, which may result in significant 1090 reduction in reservation establishment delays (and in turn 1091 in post dial delay in the case where these reservations 1092 are pre-conditions for voice call establishment), 1093 particularly in the case where the MPLS TE tunnels span 1094 long distances with high propagation delays. 1096 Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels for 1097 VoIP Call Admission Control (CAC) 1099 This Appendix presents an example scenario where the mechanisms 1100 described in this document are used, in combination with other 1101 mechanisms specified by the IETF, to achieve Call Admission Control 1102 (CAC) of Voice over IP (VoIP) traffic over the packet core. 1104 The information is that Appendix is purely informational and 1105 illustrative. 1107 Consider the scenario depicted in Figure A1. VoIP Gateways GW1 and 1108 GW2 are both signaling and media gateways. They are connected to an 1109 MPLS network via edge routers PE1 and PE2, respectively. In each 1110 direction, a DSTE tunnel passes from the head-end edge router, 1111 through core network P routers, to the tail-end edge router. GW1 and 1112 GW2 are RSVP-enabled. The RSVP reservations established by GW1 and 1113 GW2 are aggregated by PE1 and PE2 over the DS-TE tunnels. For 1114 reservations going from GW1 to GW2, PE1 serves as the 1115 aggregator/head-end and PE2 serves as the de-aggregator/tail-end. For 1116 reservations going from GW2 to GW2, PE2 serves as the 1117 aggregator/head-end and PE1 serves as the de-aggregator/tail-end. 1119 To determine whether there is sufficient bandwidth in the MPLS core 1120 to complete a connection, the originating and destination GWs each 1121 send for each connection a Resource Reservation Protocol (RSVP) 1122 bandwidth request to the network PE router to which it is connected. 1123 As part of its Aggregator role, the PE router effectively performs 1124 admission control of the bandwidth request generated by the GW onto 1125 the resources of the corresponding DS-TE tunnel. 1127 In this example, in addition to behaving as Aggregator/Deaggregator, 1128 PE1 and PE2 behave as RSVP proxy. So when a PE receives a Path 1129 message from a GW, it does not propagate the Path message any further. 1130 Rather, the PE performs admission control of the bandwidth signaled 1131 in the Path message over the DSTE tunnel towards the destination. 1132 Assuming there is enough bandwidth available on that tunnel, the PE 1133 adjusts its book-keeping of remaining available bandwidth on the 1134 tunnel and generates a Resv message back towards the GW to confirm 1135 resources have been reserved over the DSTE tunnel. 1137 ,-. ,-. 1138 _.---' `---' `-+ 1139 ,-'' +------------+ : 1140 ( | | `. 1141 \ ,' CCA `. : 1142 \ ,' | | `. ; 1143 ;' +------------+ `._ 1144 ,'+ ; `. 1145 ,' -+ Application Layer' `. 1146 SIP,' `---+ | ; `.SIP 1147 ,' `------+---' `. 1148 ,' `. 1149 ,' `. 1150 ,' ,-. ,-. `. 1151 ,' ,--+ `--+--'- --'\ `._ 1152 +-`--+_____+------+ { +----+ +----+ `. +------+_____+----+ 1153 |GW1 | RSVP| |______| P |___| P |______| | RSVP|GW2 | 1154 | |-----| PE1 | { +----+ +----+ /+| PE2 |-----| | 1155 | | | |==========================>| | | | 1156 +-:--+ RTP | |<==========================| | RTP +-:--+ 1157 _|..__ +------+ { DSTE Tunnels ; +------+ __----|--. 1158 _,' \-| ./ -'._ / | 1159 | Access \ / +----+ \, |_ Access | 1160 | Network | \_ | P | | / Network | 1161 | / `| +----+ / | ' 1162 `--. ,.__,| | IP/MPLS Network / '---'- ----' 1163 '`' '' ' .._,,'`.__ _/ '---' | 1164 | '`''' | 1165 C1 C2 1167 Figure A1. Integration of SIP Resource Management, DSTE 1168 and RSVP Aggregation 1170 [SIP-RSVP] discusses how network quality of service can be made a 1171 precondition for establishment of sessions initiated by the Session 1172 Initiation Protocol (SIP). These preconditions require that the 1173 participant reserve network resources before continuing with the 1174 session. The reservation of network resources are performed through a 1175 signaling protocol such as RSVP. 1177 Our example environment relies of [SIP-RSVP] to synchronize RSVP 1178 bandwidth reservations with SIP. For example, the RSVP bandwidth 1179 requests may be integrated into the call setup flow as follows (See 1180 call setup flow diagram in Figure A2): 1182 - Caller C1 initiates a call by sending a SIP INVITE to VoIP 1183 gateway GW1, which passes the INVITE along to the call control 1184 agent (CCA). The INVITE message may contain a list of codecs 1185 that the calling phone can support. 1187 - VoIP gateway GW2, chooses a compatible codec from the list and 1188 responds with a SIP message 183 Session Progress. 1190 - When GW1 receives the SIP response message with the SDP, it 1191 determines how much bandwidth is required for the call. 1193 - GW1 sends an RSVP Path message to PE1, requesting bandwidth for 1194 the call. 1196 - GW2 also sends an RSVP Path message to PE2. 1198 - Assuming that the tunnel (from left to right) has sufficient 1199 bandwidth, PE1 responds to GW1 with a Resv message 1201 - Again assuming the tunnel (from right to left) has sufficient 1202 bandwidth, PE2 responds to GW2 with a Resv message 1204 - GW2 sends a SIP 200 OK message to GW1. 1206 - GW1 sends a SIP UPDATE message to GW2. 1208 - Upon receiving the UPDATE, GW2 sends the INVITE to the 1209 destination phone, which responds with SIP message 180 RINGING. 1211 - When (and if) the called party answers, the destination phone 1212 responds with another SIP 200 OK which completes the connection 1213 and tells the calling party that there is now reserved 1214 bandwidth in both directions so that conversation can begin. 1216 - RTP media streams in both directions pass through the DSTE 1217 tunnels as they traverse the MPLS network. 1219 IP-Phone/ IP-Phone/ 1220 TA-C1 GW1 PE1 CCA PE2 GW2 TA-C2 1221 | INVITE|(SDP1) | INVITE | INVITE | | | 1222 |---------->|-------|---------->|------------|------->| | 1223 | 100|TRYING | | | | | 1224 |<----------|-------|-----------| | | | 1225 | 183|(SDP2) | | | | | 1226 |<----------|-------|-----------|------------|--------| | 1227 | | PATH | | | PATH | | 1228 | |------>| | |<-------| | 1229 | | RESV | | | RESV | | 1230 | |<------| | |------->| | 1231 | | | UPDATE|(SDP3) | | | 1232 | |-------|-----------|------------|------->| | 1233 | | | 200 OK|(SDP4) | | | 1234 | |<------|-----------|------------|--------| INVITE | 1235 | | | | | |---------->| 1236 |180 RINGING| | 180|RINGING | |180 RINGING| 1237 |<----------|<------|-----------|------------|--------|<----------| 1238 | 200 OK | 200|OK | 200|OK | 200 OK | 1239 |<----------|<------|-----------|<-----------|--------|<----------| 1240 | | | | | | | 1241 | | | DSTE|TUNNEL | | | 1242 | RTP|MEDIA |-----------|------------| | | 1243 |===========|=======|===========|============|========|==========>| 1244 | | |-----------|------------| | | 1245 | | | | | | | 1246 | | |-----------|------------| | | 1247 |<==========|=======|===========|============|========|===========| 1248 | | |-----------|------------| | | 1249 DSTE TUNNEL 1251 Figure A2. VoIP QoS CAC using SIP with Preconditions 1253 Through the collaboration between SIP resource management, RSVP 1254 signaling, RSVP Aggregation and DS-TE as described above, we see 1255 that: 1256 a) the PE and GW collaborate to determine whether there is enough 1257 bandwidth on the tunnel between the calling and called GWs to 1258 accommodate the connection, 1259 b) the corresponding accept/reject decision is communicated to the 1260 GWs on a connection-by-connection basis, and 1261 c) the PE can optimize network resources by dynamically adjusting 1262 the bandwidth of each tunnel according to the load over that tunnel. 1263 For example, if a tunnel is operating near capacity, the network may 1264 dynamically adjust the tunnel size within a set of parameters. 1266 We note that admission Control of voice calls over the core network 1267 capacity is achieved in a hierarchical manner whereby: 1268 - DSTE tunnels are subject to Admission Control over the 1269 resources of the MPLS TE core 1270 - Voice calls are subject to CAC over the DSTE tunnel bandwidth 1271 This hierarchy is a key element in the scalability of this CAC 1272 solution for voice calls over an MPLS Core. 1274 It is also possible for the GWs to use aggregate RSVP reservations 1275 themselves instead of per-call RSVP reservations. For example, 1276 instead of setting one reservation for each call GW1 has in place 1277 towards GW2, GW1 may establish one (or a small number of) aggregate 1278 reservations as defined in [RSVP-AGG] which is used for all (or a 1279 subset of all) the calls towards GW2. This effectively provides an 1280 additional level of hierarchy whereby: 1281 - 1282 DSTE tunnels are subject to Admission Control over the 1283 resources of the MPLS TE core 1284 - Aggregate RSVP reservations (for the calls from one GW to 1285 another GW) are subject to Admission Control over the DSTE 1286 tunnels (as per the "RSVP Aggregation over TE Tunnels" 1287 procedures defined in this document) 1288 - Voice calls are subject to CAC by the GW over the aggregate 1289 reservation towards the appropriate destination GW. 1290 This pushes even further the scalability limits of this voice CAC 1291 architecture.