idnits 2.17.1 draft-lefaucheur-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 3667, Section 5.1 on line 25. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 34. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1181. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1156. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1163. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1169. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (February 2005) is 7010 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: 'RSVP' is mentioned on line 777, but not defined == Missing Reference: 'MPLS-TE' is mentioned on line 132, but not defined == Missing Reference: 'RSVP-AGG' is mentioned on line 777, but not defined == Missing Reference: 'RFC2205' is mentioned on line 460, but not defined == Unused Reference: 'RFC 3668' is defined on line 808, but no explicit reference was found in the text == Unused Reference: 'BCP-78' is defined on line 811, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) ** Obsolete normative reference: RFC 3667 (ref. 'BCP-78') (Obsoleted by RFC 3978) ** 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 draft: draft-ietf-tewg-diff-te-reqts (ref. 'DSTE-REQ') == Outdated reference: A later version (-08) exists of draft-ietf-tewg-diff-te-proto-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'LSP-HIER' -- Obsolete informational reference (is this intentional?): RFC 2751 (ref. 'RSVP-PREEMP') (Obsoleted by RFC 3181) == Outdated reference: A later version (-02) exists of draft-vasseur-ccamp-automesh-00 Summary: 15 errors (**), 0 flaws (~~), 12 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RSVP Aggregation over MPLS TE tunnels February 2005 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-lefaucheur-rsvp-dste-02.txt 16 Expires: August 2005 February 2005 18 Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels 20 Intellectual Property Rights (IPR) Statement 22 By submitting this Internet-Draft, I certify that any applicable 23 patent or other IPR claims of which I am aware have been disclosed, 24 or will be disclosed, and any of which I become aware will be 25 disclosed, in accordance with RFC 3668. 27 Status of this Memo 29 This document is an Internet-Draft and is subject to all provisions 30 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 31 author represents that any applicable patent or other IPR claims of 32 which he or she is aware have been or will be disclosed, and any of 33 which he or she become aware will be disclosed, in accordance with 34 RFC 3668. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as 39 Internet-Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 RSVP Aggregation over MPLS TE tunnels February 2005 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 This Internet-Draft will expire in August, 2005. 56 Abstract 58 This document provides specification for aggregation of RSVP end-to- 59 end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS 60 Diffserv-aware MPLS Traffic Engineering (DS-TE) Tunnels. This 61 approach is based on RFC 3175 and simply modifies the corresponding 62 procedures for operations over MPLS TE tunnels instead of aggregated 63 RSVP reservations. This approach can be used to achieve admission 64 control of a very large number of flows in a scalable manner since 65 the devices in the core of the network are unaware of the end-to-end 66 RSVP reservations and are only aware of the MPLS TE tunnels. 68 Copyright Notice 69 Copyright (C) The Internet Society. (2005) 71 Specification of Requirements 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 1. Introduction 79 The Integrated Services (Intserv) [INT-SERV] architecture provides a 80 means for the delivery of end-to-end Quality of Service (QoS) to 81 applications over heterogeneous networks. 83 [RSVP] defines the Resource reSerVation Protocol which can be used by 84 applications to request resources from the network. The network 85 responds by explicitely admitting or rejecting these RSVP requests. 86 Certain applications that have quantifiable resource requirements 87 express these requirements using Intserv parameters as defined in the 88 appropriate Intserv service specifications ([GUARANTEED], 89 [CONTROLLED]). 91 The Differentiated Services (DiffServ) architecture ([DIFFSERV]) was 92 then developed to support differentiated treatment of packets in very 93 large scale environments. In contrast to the per-flow orientation of 94 Intserv and RSVP, Diffserv networks classify packets into one of a 96 RSVP Aggregation over MPLS TE tunnels February 2005 98 small number of aggregated flows or "classes", based on the Diffserv 99 codepoint (DSCP) in the packet's IP header. At each Diffserv router, 100 packets are subjected to a "per-hop behavior" (PHB), which is invoked 101 by the DSCP. The primary benefit of Diffserv is its scalability. 102 Diffserv eliminates the need for per-flow state and per-flow 103 processing and therefore scales well to large networks. 105 However, DiffServ does not include any mechanism for communication 106 between applications and the network. Thus, as detailed in [INT-DIFF], 107 significant benefits can be achieved by using Intserv over Diffserv 108 including resource based admission control, policy based admission 109 control, assistance in traffic identification /classification and 110 traffic conditioning. As discussed in [INT-DIFF], Intserv can operate 111 over Diffserv in multiple ways. For example, the Diffserv region may 112 be statically provisioned or may be RSVP aware. When it is RSVP aware, 113 several mechanisms may be used to support dynamic provisioning and 114 topology aware admission control including aggregated RSVP 115 reservations, per flow RSVP or a bandwidth broker. The advantage of 116 using aggregated RSVP reservations is that it offers dynamic, 117 topology-aware admission control over the Diffserv region without the 118 scalability burden of per-flow reservations and the associated level 119 of RSVP signaling in the Diffserv core. [RSVP-AGGR] describes in 120 detail how to perform such aggregation of end to end RSVP 121 reservations over aggregated RSVP reservations in a Diffserv cloud. 122 It establishes an architecture where multiple end-to-end RSVP 123 reservations sharing the same ingress router (Aggregator) and the 124 same egress router (Deaggregator) at the edges of an "aggregation 125 region", can be mapped onto a single aggregate reservation within the 126 aggregation region. This considerably reduces the amount of 127 reservation state that needs to be maintained by routers within the 128 aggregation region. Furthermore, traffic belonging to aggregate 129 reservations is classified in the data path purely using Diffserv 130 marking. 132 [MPLS-TE] describes how MPLS TE Tunnels can be established via [RSVP- 133 TE] and how these tunnels can be used to carry arbitrary aggregates 134 of traffic. MPLS TE uses Constraint Based Routing to compute the path 135 for a TE tunnel. Then, CAC (Call Admission Control) is performed 136 during the establishment of TE Tunnels to ensure they are granted 137 their requested resources. 139 [DSTE-REQ] presents the Service Providers requirements for support of 140 Diff-Serv-aware MPLS Traffic Engineering (DS-TE). With DS-TE, 141 separate DS-TE tunnels can be used to carry different Diffserv 142 classes of traffic and different resource constraints can be enforced 143 for these different classes. [DSTE-PROTO] specifies RSVP-TE signaling 144 extensions as well as OSPF and ISIS extensions for support of DS-TE. 146 RSVP Aggregation over MPLS TE tunnels February 2005 148 In the rest of this document we will refer to both TE tunnels and DS- 149 TE tunnels simply as "TE tunnels". 151 TE tunnels have much in common with the aggregate RSVP reservations 152 used in [RSVP-AGGR]: 153 - a TE tunnel is subject to CAC and thus is effectively an 154 aggregate bandwidth reservation 155 - In the data plane, packet scheduling relies exclusively on 156 Diff-Serv classification and PHBs 157 - Both TE tunnels and Aggregate RSVP reservations are controlled 158 by "intelligent" devices on the edge of the "aggregation core" 159 (Head-end and Tail-end in the case of TE tunnels, Aggregator 160 and Deaggregator in the case of Aggregated RSVP reservations 161 - Both TE tunnels and Aggregate RSVP reservations are signaled 162 using the RSVP protocol (with some extensions defined in [RSVP- 163 TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE 164 tunnels). 166 This document provides a detailed specification for performing 167 aggregation of end-to-end RSVP reservations over MPLS TE tunnels 168 (which act as aggregated reservations in the core). This document 169 builds on the RSVP Aggregation procedures defined in [RSVP-AGGR], and 170 only changes those where necessary to operate over TE tunnels. With 171 [RSVP-AGGR], a lot of responsibilities (such as mapping end-to-end 172 reservations to Aggregate reservations and resizing the Aggregate 173 reservations) are assigned to the Deaggregator (which is the 174 equivalent of the Tunnel Tail-end) while with TE, the tunnels are 175 controlled by the Tunnel Head-end. Hence, the main change over the 176 RSVP Aggregations procedures defined in [RSVP-AGGR] is to modify 177 these procedures to reassign responsibilities from the Deaggregator 178 to the Aggregator (i.e. the tunnel Head-end). 180 [LSP-HIER] defines how to aggregate MPLS TE Label Switched Paths 181 (LSPs) by creating a hierarchy of such LSPs. This involves nesting of 182 end-to-end LSPs into an aggregate LSP in the core (by using the label 183 stack construct). Since end-to-end TE LSPs are themselves signaled 184 with RSVP-TE and reserve resources at every hop, this can be looked 185 at as a form of aggregation of RSVP(-TE) reservations over MPLS TE 186 Tunnels. This document capitalizes on the similarities between 187 nesting of TE LSPs over TE tunnels and RSVP aggregation over TE 188 tunnels and reuses the procedures of [LSP-HIER] wherever possible. 190 This document also builds on the "RSVP over Tunnels" concepts of RFC 191 2746 [RSVP-TUN]. It differs from that specification in the following 192 ways: 193 - Whereas RFC 2746 describes operation with IP tunnels, this 194 draft describes operation over MPLS tunnels. One consequence of 195 this difference is the need to deal with penultimate hop 196 popping (PHP). 198 RSVP Aggregation over MPLS TE tunnels February 2005 200 - MPLS-TE tunnels inherently reserve resources, whereas the 201 tunnels in RFC 2746 do not have resource reservations by 202 default. This leads to some simplifications in the current 203 draft. 204 - There is exactly one reservation per MPLS-TE tunnel, whereas 205 RFC 2746 permits many reservations per tunnel. 206 - We have assumed in the current draft that a given MPLS-TE 207 tunnel will carry reserved traffic and nothing but reserved 208 traffic, which negates the requirement of RFC 2746 to 209 distinguish reserved and non-reserved traffic traversing the 210 same tunnel by using distinct encapsulations. 211 - There may be several MPLS-TE tunnels that share common head and 212 tail end routers, with head-end policy determining which tunnel 213 is appropriate for a particular flow. This scenario does not 214 appear to be addressed in RFC 2746. 216 At the same time, this draft does have many similarities with RFC 217 2746. MPLS-TE tunnels are "type 2 tunnels" in the nomenclature of RFC 218 2746: 219 " 220 The (logical) link may be able to promise that some overall 221 level of resources is available to carry traffic, but not to 222 allocate resources specifically to individual data flows. 223 " 225 Aggregation of end-to-end RSVP reservations over TE tunnels combines 226 the benefits of [RSVP-AGGR] with the benefits of MPLS including the 227 following: 228 - dynamic, topology-aware resource-based admission control can be 229 provided to applications over any segment of the end to end 230 path including the core 231 - as per regular RSVP behavior, RSVP does not impose any burden 232 on routers where such admission control is not needed (for 233 example if the links upstream and downstream of the MPLS TE 234 core are vastly over-engineered compared to the core capacity, 235 admission control is not required on these links and RSVP need 236 not be processed on the corresponding router hops) 237 - the core scalability is not affected (relative to the standard 238 MPLS TE deployment model) since the core remains unaware of 239 end-to-end RSVP reservations and only has to maintain aggregate 240 TE tunnels and since the datapath classification and scheduling 241 in the core relies purely on Diffserv mechanism (or more 242 precisely MPLS Diffserv mechanisms as specified in [DIFF-MPLS]) 243 - the aggregate reservation (and thus the traffic from the 244 corresponding end to end reservations) can be network 245 engineered via the use of Constraint based routing (e.g. 246 affinity, optimization on different metrics) and when needed 247 can take advantage of resources on other paths than the 248 shortest path 250 RSVP Aggregation over MPLS TE tunnels February 2005 252 - the aggregate reservations (and thus the traffic from the 253 corresponding end to end reservations) can be protected against 254 failure through the use of MPLS Fast Reroute 256 This document, like [RSVP-AGGR], covers aggregation of unicast 257 sessions. Aggregation of multicast sessions is for further study. 259 1.1. Changes from previous versions 261 The significant changes from version -01 to version -02 of this draft 262 are: 263 - Alignment with RSVP operations of draft-ietf-mpls-lsp-hierarchy 264 - Addition of an appendix providing an example usage scenario for 265 information purposes 267 The significant changes from version -00 to version -01 of this draft 268 were: 269 - added discussion of the relationship to RFC 2746 [RSVP-TUN] 270 - added discussion of mapping policy at aggregator 271 - added discussion of "RSVP proxy" behavior in conjunction with 272 the aggregation scheme described here 273 - added discussion on TTL processing on Deaggregator 275 2. Definitions 277 For readability, a number of definitions from [RSVP-AGGR] as well as 278 definitions for commonly used MPLS TE terms are provided here: 280 Aggregator This is the router at the ingress edge of the 281 aggregation region (with respect to the end to end 282 RSVP reservation) and behaving in accordance with 283 [RSVP-AGG]. In this document, it is also the TE Tunnel 284 Head-end. 286 Deaggregator This is the router at the egress edge of the 287 aggregation region (with respect to the end to end 288 RSVP reservation) and behaving in accordance with 289 [RSVP-AGG]. In this document, it is also the TE Tunnel 290 Tail-end 292 E2E End to end 294 Head-end 295 This is the Label Switch Router responsible for 296 establishing, maintaining and tearing-off a given TE 297 tunnel. 299 Tail-end 300 This is the Label Switch Router responsible for 301 terminating a given TE tunnel 303 RSVP Aggregation over MPLS TE tunnels February 2005 305 Transit LSR This is a Label Switch router that is on the path of a 306 given TE tunnel and is neither the Head-end nor the 307 Tail-end 309 3. Operations of RSVP Aggregation over TE with pre-established Tunnels 311 [RSVP-AGG] supports operations both in the case where aggregate RSVP 312 reservations are pre-established and in the case where Aggregating 313 and De-aggregating routers have to dynamically discover each other 314 and dynamically establish the necessary Aggregated RSVP reservations. 316 Similarly, RSVP Aggregation over TE tunnels could operate both in the 317 case where the TE tunnels are pre-established and in the case where 318 the tunnels need to be dynamically established. 320 In this document we provide a detailed description of the procedures 321 in the case where TE tunnels are already established. These 322 procedures are based on those defined in [LSP-HIER]. 324 Pre-establishment of the TE tunnels may be triggered by any 325 mechanisms including for example manual configuration or automatic 326 establishment of a TE tunnel mesh through dynamic discovery of TE 327 Mesh membership as allowed in [AUTOMESH]. 329 Procedures in the case of dynamically established TE tunnels are for 330 further studies. 332 3.1. Reference Model 334 I----I I----I 335 H--I R I\ I-----I I------I /I R I--H 336 H--I I\\I I I---I I I//I I--H 337 I----I \I He/ I I T I I Te/ I/ I----I 338 I Agg I=======================I Deag I 339 /I I I I I I\ 340 H--------//I I I---I I I\\--------H 341 H--------/ I-----I I------I \--------H 343 H = Host requesting end-to-end RSVP reservations 344 R = RSVP router 345 He/Agg = TE tunnel Head-end/Aggregator 346 Te/Deag = TE tunnel Tail-end/Deaggregator 347 T = Transit LSR 349 -- = E2E RSVP reservation 350 == = TE Tunnel 352 RSVP Aggregation over MPLS TE tunnels February 2005 354 3.2. Receipt of E2E Path message By the Aggregator 356 The first event is the arrival of the E2E Path message at the 357 Aggregator. Standard RSVP procedures are followed for this path 358 message (including update of the PHOP field to a local Aggregator 359 address) augmented with the extensions documented in this section. 361 The Aggregator first attempts to map the E2E reservation onto a TE 362 tunnel. This decision is made in accordance with routing information 363 as well as any local policy information that may be available at the 364 Aggregator. Examples of such policies appear in the following 365 paragraphs. Just for illustration purposes, among many other criteria, 366 such mapping policies might take into account the Intserv service 367 type, the Application Identity [RSVP-APPID] and/or the signaled 368 preemption [RSVP-PREEMP] of the E2E reservation (for example, the 369 aggregator may take into account the E2E reservations RSVP preemption 370 priority and the MPLS TE Tunnel set-up and/or hold priorities when 371 mapping the E2E reservation onto an MPLS TE tunnel). 373 There are situations where the Aggregator is able to make a final 374 mapping decision. That would be the case, for example, if there is a 375 single TE tunnel towards the destination and if the policy is to map 376 any E2E RSVP reservation onto TE Tunnels. 378 There are situations where the Aggregator is not able to make a final 379 determination. That would be the case, for example, if routing 380 identifies two DS-TE tunnels towards the destination, one belonging 381 to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to 382 map Intserv Guaranteed Services reservations to a Class-Type 1 tunnel 383 and Intserv Controlled Load reservations to a Class-Type 0 tunnel, 384 and if the E2E RSVP Path message advertises both Guaranteed Service 385 and Controlled Load. 387 Whether final or tentative, the Aggregator makes a mapping decision 388 and selects a TE tunnel. Before forwarding the E2E Path message 389 towards the receiver, the Aggregator should update the ADSPEC inside 390 the E2E Path message to reflect the impact of the MPLS TE cloud onto 391 the QoS achievable by the E2E flow. This update is a local matter and 392 may be based on configured information, on information available in 393 the MPLS TE topology database, on the current TE tunnel path, on 394 information collected via RSVP-TE signaling, or combinations of those. 396 The Aggregator then forwards the E2E Path message. In accordance with 397 [LSP-HIER], the E2E Path message is: 398 - sent with an IF_ID RSVP_HOP object instead of an RSVP_HOP 399 object. The data interface identification identifies the TE 400 Tunnel 402 RSVP Aggregation over MPLS TE tunnels February 2005 404 - addressed directly to the Deaggregator. The destination address 405 of the E2E Path message is set to the Deaggregator address and 406 the Router Alert is not set. Thus, the E2E Path message will 407 not be visible to Transit routers along the path of the TE 408 tunnel. Thus, in contrast to the procedures of [RSVP-AGGR], the 409 IP Protocol number need not be modified to "RSVP-E2E-IGNORE"; 410 it is left as is (indicating "RSVP"). 412 3.3. Handling of E2E Path message By Transit LSRs 414 Since the E2E Path message is addressed directly to the Deaggreagtor 415 and does not have Router Alert set, it is hidden from all transit 416 LSRs. 418 3.4. Receipt of E2E Path Message by Deaggregator 420 On receipt of the E2E Path message addressed to it, the Deaggregator 421 will notice that the IP Protocol number is set to "RSVP" and will 422 thus perform RSVP processing of the E2E Path message. 424 As with [LSP-HIER], the IP TTL vs. RSVP TTL check must not be made. 425 The Deaggregator is informed that this check must not be made because 426 of the presence of the IF_ID RSVP HOP object. As with [LSP-HIER], the 427 following checks should be made by the receiver Y of the IF_ID 428 RSVP_HOP object: 430 1. Make sure that the data interface identified in the IF_ID 431 RSVP_HOP object actually terminates on Y. 432 2. Find the "other end" of the above data interface, say X. 433 Make sure that the PHOP in the IF_ID RSVP_HOP object is a 434 control channel address that belongs to the same node as X. 436 3.5. Handling of E2E Resv Message by Deaggregator 438 The Deaggregator follows standard RSVP procedures on receipt of the 439 E2E Resv message. This includes performing admission control for the 440 segment downstream of the Deaggregator and forwarding the E2E Resv 441 message to the PHOP signaled earlier in the E2E Path message and 442 which identifies the Aggregator. 444 3.6. Handling of E2E Resv Message by the Aggregator 446 The Aggregator is responsible for ensuring that there is sufficient 447 bandwidth available and reserved over the appropriate TE tunnel to 448 the Deaggregator for the E2E reservation. 450 RSVP Aggregation over MPLS TE tunnels February 2005 452 On receipt of the E2E Resv message, the Aggregator first performs the 453 final mapping onto the final TE tunnels (if it was only a tentative 454 mapping). If needed the Aggregator updates the ADSPEC and immediately 455 generates an E2E Path refresh in order to provide the accurate ADSPEC 456 information to the receiver as soon as possible. 458 The aggregator then calculates the size of the resource request using 459 standard RSVP procedures. That is, it follows the procedures in 460 [RFC2205] to determine the resource requirements from the Sender 461 Tspec and the Flowspec contained in the Resv. It them compares the 462 resource requests with the available resources of the selected TE 463 tunnel. 465 If sufficient bandwidth is available on the final TE tunnel, the 466 Aggregator updates its internal understanding of how much of the TE 467 Tunnel is in use and forwards the E2E Resv messages to the 468 corresponding PHOP. 470 As noted in [RSVP-AGGR], a range of policies may be applied to the 471 re-sizing of the aggregate reservation (in this case, the TE tunnel.) 472 For example, the policy may be that the reserved bandwidth of the 473 tunnel can only be changed by configuration. More dynamic policies 474 are also possible, whereby the aggregator may attempt to increase the 475 reserved bandwidth of the tunnel in response to the amount of 476 allocated bandwidth that has been used by E2E reservations. 477 Furthermore, to avoid the delay associated with the increase of the 478 Tunnel size, the Aggregator may attempt to anticipate the increases 479 in demand and adjust the TE tunnel size ahead of actual needs by E2E 480 reservations. 482 If sufficient bandwidth is not available on the final TE Tunnel, the 483 Aggregator must follow the normal RSVP procedure for a reservation 484 being placed with insufficient bandwidth to support this reservation. 485 That is, the reservation is not installed and a ResvError is sent 486 back towards the receiver. 488 3.7. Removal of E2E reservations 490 E2E reservations are removed in the usual way via PathTear, ResvTear, 491 timeout, or as the result of an error condition. When a reservation 492 is removed, the Aggregator updates its local view of the 493 resources available on the corresponding TE tunnel accordingly. 495 3.8. Removal of TE Tunnel 497 Should a TE Tunnel go away (presumably due to a configuration change, 498 route change, or policy event), the aggregator behaves much like a 499 conventional RSVP router in the face of a link failure. That is, it 500 may try to forward the Path messages onto another tunnel, if routing 502 RSVP Aggregation over MPLS TE tunnels February 2005 504 and policy permit, or it may send Path_Error messages to the sender 505 if no suitable tunnel exists. In case the Path messages are forwarded 506 onto another tunnel which terminates on a different Deaggregator, or 507 the reservation is torn-down via Path Error messages, the reservation 508 state established on the router acting as the Deaggregator before the 509 TE tunnel went away, will time out since it will no longer be 510 refreshed. 512 3.9. Example Signaling Flow 514 Aggregator Deaggregator 516 (*) 517 RSVP-TE Path 518 =========================> 520 RSVP-TE Resv 521 <========================= 522 (**) 524 E2E Path 525 --------------> 526 (1) 527 E2E Path 528 -------------------------------> 529 (2) 530 E2E Path 531 -----------> 533 E2E Resv 534 <----------- 535 (3) 536 E2E Resv 537 <----------------------------- 538 (4) 539 E2E Resv 540 <------------- 542 (*) Aggregator is triggered to pre-establish the TE Tunnel(s) 544 (**) TE Tunnel(s) are pre-established 546 RSVP Aggregation over MPLS TE tunnels February 2005 548 (1) Aggregator tentatively selects the TE tunnel and forwards 549 E2E path to Deaggregator 551 (2) Deaggregator forwards the E2E Path towards receiver 553 (3) Deaggregator forwards the E2E Resv to the Aggregator 555 (4) Aggregator selects final TE tunnel, check there is 556 sufficient bandwidth on TE tunnel and forwards E2E Resv to 557 PHOP 559 4. IPv4 and IPv6 Applicability 561 The procedures defined in this document are applicable to all the 562 following cases: 564 (1) Aggregation of E2E IPv4 RSVP reservations over IPv4 TE 565 Tunnels 566 (2) Aggregation of E2E IPv6 RSVP reservations over IPv6 TE 567 Tunnels 568 (3) Aggregation of E2E IPv6 RSVP reservations over IPv4 TE 569 tunnels, provided a mechanism such as [6PE] is used by the 570 Aggregator and Deaggregator for routing of IPv6 traffic over 571 an IPv4 MPLS core, 572 (4) Aggregation of E2E IPv4 RSVP reservations over IPv6 TE 573 tunnels, provided a mechanism is used by the Aggregator and 574 Deaggregator for routing IPv4 traffic over IPv6 MPLS. 576 5. E2E Reservations Applicability 578 The procedures defined in this document are applicable to many types 579 of E2E RSVP reservations including the following cases: 580 (1) the E2E RSVP reservation is a per-flow reservation where the 581 flow is characterized by the usual 5-tuple 582 (2) the E2E reservation is an aggregate reservation for multiple 583 flows as described in [RSVP-AGG] where the set of flows is 584 characterized by the 586 (3) the E2E reservation is a reservation for an IPSec protected 587 flow. For example, where the flow is characterized by the 588 as described in 589 [RSVP-IPSEC] 590 (4) the E2E reservation is an aggregate reservation for multiple 591 flows and where the set of flows are protected by IPSec 592 (5) the E2E RSVP reservation is itself an RSVP-TE reservation 593 for an E2E TE tunnel, so that LSP Hierarchy is achieved 594 [LSP-HIER] 596 RSVP Aggregation over MPLS TE tunnels February 2005 598 6. Example Deployment Scenarios 600 6.1. Voice and Video Reservations Scenario 602 An example application of the procedures specified in this document 603 is admission control of voice and video in environments with very 604 high numbers of hosts. In the example illustrated below, hosts 605 generate end-to-end per-flow reservations for each of their video 606 streams associated with a video-conference, each of their audio 607 streams associated with a video-conference and each of their voice 608 calls. These reservations are aggregated over MPLS DS-TE tunnels over 609 the packet core. The mapping policy defined by the user maybe that 610 all the reservations for audio and voice streams are mapped onto DS- 611 TE tunnels of Class-Type 1 while reservations for video streams are 612 mapped onto DS-TE tunnels of Class-Type 0. 614 ------ ------ 615 I H I# ------- -------- #I H I 616 I I\#I I ----- I I#/I I 617 -----I \I Agg I I T I I Deag I/ ------ 618 I I==========================I I 619 ------ /I I::::::::::I I:::::::::::I I\ ------ 620 I H I/#I I ----- I I#\I H I 621 I I# ------- -------- #I I 622 ------ ------ 624 H = Host 625 Agg = Aggregator (TE Tunnel Head-end) 626 Deagg = Deaggregator (TE Tunnel Tail-end) 627 T = Transit LSR 629 / = E2E RSVP reservation for a Voice flow 630 # = E2E RSVP reservation for a Video flow 631 == = DS-TE Tunnel from Class-Type 1 632 :: = DS-TE Tunnel from Class-Type 0 634 6.2. PSTN/3G Voice Trunking Scenario 636 An example application of the procedures specified in this document 637 is voice call admission control in large scale telephony trunking 638 environments. A Trunk VoIP Gateway may generate one aggregate RSVP 639 reservation for all the calls in place towards another given remote 640 Trunk VoIP Gateway (with resizing of this aggregate reservation in a 641 step function depending on current number of calls). In turn, these 642 reservations may be aggregated over MPLS TE tunnels over the packet 644 RSVP Aggregation over MPLS TE tunnels February 2005 646 core so that tunnel Head-ends act as Aggregators and perform 647 admission control of Trunk Gateway reservations into MPLS TE Tunnels. 648 The MPLS TE tunnels may be protected by MPLS Fast Reroute. 649 This scenario is illustrated below: 651 ------ ------ 652 I GW I\ ------- -------- /I GW I 653 I I\\I I ----- I I//I I 654 -----I \I Agg I I T I I Deag I/ ------ 655 I I==========================I I 656 ------ /I I I I I I\ ------ 657 I GW I//I I ----- I I\\I GW I 658 I I/ ------- -------- \I I 659 ------ ------ 661 GW = VoIP Gateway 662 Agg = Aggregator (TE Tunnel Head-end) 663 Deagg = Deaggregator (TE Tunnel Tail-end) 664 T = Transit LSR 666 / = Aggregate Gateway to Gateway E2E RSVP reservation 667 == = TE Tunnel 669 7. Optional Use of RSVP Proxy on RSVP Aggregator 671 A number of approaches ([RSVP-PROXY], [L-RSVP]) have been, or are 672 being, discussed in the IETF in order to allow a network node to 673 behave as an RSVP proxy which: 674 - originates the Resv Message (in response to the Path message) on 675 behalf of the destination node 676 - originates the Path message (in response to some trigger) on 677 behalf of the source node. 679 We observe that such approaches may optionally be used in conjunction 680 with the aggregation of RSVP reservations over MPLS TE tunnels as 681 specified in this document. In particular, we consider the case where 682 the RSVP Aggregator/Deaggregator also behaves as the RSVP proxy. 684 As discussed in [RSVP-PROXY]: 686 "The proxy functionality does not imply merely generating a single 687 Resv message. Proxying the Resv involves installing state in the node 688 doing the proxy i.e. the proxying node should act as if it had 689 received a Resv from the true endpoint. This involves reserving 690 resources (if required), sending periodic refreshes of the Resv 691 message and tearing down the reservation if the Path is torn down." 693 RSVP Aggregation over MPLS TE tunnels February 2005 695 Hence, when behaving as the RSVP Proxy, the RSVP Aggregator may 696 effectively perform resource reservation over the MPLS TE Tunnel (and 697 hence over the whole segment between the RSVP Aggregator and the RSVP 698 Deaggregator) even if the RSVP signaling only takes place upstream of 699 the MPLS TE Tunnel (i.e. between the host and the RSVP aggregator). 701 Also, the RSVP Proxy can generate the Path message on behalf of the 702 remote source host in order to achieve reservation in the return 703 direction (i.e. from RSVP aggregator/Deaggregator to host). 705 The resulting Signaling Flow is illustrated below, covering 706 reservations for both directions: 708 I----I I--------------I I------I I--------------I I----I 709 I I I Aggregator/ I I MPLS I I Aggregator/ I I I 710 IHostI I Deaggregator/I I cloudI I Deaggregator/I IHostI 711 I I I RSVP Proxy I I I I RSVP Proxy I I I 712 I----I I--------------I I------I I--------------I I----I 714 ==========TE Tunnel==========> 715 <========= TE Tunnel========== 717 Path Path 718 ------------> (1)-\ (i) <---------- 719 Resv I Resv 720 <------------ (2) -/ (ii) ------------> 721 Path Path 722 <------------ (3) (iii) ------------> 723 Resv Resv 724 ------------> <------------ 726 (1)(i) : Aggregator/Deaggregator/Proxy receives Path message, 727 selects the TE tunnel, performs admission control over the TE Tunnel. 728 (1) and (i) happens independently of each other. 730 (2)(ii) : Aggregator/Deaggregator/Proxy generates the Resv message 731 towards Host. (2) is triggered by (1) and (ii) is triggered by (i). 732 Before generating this Resv message, the Aggregator/Proxy performs 733 admission control of the corresponding reservation over the TE tunnel 734 that will eventually carry the corresponding traffic. 736 (3)(iii) : Aggregator/Deaggregator/Proxy generates the Path message 737 towards Host for reservation in return direction. The actual trigger 738 for this depends on the actual RSVP proxy solution. As an example, 739 (3) and (iii) may simply be triggered respectively by (1) and (i). 741 Note that the details of the signaling flow may vary slightly 742 depending on the actual approach used for RSVP Proxy. For example, if 744 RSVP Aggregation over MPLS TE tunnels February 2005 746 the [L-RSVP] approach was used instead of [RSVP-PROXY], an additional 747 PathRequest message would be needed from host to 748 Aggregator/Deaggregator/Proxy in order to trigger the generation of 749 the Path message for return direction. 751 But regardless of the details of the call flow and of the actual RSVP 752 Proxy approach, RSVP proxy may optionally be deployed in combination 753 with RSVP Aggregation over MPLS TE Tunnels, in such a way which 754 ensures (when used on both the Host-Aggregator and Deaggregator-Host 755 sides, and when both end systems support RSVP) that: 757 (i) admission control and resource reservation is performed on 758 every segment of the end-to-end path (i.e. between source 759 host and Aggregator, over the TE Tunnel between the 760 Aggregator and Deaggregator which itself has been subject 761 to admission control by MPLS TE, between Deaggregator and 762 destination host) 764 (ii) this is achieved in both direction 766 (iii) RSVP signaling is localized between hosts and 767 Aggregator/Deaggregator, which may result in significant 768 reduction in reservation establishment delays (and in turn 769 in post dial delay in the case where these reservations 770 are pre-conditions for voice call establishment), 771 particularly in the case where the MPLS TE tunnels span 772 long distances with high propagation delays. 774 8. Security Considerations 776 The security issues inherent to the use of RSVP, RSVP Aggregation and 777 MPLS TE apply. Those can be addressed as discussed in [RSVP], [RSVP- 778 AGG] and [RSVP-TE]. 780 In addition, in the case where the Aggregators dynamically resize the 781 TE tunnels based on the current level of reservation, there are risks 782 that the TE tunnels used for RSVP aggregation hog resources in the 783 core which could prevent other TE Tunnels from being established. 784 There are also potential risks that such resizing results in 785 significant computation and signaling as well as churn on tunnel 786 paths. Such risks can be mitigated by configuration options allowing 787 control of TE tunnel dynamic resizing (maximum Te tunnel size, 788 maximum resizing frequency,...) and/or possibly by the use of TE 789 preemption. 791 9. IANA Considerations 793 This document has no actions for IANA. 795 RSVP Aggregation over MPLS TE tunnels February 2005 797 10. Acknowledgments 799 This document builds on the [RSVP-AGGR], [RSVP-TUN] and [LSP-HIER] 800 specifications. Also, we would like to thank Tom Phelan and John 801 Drake for their input into this document. 803 11. Normative References 805 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 806 Requirement Levels, RFC2119, March 1997. 808 [RFC 3668] S. Bradner, Intellectual Property Rights in IETF 809 Technology, RFC 3668, February 2004. 811 [BCP-78], S. Bradner, IETF Rights in Contributions, RFC3667, February 812 2004. 814 [INT-SERV] Braden, R., Clark, D. and S. Shenker, Integrated Services 815 in the Internet Architecture: an Overview, RFC 1633, June 1994. 817 [GUARANTEED] Shenker et al., Specification of Guaranteed Quality of 818 Service, RFC2212 820 [CONTROLLED] Wroclawski, Specification of the Controlled-Load Network 821 Element Service, RFC2211 823 [DIFFSERV] Blake et al., An Architecture for Differentiated Services, 824 RFC 2475 826 [INT-DIFF] A Framework for Integrated Services Operation over 827 Diffserv Networks, RFC 2998, November 2000. 829 [RSVP-AGGR] Baker et al, Aggregation of RSVP for IPv4 and IPv6 830 Reservations, RFC 3175, September 2001. 832 [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- 833 aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-reqts-07.txt, 834 February 2003. 836 [DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of 837 Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te- 838 proto-04.txt, June 2003 840 [LSP-HIER] Kompella et al, LSP Hierarchy with Generalized MPLS TE, 841 work in progress 843 RSVP Aggregation over MPLS TE tunnels February 2005 845 12. Informative References 847 [RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels, 848 RFC 3209, December 2001. 850 [DIFF-MPLS] Le Faucheur et al, MPLS Support of Diff-Serv, RFC3270, 851 May 2002. 853 [6PE] De Clercq et al, Connecting IPv6 Islands over IPv4 MPLS using 854 IPv6 Provider Edge Routers (6PE), work in progress 856 [RSVP-IPSEC] Berger et al, RSVP Extensions for IPSEC Data Flows, RFC 857 2207 859 [RSVP-TUN] Terzis et al., RSVP Operation Over IP Tunnels, RFC 2746, 860 January 2000 862 [RSVP-PREEMP] Herzog, Signaled Preemption Priority Policy Element, 863 RFC 2751 865 [L-RSVP] Manner et al., Localized RSVP, draft-manner-lrsvp-04.txt, 866 work in progress. 868 [RSVP-PROXY] Gai et al., RSVP Proxy, draft-ietf-rsvp-proxy-03.txt 869 (expired), work in progress. 871 [RSVP-APPID] Bernet et al., Application and Sub Application Identity 872 Policy Element for Use with RSVP, RFC 2872. 874 [AUTOMESH] Vasseur and Leroux, Routing extensions for discovery of 875 Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering 876 (TE) mesh membership, draft-vasseur-ccamp-automesh-00.txt, work in 877 progress. 879 [SIP-RSVP] Camarillo, Integration of Resource Management and Session 880 Initiation Protocol (SIP), RFC 3312 882 13. Authors Address: 884 Francois Le Faucheur 885 Cisco Systems, Inc. 886 Village d'Entreprise Green Side - Batiment T3 887 400, Avenue de Roumanille 888 06410 Biot Sophia-Antipolis 890 RSVP Aggregation over MPLS TE tunnels February 2005 892 France 893 Email: flefauch@cisco.com 895 Michael DiBiasio 896 Cisco Systems, Inc. 897 300 Beaver Brook Road 898 Boxborough, MA 01719 899 USA 900 Email: dibiasio@cisco.com 902 Bruce Davie 903 Cisco Systems, Inc. 904 300 Beaver Brook Road 905 Boxborough, MA 01719 906 USA 907 Email: bdavie@cisco.com 909 Christou Christou 910 Booz Allen Hamilton 911 8283 Greensboro Drive 912 McLean, VA 22102 913 USA 914 Email: christou_chris@bah.com 916 Michael Davenport 917 Booz Allen Hamilton 918 8283 Greensboro Drive 919 McLean, VA 22102 920 USA 921 Email: davenport_michael@bah.com 923 Jerry Ash 924 AT&T 925 200 Laurel Avenue 926 Middletown, NJ 07748, USA 927 USA 928 Email: gash@att.com 930 Bur Goode 931 AT&T 932 200 Laurel Avenue 933 Middletown, NJ 07748, USA 934 USA 936 RSVP Aggregation over MPLS TE tunnels February 2005 938 Email: bgoode@att.com 940 Appendix A - Example Usage of RSVP Aggregation over DSTE Tunnels for 941 VoIP Call Admission Control (CAC) 943 This Appendix presents an example scenario where the mechanisms 944 described in this document are used, in combination with other 945 mechanisms specified by the IETF, to achieve Call Admission Control 946 of Voice over IP (VoIP) traffic over the packet core. 948 The information is that Appendix is purely informational and 949 illustrative. 951 Consider the scenario depicted in Figure A1. VoIP Gateways GW1 and 952 GW2 are both signaling and media gateways. They are connected to an 953 MPLS network via edge routers PE1 and PE2, respectively. In each 954 direction, a DSTE tunnel passes from the head-end edge router, 955 through core network P routers, to the tail-end edge router. GW1 and 956 GW2 are RSVP-enabled. The RSVP reservations established by GW1 and 957 GW2 are aggregated by PE1 and PE2 over the DS-TE tunnels. For 958 reservations going from GW1 to GW2, PE1 serves as the 959 aggregator/head-end and PE2 serves as the de-aggregator/tail-end. For 960 reservations going from GW2 to GW2, PE2 serves as the 961 aggregator/head-end and PE1 serves as the de-aggregator/tail-end. 963 To determine whether there is sufficient bandwidth in the MPLS core 964 to complete a connection, the originating and destination GWs each 965 send for each connection a Resource Reservation Protocol (RSVP) 966 bandwidth request to the network PE router to which it is connected. 967 The bandwidth request takes into account VoIP header compression, 968 where applicable. As part of its Aggregator role, the PE router 969 effectively performs admission control of the bandwidth request 970 generated by the GW onto the resources of the corresponding DS-TE 971 tunnel. 973 In this example, in addition to behaving as Aggregator/Deaggregator, 974 PE1 and PE2 behave as RSVP proxy. So when a PE receives a Path 975 message from a GW, it does not propagate the Path message any further. 976 Rather, the PE performs admission control of the bandwidth signaled 977 in the Path message over the DSTE tunnel towards the destination. 978 Assuming there is enough bandwidth available on that tunnel, the PE 979 adjusts its book-keeping of remaining available bandwidth on the 980 tunnel and generates a Resv message back towards the GW to confirm 981 resources have been reserved over the DSTE tunnel. 983 RSVP Aggregation over MPLS TE tunnels February 2005 985 ,-. ,-. 986 _.---' `---' `-+ 987 ,-'' +------------+ : 988 ( | | `. 989 \ ,' CCA `. : 990 \ ,' | | `. ; 991 ;' +------------+ `._ 992 ,'+ ; `. 993 ,' -+ Application Layer' `. 994 SIP,' `---+ | ; `.SIP 995 ,' `------+---' `. 996 ,' `. 997 ,' `. 998 ,' ,-. ,-. `. 999 ,' ,--+ `--+--'- --'\ `._ 1000 +-`--+_____+------+ { +----+ +----+ `. +------+_____+----+ 1001 |GW1 | RSVP| |______| P |___| P |______| | RSVP|GW2 | 1002 | |-----| PE1 | { +----+ +----+ /+| PE2 |-----| | 1003 | | | |==========================>| | | | 1004 +-:--+ RTP | |<==========================| | RTP +-:--+ 1005 _|..__ +------+ { DSTE Tunnels ; +------+ __----|--. 1006 _,' \-| ./ -'._ / | 1007 | Access \ / +----+ \, |_ Access | 1008 | Network | \_ | P | | / Network | 1009 | / `| +----+ / | ' 1010 `--. ,.__,| | IP/MPLS Network / '---'- ----' 1011 '`' '' ' .._,,'`.__ _/ '---' | 1012 | '`''' | 1013 C1 C2 1015 Figure A1. Integration of SIP Resource Management, DSTE 1016 and RSVP Aggregation 1018 [SIP-RSVP] discusses how network quality of service can be made a 1019 precondition for establishment of sessions initiated by the Session 1020 Initiation Protocol (SIP). These preconditions require that the 1021 participant reserve network resources before continuing with the 1022 session. The reservation of network resources are performed through a 1023 signaling protocol such as RSVP. 1025 Our example environment relies of [SIP-RSVP] to synchronize RSVP 1026 bandwidth reservations with SIP. For example, the RSVP bandwidth 1027 requests may be integrated into the call setup flow as follows (See 1028 call setup flow diagram in Figure A2): 1030 - Caller C1 initiates a call by sending a SIP INVITE to VoIP 1031 gateway GW1, which passes the INVITE along to the call control 1033 RSVP Aggregation over MPLS TE tunnels February 2005 1035 agent (CCA). The INVITE message may contain a list of codecs 1036 that the calling phone can support. 1038 - VoIP gateway GW2, chooses a compatible codec from the list and 1039 responds with a SIP message 183 Session Progress. 1041 - When GW1 receives the SIP response message and learns the codec 1042 to be used, it knows how much bandwidth is required for the 1043 call. 1045 - GW1 sends an RSVP Path message to PE1, requesting bandwidth for 1046 the call. 1048 - GW2 also sends an RSVP Path message to PE2. 1050 - Assuming that the tunnel (from left to right) has sufficient 1051 bandwidth, PE1 responds to GW1 with a Resv message 1053 - Again assuming the tunnel (from right to left) has sufficient 1054 bandwidth, PE2 responds to GW2 with a Resv message 1056 - GW2 sends a SIP 200 OK message to GW1. 1058 - GW1 sends a SIP UPDATE message to GW2. 1060 - Upon receiving the UPDATE, GW2 sends the INVITE to the 1061 destination phone, which responds with SIP message 180 RINGING. 1063 - When (and if) the called party answers, the destination phone 1064 responds with another SIP 200 OK which completes the connection 1065 and tells the calling party that there is now reserved 1066 bandwidth in both directions so that conversation can begin. 1068 - RTP media streams in both directions pass through the DSTE 1069 tunnels as they traverse the MPLS network. 1071 RSVP Aggregation over MPLS TE tunnels February 2005 1073 IP-Phone/ IP-Phone/ 1074 TA-C1 GW1 PE1 CCA PE2 GW2 TA-C2 1075 | INVITE|(SDP1) | INVITE | INVITE | | | 1076 |---------->|-------|---------->|------------|------->| | 1077 | 100|TRYING | | | | | 1078 |<----------|-------|-----------| | | | 1079 | 183|(SDP2) | | | | | 1080 |<----------|-------|-----------|------------|--------| | 1081 | | PATH | | | PATH | | 1082 | |------>| | |<-------| | 1083 | | RESV | | | RESV | | 1084 | |<------| | |------->| | 1085 | | | UPDATE|(SDP3) | | | 1086 | |-------|-----------|------------|------->| | 1087 | | | 200 OK|(SDP4) | | | 1088 | |<------|-----------|------------|--------| INVITE | 1089 | | | | | |---------->| 1090 |180 RINGING| | 180|RINGING | |180 RINGING| 1091 |<----------|<------|-----------|------------|--------|<----------| 1092 | 200 OK | 200|OK | 200|OK | 200 OK | 1093 |<----------|<------|-----------|<-----------|--------|<----------| 1094 | | | | | | | 1095 | | | DSTE|TUNNEL | | | 1096 | RTP|MEDIA |-----------|------------| | | 1097 |===========|=======|===========|============|========|==========>| 1098 | | |-----------|------------| | | 1099 | | | | | | | 1100 | | |-----------|------------| | | 1101 |<==========|=======|===========|============|========|===========| 1102 | | |-----------|------------| | | 1103 DSTE TUNNEL 1105 Figure A2. VoIP QoS CAC using SIP with Preconditions 1107 Through the collaboration between SIP resource management, RSVP 1108 signaling, RSVP Aggregation and DS-TE as described above, we see 1109 that: 1110 a) the PE and GW collaborate to determine whether there is enough 1111 bandwidth on the tunnel between the calling and called GWs to 1112 accommodate the connection, 1113 b) the corresponding accept/reject decision is communicated to the 1114 GWs on a connection-by-connection basis, and 1115 c) the PE can optimize network resources by dynamically adjusting 1116 the bandwidth of each tunnel according to the load over that tunnel. 1117 For example, if a tunnel is operating near capacity, the network may 1118 dynamically adjust the tunnel size within a set of parameters. 1120 RSVP Aggregation over MPLS TE tunnels February 2005 1122 We note that admission Control of voice calls over the core network 1123 capacity is achieved in a hierarchical manner whereby: 1124 - DSTE tunnels are subject to CAC over the resources of the MPLS 1125 TE core 1126 - Voice calls are subject to CAC over the DSTE tunnel bandwidth 1127 This hierarchy is a key element in the scalability of this CAC 1128 solution for voice calls over an MPLS Core. 1130 It is also possible for the GWs to use aggregate RSVP reservations 1131 themselves instead of per-call RSVP reservations. For example, 1132 instead of setting one reservation for each call GW1 has in place 1133 towards GW2, GW1 may establish one (or a small number of) aggregate 1134 reservations as defined in [RSVP-AGGR] which is used for all (or a 1135 subset of all) the calls towards GW2. This effectively provides an 1136 additional level of hierarchy whereby: 1137 - 1138 DSTE tunnels are subject to CAC over the resources of the MPLS 1139 TE core 1140 - Aggregate RSVP reservations from GW to GW are subject to CAC 1141 over the DSTE tunnels (as per the "RSVP Aggregation over TE 1142 Tunnels" procedures defined in this document) 1143 - Voice calls are subject to CAC by the GW over the aggregate 1144 reservation towards the appropriate destination GW. 1145 This pushes even further the scalability limits of this voice CAC 1146 architecture. 1148 Intellectual Property Statement 1149 The IETF takes no position regarding the validity or scope of any 1150 Intellectual Property Rights or other rights that might be claimed to 1151 pertain to the implementation or use of the technology described in 1152 this document or the extent to which any license under such rights 1153 might or might not be available; nor does it represent that it has 1154 made any independent effort to identify any such rights. Information 1155 on the procedures with respect to rights in RFC documents can be 1156 found in BCP 78 and BCP 79. 1158 Copies of IPR disclosures made to the IETF Secretariat and any 1159 assurances of licenses to be made available, or the result of an 1160 attempt made to obtain a general license or permission for the use of 1161 such proprietary rights by implementers or users of this 1162 specification can be obtained from the IETF on-line IPR repository at 1163 http://www.ietf.org/ipr. 1165 The IETF invites any interested party to bring to its attention any 1166 copyrights, patents or patent applications, or other proprietary 1167 rights that may cover technology that may be required to implement 1168 this standard. Please address the information to the IETF at 1169 ietf-ipr@ietf.org. 1171 RSVP Aggregation over MPLS TE tunnels February 2005 1173 Disclaimer of Validity 1175 This document and the information contained herein are provided on an 1176 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1177 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1178 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1179 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1180 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1181 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1183 Copyright Statement 1185 Copyright (C) The Internet Society (2005). This document is subject 1186 to the rights, licenses and restrictions contained in BCP 78, and 1187 except as set forth therein, the authors retain all their rights. 1189 Acknowledgment 1191 Funding for the RFC Editor function is currently provided by the 1192 Internet Society.