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