idnits 2.17.1 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft K. Kumaki, Ed. 4 Intended Status: Informational KDDI Corporation 5 Created: December 28, 2009 R. Zhang 6 Expires: June 27, 2010 BT 7 Y. Kamite 8 NTT Communications 10 Requirements for supporting Customer RSVP and RSVP-TE over a 11 BGP/MPLS IP-VPN 13 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months 27 and may be updated, replaced, or obsoleted by other documents at 28 any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on June 27, 2010. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your 49 rights 50 and restrictions with respect to this document. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) 58 controlling the copyright in such materials, this document may not 59 be modified outside the IETF Standards Process, and derivative 60 works of it may not be created outside the IETF Standards Process, 61 except to format it for publication as an RFC or to translate it 62 into languages other than English. 64 Abstract 66 Today, customers expect to run triple play services through 67 BGP/MPLS IP-VPNs. Some Service Providers will deploy services that 68 request QoS guarantees from a local CE to a remote CE across the 69 network. As a result, the application (e.g., voice, video, 70 bandwidth-guaranteed data pipe, etc.) requirements for an end-to- 71 end QOS and reserving an adequate bandwidth continue to increase. 73 Service Providers can use both an MPLS and an MPLS-TE LSP to meet 74 the service objectives. This document describes service provider 75 requirements for supporting a customer RSVP and RSVP-TE over a 76 BGP/MPLS IP-VPN. 78 Requirements Language 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 82 this document are to be interpreted as described in [RFC2119]. 84 Table of Contents 86 1. Introduction..................................................3 87 2. Terminology...................................................4 88 3. Problem Statement.............................................5 89 4. Application Scenarios.........................................7 90 4.1 Scenario I: Fast Recovery over BGP/MPLS IP-VPNs...........7 91 4.2 Scenario II: Strict C-TE LSP QoS Guarantees...............8 92 4.3 Scenario III: Load Balance of CE-to-CE Traffic............9 93 4.4 Scenario IV: RSVP Aggregation over MPLS TE Tunnels.......10 94 4.5 Scenario V: RSVP over Non-TE LSPs........................11 95 4.6 Scenario VI: RSVP-TE over Non-TE LSPs....................12 96 5. Detailed Requirements for C-TE LSPs Model....................12 97 5.1 Selective P-TE LSPs.....................................12 98 5.2 Graceful Restart Support for C-TE LSPs..................13 99 5.3 Rerouting Support for C-TE LSPs.........................13 100 5.4 FRR Support for C-TE LSPs...............................13 101 5.5 Admission Control Support on P-TE LSP Head-Ends.........13 102 5.6 Admission Control Support for C-TE LSPs in LDP-based Core 103 Networks.....................................................14 104 5.7 Policy Control Support for C-TE LSPs....................14 105 5.8 PCE Features Support for C-TE LSPs......................14 106 5.9 Diversely Routed C-TE LSPs Support......................15 107 5.10 Optimal Path Support for C-TE LSPs......................15 108 5.11 Reoptimization Support for C-TE LSPs....................15 109 5.12 DS-TE Support for C-TE LSPs.............................15 110 6. Detailed Requirements for C-RSVP Paths Model.................16 111 6.1 Admission Control between PE-CE for C-RSVP Paths........16 112 6.2 Aggregation of C-RSVP Paths by P-TE LSPs................16 113 6.3 Non-TE LSPs support for C-RSVP Paths....................16 114 6.4 Transparency of C-RSVP Paths............................16 115 7. Common Detailed Requirements for Two Models..................16 116 7.1 CE-PE Routing...........................................17 117 7.2 Complexity and Risks....................................17 118 7.3 Backward Compatibility..................................17 119 7.4 Scalability Considerations..............................17 120 7.5 Performance Considerations..............................17 121 7.6 Management Considerations...............................18 122 8. Security Considerations......................................18 123 9. IANA Considerations..........................................19 124 10. References..................................................19 125 10.1 Normative References....................................19 126 10.2 Informative References..................................20 127 11. Acknowledgments.............................................21 128 12. Author's Addresses..........................................21 129 Appendix A. Reference Model.....................................21 130 A.1 End-to-End C-RSVP Path Model.............................22 131 A.2 End-to-End C-TE LSP Model................................22 133 1. Introduction 135 Some Service Providers want to build a service which guarantees 136 QoS and a bandwidth from a local CE to a remote CE through the 137 network. A CE includes the network client equipment owned and 138 operated by the service provider. However, the CE may not be part 139 of the MPLS provider network. 141 Today, customers expect to run triple play services such as the 142 internet access, the telephone and the television through BGP/MPLS 143 IP-VPNs [RFC4364]. 144 As these services evolve, the requirements for an end-to-end QoS 145 to meet the application requirements also continue to grow. 146 Depending on the application (e.g., voice, video, bandwidth- 147 guaranteed data pipe, etc.), a native IP using an RSVP and/or an 148 end-to-end constrained MPLS-TE Label Switched Path (LSP) may be 149 required. The RSVP path may be used to provide QoS guarantees and 150 reserve an adequate bandwidth for the data. An end-to-end MPLS-TE 151 LSP may also be used to guarantee a bandwidth, and provide 152 extended functionality like MPLS fast reroute (FRR)[RFC4090] for 153 maintaining the service continuity around node and link, 154 including the CE-PE link, failures. It should be noted that an 155 RSVP session between two CEs may also be mapped and tunneled into 156 an MPLS-TE LSP across an MPLS provider network. 158 A number of advantages exist for deploying the model previously 159 mentioned. The first is that customers can use these network 160 services whilst being able to use both private addresses and 161 global addresses. The second advantage is that the traffic is 162 tunneled through the Service Provider backbone, so that the 163 customer traffic and the route confidentiality are maintained. 165 This document defines a reference model, example application 166 scenarios and detailed requirements for a solution supporting 167 a customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN. 169 Specification for a solution is out of scope in this document. 171 2. Terminology 173 This document uses the BGP/MPLS IP-VPN terminology defined in 174 [RFC4364]. The document also uses Path Computation Element terms 175 which are defined in [RFC4655]. 177 TE LSP: Traffic Engineering Label Switched Path 179 MPLS TE LSP: Multi Protocol Label Switching TE LSP 181 C-RSVP path: Customer RSVP path: a native RSVP path with the 182 bandwidth reservation of X for customers 184 C-TE LSP: Customer Traffic Engineering Label Switched Path: 185 an end-to-end MPLS TE LSP for customers 187 P-TE LSP: Provider Traffic Engineering Label Switched Path: a 188 transport TE LSP between two PEs 190 Head-end LSR: an ingress LSR 192 Tail-end LSR: an egress LSR 194 LSR: a Label Switched Router 196 3. Problem Statement 198 Service Providers want to deliver triple play services with QOS 199 guarantees to their customers. Various techniques are available to 200 achieve this. Some Service Providers will wish to offer advanced 201 services using an RSVP signaling for native IP flows (C-RSVP) or 202 an RSVP-TE signaling for Customer TE LSPs (C-TE LSPs) over 203 BGP/MPLS IP-VPNs. 205 The following examples outline each method: 207 A C-RSVP path with the bandwidth reservation of X can be used to 208 transport the voice. In order to achieve the sub-50msec recovery 209 during link, node and SRLG failures and to provide strict QoS 210 guarantees, a C-TE LSP with the bandwidth X between data centers 211 or customer sites can be used to carry the voice and the video 212 traffic. Thus, service providers or customers can choose a C-RSVP 213 path or a C-TE LSP to meet their requirements. 215 When service providers offer a C-RSVP path between hosts or CEs 216 over BGP/MPLS IP-VPNs, the CE/host requests an end-to-end C-RSVP 217 path with the bandwidth reservation of X to the remote CE/host. 218 However, if a C-RSVP signaling is to send within a VPN, the 219 service provider network will face scalability issues because 220 routers need to retain the RSVP state per a customer. Therefore, 221 in order to solve scalability issues, multiple C-RSVP 222 reservations can be aggregated at a PE, where a P-TE LSP 223 head-end can perform the admission control using the aggregated 224 C-RSVP reservations. The method that is described in RFC4804 can 225 be considered as a useful approach. In this case, a reservation 226 request from within the context of a VRF can get aggregated onto 227 a P-TE LSP. The P-TE LSP can be pre-established, resized based on 228 the request, or triggered by the request. Service providers, 229 however, cannot provide a C-RSVP path over the VRF instance as 230 defined in RFC4364. The current BGP/MPLS IP-VPN architecture also 231 does not support an RSVP instance running in the context of a VRF 232 to process RSVP messages and integrated services (int-serv) 233 [RFC1633][RFC2210]. One of solutions is described in [RSVP-L3VPN]. 235 If service providers offer a C-TE LSP from a CE to a CE over the 236 BGP/MPLS IP-VPN, they require that a MPLS TE LSP from a local CE 237 to a remote CE be established. However, if a C-TE LSP signaling 238 is to send within the VPN, the service provider network may face 239 the following scalability issues: 241 - A C-TE LSP can be aggregated by a P-TE LSP at a PE. (i.e. 242 hierarchical LSPs) In this case, only a PE maintains the state 243 about customer RSVP sessions. 245 - A C-TE LSP cannot be aggregated by a P-TE LSP at a PE depending 246 on some policies. (i.e. continuous LSPs) 247 In this case, both Ps and PEs maintain the state about customer 248 RSVP sessions. 250 - A C-TE LSP can be aggregated by the non-TE LSP (i.e. LDP). 251 In this case, only a PE maintains the state about customer 252 RSVP-TE sessions. 253 Note that it is assumed there is always enough bandwidth 254 available in the service provider core network. 256 Furthermore, if service providers provide the C-TE LSP over the 257 BGP/MPLS IP-VPN, they currently cannot provide it over the VRF 258 Instance as defined in RFC4364. Specifically the current BGP/MPLS 259 IP-VPN architecture does not support the RSVP-TE instance running 260 in the context of a VRF to process RSVP messages and trigger the 261 establishment of the C-TE LSP over the service provider core 262 network. If every C-TE LSP is to trigger the establishment or 263 resizing of a P-TE LSP, the service provider network will also 264 face scalability issues that arise from maintaining a large number 265 of the P-TE LSP and/or the dynamic signaling of these P-TE LSPs. 266 Section 8.4, Scalability Considerations, of this document provides 267 the detailed scalability requirements. 269 Two different models are described above. The differences between 270 C-RSVP paths and C-TE LSPs are as follows: 272 - C-RSVP path model: data packets among CEs are forwarded by 273 "native IP packets" (i.e. not labeled packets). 275 - C-TE LSP model: data packets among CEs are forwarded by 276 "labeled IP packets". 278 Depending on the service level and the need to meet specific 279 requirements, service providers should be able to choose P-TE LSPs 280 or non-TE LSPs in the backbone network. The selection may be 281 dependent on the Service Providers policy and the node capability 282 to support the mechanisms described. 284 The following items are required selectively to support C-RSVP 285 paths and C-TE LSPs over BGP/MPLS IP-VPNs based on the service 286 level. For example, some service providers need all of the 287 following items to provide a service. Some service providers need 288 some of them to provide the service. It depends on a service level 289 and a policy of service providers. Detailed requirements are 290 described in sections 6, 7 and 8. 292 - C-RSVP path QoS guarantees. 293 - Fast recovery over the BGP/MPLS IP-VPN to protect traffic for 294 the C-TE LSP against the CE-PE link failure and the PE node 295 failure. 296 - Strict C-TE LSP bandwidth and QoS guarantees. 297 - Resource optimization for C-RSVP paths and C-TE LSPs. 298 - Scalability for C-RSVP paths and C-TE LSPs. 300 4. Application Scenarios 302 The following sections present a few application scenarios for 303 C-RSVP paths and C-TE LSPs in BGP/MPLS IP-VPN environments. 304 Appendix A. (Reference Model), describes a C-RSVP path, a C-TE LSP 305 and a P-TE LSP. 307 In all scenarios, it is the responsibility of the service provider 308 to ensure that the enough bandwidth is available to meet the 309 customers application requirements. 311 4.1 Scenario I: Fast Recovery over BGP/MPLS IP-VPNs 313 In this scenario, as shown in figure 1, a customer uses a VoIP 314 application between its sites (i.e., between CE1 and CE2). 315 H0 and H1 are voice equipments. 317 In this case, the customer establishes C-TE LSP1 as a primary 318 Path and C-TE LSP2 as a backup path. If the link between PE1 319 and CE1 or the node of PE1 fails, C-TE LSP1 needs C-TE LSP2 as a 320 path protection. 322 Generally speaking, C-RSVP paths are used by customers and P-TE 323 LSPs are used by service providers. 325 C-TE LSP1 326 <----------------------------------------------> 327 P-TE LSP1 328 <---------------------------> 329 ............. ............. 330 . --- --- . --- --- --- --- . --- --- . 331 .|H0 | |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |H1 |. 332 . --- --- . --- --- --- --- . --- --- . 333 .........|... --- --- --- --- ...|......... 334 +-------|PE3|----|P3 |-----|P4 |----|PE4|-------+ 335 --- --- --- --- 337 <---------------------------> 338 P-TE LSP2 339 <----------------------------------------------> 340 C-TE LSP2 342 <--customer--> <--------BGP/MPLS IP-VPN-------> <--customer-> 343 network network 345 Figure 1 Scenario I 347 4.2 Scenario II: Strict C-TE LSP QoS Guarantees 349 In this scenario, as shown in figure 2, a service provider B 350 transports the voice and the video traffic between its sites (i.e., 351 between CE1 and CE2). 352 In this case, the service provider B establishes C-TE LSP1 with 353 the preemption priority 0 and the bandwidth 100Mbps for the voice 354 traffic, and C-TE LSP2 with the preemption priority 1 and the 355 bandwidth 200Mbps for the unicast video traffic. On the other hand, 356 a service provider A also pre-establishes P-TE LSP1 with the 357 preemption priority 0 and the bandwidth 1Gbps for the voice 358 traffic, and P-TE LSP2 with the preemption priority 1 and the 359 bandwidth 2Gbps for the video traffic. These P-TE LSP1 and P-TE 360 LSP2 should support DS-TE. [RFC4124] 362 PE1 and PE3 should choose an appropriate P-TE LSP based on the 363 preemption priority. In this case, C-TE LSP1 must be associated 364 with P-TE LSP1 at PE1 and C-TE LSP2 must be associated with P-TE 365 LSP2 at PE3. 367 Furthermore, PE1 and PE3 head-ends should control the bandwidth of 368 C-TE LSPs. In this case, PE1 and PE3 can choose C-TE LSPs by the 369 amount of max available bandwidth for each P-TE LSP, respectively. 371 C-TE LSP1 372 <----------------------------------------------> 373 P-TE LSP1 374 <---------------------------> 375 ............. ............. 376 . --- --- . --- --- --- --- . --- --- . 377 .|CE0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |CE3|. 378 . --- --- . --- --- --- --- . --- --- . 379 .........|... --- --- --- --- ...|......... 380 +-------|PE3|----|P3 |-----|P4 |----|PE4|-------+ 381 --- --- --- --- 383 <---------------------------> 384 P-TE LSP2 385 <----------------------------------------------> 386 C-TE LSP2 388 <---SP B----> <--------BGP/MPLS IP-VPN-------> <---SP B---> 389 network SP A network network 391 Figure 2 Scenario II 393 It's possible that the customer and the service provider have 394 differing preemption priorities. In this case, the PE policy will 395 override the customers. In the case that the service provider does 396 not support preemption priorities then priorities should be 397 ignored. 399 4.3 Scenario III: Load Balance of CE-to-CE Traffic 401 In this scenario, as shown in figure 3, the service provider C 402 uses the voice and the video traffic between its sites (i.e., 403 between CE0 and CE5/CE7, between CE2 and CE5/CE7, between CE5 and 404 CE0/CE2, and between CE7 and CE0/CE2). H0 and H1 are voice and 405 video equipments. In this case, the service provider C establishes 406 C-TE LSP1, C-TE LSP3, C-TE LSP5 and C-TE LSP7 with the preemption 407 priority 0 and the bandwidth 100Mbps for the voice traffic, and 408 establishes C-TE LSP2, C-TE LSP4, C-TE LSP6 and C-TE LSP8 with the 409 preemption priority 1 and the bandwidth 200Mbps for the video 410 traffic. On the other hand, the service provider A also pre- 411 establishes P-TE LSP1 and P-TE LSP3 with the preemption priority 0 412 and the bandwidth 1Gbps for the voice traffic, and P-TE LSP2 and 413 P-TE LSP4 with the preemption priority 1 and the bandwidth 2Gbps 414 for the video traffic. These P-TE LSP1, P-TE LSP2, P-TE LSP3 and 415 P-TE LSP4 should support DS-TE.[RFC4124] 417 All PEs should choose an appropriate P-TE LSP based on the 418 preemption priority. To minimize the traffic disruption due to a 419 single network failure, diversely routed C-TE LSPs are 420 established. In this case, the FRR [RFC4090] is not necessarily 421 required. 423 Also, unconstrained TE LSPs (i.e., C-TE LSPs/P-TE LSPs with the 0 424 bandwidth) [RFC5330] are applicable to this scenario. 426 Furthermore, the load balancing for a communication between H0 427 and H1 can be done by setting up full mesh C-TE LSPs between 428 CE0/CE2 and CE5/CE7. 430 C-TE LSP1(P=0),2(P=1) (CE0->CE1->...->CE4->CE5) 431 (CE0<-CE1<-...<-CE4<-CE5) 432 <----------------------------------------------> 434 C-TE LSP3(P=0),4(P=1) (CE2->CE1->...->CE4->CE7) 435 (CE2<-CE1<-...<-CE4<-CE7) 436 <----------------------------------------------> 437 P-TE LSP1 (p=0) 438 <--------------------> 439 P-TE LSP2 (p=1) 441 <--------------------> 442 .................. .................. 443 . --- --- . --- --- --- --- . --- --- . 444 . |CE0|-|CE1|--|PE1|--|P1 |---|P2 |--|PE2|--|CE4|-|CE5| . 445 . --- /--- --- . --- --- --- --- . --- ---\ --- . 446 .|H0 | + . + . + |H1 |. 447 . --- \--- --- . --- --- --- --- . --- ---/ --- . 448 . |CE2|-|CE3|--|PE3|--|P3 |---|P4 |--|PE4|--|CE6|-|CE7| . 449 . --- --- . --- --- --- --- . --- --- . 450 .................. .................. 451 <--------------------> 452 P-TE LSP3 (p=0) 453 <--------------------> 454 P-TE LSP4 (p=1) 455 <----------------------------------------------> 456 C-TE LSP5(P=0),6(P=1) (CE0->CE3->...->CE6->CE5) 457 (CE0<-CE3<-...<-CE6<-CE5) 459 <----------------------------------------------> 460 C-TE LSP7(P=0),8(P=1) (CE2->CE3->...->CE6->CE7) 461 (CE2<-CE3<-...<-CE6<-CE7) 463 <-----SP C-----> <----BGP/MPLS IP-VPN----> <-----SP C-----> 464 network SP A network network 466 Figure 3 Scenario III 468 4.4 Scenario IV: RSVP Aggregation over MPLS TE Tunnels 470 In this scenario, as shown in figure 4, the customer has two hosts 471 connecting off CE1 and CE2 respectively. CE1 and CE2 are connected 472 to PE1 and PE2, respectively, within a VRF instance belonging to 473 the same VPN. The requesting host (H1) may request to the H2 an 474 RSVP path with the bandwidth reservation of X. This reservation 475 request from within the context of VRF will get aggregated onto a 476 pre-established P-TE/DS-TE LSP based upon procedures similar to 477 [RFC4804]. As in the case of [RFC4804], there may be multiple P-TE 478 LSPs belonging to different DS-TE class-types. Local policies can 479 be implemented to map the incoming RSVP path request from H1 to 480 the P-TE LSP with the appropriate class-type. Please note that the 481 e2e RSVP path request may also be initiated by the CE devices 482 themselves. 484 C-RSVP path 485 <-----------------------------------------------------> 487 P-TE LSP 488 <---------------------------> 489 ............. ............. 491 . --- --- . --- --- --- --- . --- --- . 492 .|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |. 493 . --- --- . --- --- --- --- . --- --- . 494 ............. ............. 495 ^ ^ 496 | | 497 vrf instance vrf instance 499 <-customer-> <--------BGP/MPLS IP-VPN-------> <-customer-> 500 network network 502 Figure 4 Scenario IV 504 4.5 Scenario V: RSVP over Non-TE LSPs 506 In this scenario, as shown in figure 5, a customer has two hosts 507 connecting off CE1 and CE2, respectively. CE1 and CE2 are 508 connected to PE1 and PE2, respectively, within a VRF instance 509 belonging to the same VPN. The requesting host (H1) may request 510 to H2 an RSVP path with the bandwidth reservation of X. In this 511 case, a non-TE LSP (i.e. LDP etc) is provided between PEs and has 512 LDP which supports MPLS diffserv [RFC3270]. 513 Note that this only provides Diffserv and not the bandwidth 514 reservation as is done with RSVP-TE. 516 Local policies can be implemented to map the customer's reserved 517 flow to the LSP with the appropriate Traffic Class [RFC5462] at 518 PE1. 520 C-RSVP path 521 <------------------------------------------> 523 Non-TE LSP 524 <---------------------------> 525 ............. ............. 526 . --- --- . --- --- --- --- . --- --- . 527 .|H1 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H2 |. 528 . --- --- . --- --- --- --- . --- --- . 529 ............. ............. 530 ^ ^ 531 | | 532 vrf instance vrf instance 534 <-customer-> <-------BGP/MPLS IP-VPN-------> <-customer-> 535 network network 537 Figure 5 Scenario V 539 4.6 Scenario VI: RSVP-TE over Non-TE LSPs 541 In this scenario, as shown in figure 6, a customer uses a VoIP 542 application between its sites (i.e., between CE1 and CE2). H0 543 and H1 are voice equipments. In this case, a non-TE LSP means 544 LDP and the customer establishes C-TE LSP1 as a primary path and 545 C-TE LSP2 as a backup path. If the link between PE1 and CE1 or 546 the node of PE1 fails, C-TE LSP1 needs C-TE LSP2 as a path 547 protection. 549 C-TE LSP1 550 <-----------------------------------------> 551 Non-TE LSP 552 <--------------------------> 553 ............. ............. 554 . --- --- . --- --- --- --- . --- --- . 555 .|H0 | |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |H1 |. 556 . --- --- . --- --- --- --- . --- --- . 557 .........|... --- --- --- --- ...|......... 558 +-----|PE3|----|P3 |-----|P4 |----|PE4|-----+ 559 --- --- --- --- 561 <--------------------------> 562 Non-TE LSP 563 <-----------------------------------------> 564 C-TE LSP2 566 <-customer-> <------BGP/MPLS IP-VPN------> <-customer-> 567 network network 569 Figure 6 Scenario VI 571 5. Detailed Requirements for C-TE LSPs Model 573 This section describes detailed requirements for C-TE LSPs in 574 BGP/MPLS IP-VPN environments. 576 5.1 Selective P-TE LSPs 578 The solution MUST provide the ability to decide which P-TE LSPs a 579 PE uses for a C-RSVP path and a C-TE LSP. When a PE receives a 580 native RSVP and/or a path messages from a CE, it MUST be able to 581 decide which P-TE LSPs it uses. In this case, various kinds of 582 P-TE LSPs exist in the service provider network. For example, the 583 PE MUST choose an appropriate P-TE LSP based on local policies 584 such as: 586 1. preemption priority 587 2. affinity 588 3. class-type 589 4. on the data plane: (DSCP or Traffic Class bits) 591 5.2 Graceful Restart Support for C-TE LSPs 593 The solution SHOULD support the graceful restart capability, 594 where the C-TE LSP traffic continues to be forwarded during a PE 595 graceful restart, graceful restart mechanisms related to this 596 architecture are described in [RFC3473], [RFC3623] and [RFC4781]. 598 5.3 Rerouting Support for C-TE LSPs 600 The solution MUST provide the rerouting of a C-TE LSP in case of 601 Link, node and SRLG failures or preemption. Such rerouting may be 602 controlled by a CE or by a PE depending on the failure. In a dual 603 homed environment, the ability to perform the rerouting MUST be 604 provided against a CE-PE link failure or a PE failure if another 605 is available between the head-end and the tail-end of the C-TE 606 LSP. 608 5.4 FRR Support for C-TE LSPs 610 The solution MUST support FRR [RFC4090] features for a C-TE LSP 611 over a vrf instance. 612 In BGP/MPLS IP-VPN environments, a C-TE LSP from a CE traverses 613 multiple PEs and Ps, albeit tunneled over a P-TE LSP. In order to 614 avoid PE-CE link/PE node/SRLG failures, a CE (a customer's head-end 615 router) needs to support the link protection or the node 616 protection. 618 The following protection MUST be supported: 620 1. CE link protection 621 2. PE node protection 622 3. CE node protection 624 5.5 Admission Control Support on P-TE LSP Head-Ends 626 The solution MUST support the admission control on a P-TE LSP 627 tunnel head-end for C-TE LSPs. C-TE LSPs may potentially try to 628 reserve the bandwidth that exceeds the bandwidth of the P-TE LSP. 629 The P-TE LSP tunnel head-end SHOULD control the number of 630 C-TE LSPs and/or the bandwidth of C-TE LSPs. For example, the 631 transport TE LSP head-end SHOULD have a configurable limit on 632 the maximum number of C-TE LSPs that it can admit from a CE. As 633 for the amount of bandwidth that can be reserved by C-TE LSPs 634 there could be two situations: 636 1. Let the P-TE LSP do its natural bandwidth admission 637 2. Set a cap on the amount of bandwidth and have the configuration 638 option to: 640 a. Reserve the minimum of the cap bandwidth or the C-TE LSP 641 bandwidth on the P-TE LSP if the required bandwidth is available 642 b. Reject the C-TE LSP if the required bandwidth by the C-TE LSP 643 is not available 645 5.6 Admission Control Support for C-TE LSPs in LDP-based Core 646 Networks 648 The solution MUST support the admission control for a C-TE LSP at 649 a PE in the LDP-based core network. Specifically, PEs MUST have a 650 configurable limit on the maximum amount of bandwidth that can be 651 reserved by C-TE LSPs per a vrf instance (i.e. per a customer). 652 Also, a PE SHOULD have a configurable limit on the total amount of 653 bandwidth that can be reserved by C-TE LSPs between PEs. 655 5.7 Policy Control Support for C-TE LSPs 657 The solution MUST support the policy control for a C-TE LSP at a 658 PE. 660 The PE MUST be able to perform the following: 662 1. Limit the rate of RSVP messages per CE link. 663 2. Accept and map or reject requests for a given affinity. 664 3. Accept and map or reject requests with a specified setup and/or 665 pre-emption priorities. 666 4. Accept or reject requests for fast reroutes. 667 5. Neglect the requested setup and/or pre-emption priorities and 668 select a P-TE LSP based on a local policy that applies to the CE-PE 669 link or the VRF. 670 6. Ignore the requested affinity and select a P-TE LSP based on a 671 local policy that applies to the CE-PE link or the VRF. 672 7. Perform mapping in data plane between customer traffic class 673 bits and transport P-TE LSP traffic class bits, as signaled per 674 [RFC3270]. 676 5.8 PCE Features Support for C-TE LSPs 678 The solution SHOULD support the PCE architecture for a C-TE LSP 679 establishment in the context of a VRF instance. When a C-TE LSP is 680 provided, CEs, PEs and Ps may support PCE [RFC4655] and [RFC5440] 681 features. 683 In this case, CE routers or PE routers may be PCCs and PE routers 684 and/or P routers may be PCEs. Furthermore, the solution SHOULD 685 support a mechanism for the dynamic PCE discovery. Specifically, 686 all PCEs are not necessarily discovered automatically and only 687 specific PCEs that know VPN routes should be discovered 688 automatically. 690 5.9 Diversely Routed C-TE LSPs Support 692 The solution MUST provide for setting up diversely routed C-TE 693 LSPs over the VRF instance. These diverse C-TE LSPs MAY be 694 traversing over two different P-TE LSPs that are fully disjoint 695 within a service provider network. When a single CE has multiple 696 uplinks which connect to different PEs, it is desirable that 697 multiple C-TE LSPs over the VRF instance are established between 698 a pair of LSRs. When two CEs have multiple uplinks which connect 699 to different PEs, it is desirable that multiple C-TE LSPs over the 700 VRF instance are established between two different pairs of LSRs. 701 In these cases, for example, the following points will be 702 beneficial to customers. 704 1. load balance of the CE-to-CE traffic across diverse C-TE LSPs 705 so as to minimize the traffic disruption in case of a single 706 network element failure 707 2. path protection (e.g. 1:1, 1:N) 709 5.10 Optimal Path Support for C-TE LSPs 711 The solution MUST support the optimal path for a C-TE LSP over the 712 VRF instance. Depending on an application (e.g. voice and video), 713 an optimal path is needed for a C-TE LSP over the vrf instance. An 714 optimal path may be a shortest path based on the TE metric, in the 715 case of a TE-LSP or an IGP metric, in the case of LDP. 717 5.11 Reoptimization Support for C-TE LSPs 719 The solution MUST support the reoptimization of a C-TE LSP over 720 the VRF instance. These LSPs MUST be reoptimized using 721 make-before-break[RFC3209]. 722 In this case, it is desirable for a CE to be configured with 723 regard to the timer-based or event-driven reoptimization. 724 Furthermore, customers SHOULD be able to reoptimize a C-TE LSP 725 manually. To provide the delay-sensitive or jitter-sensitive 726 traffic (i.e. the voice traffic), a C-TE LSP path computation 727 and a route selection are expected to optimal for the specific 728 application. 730 5.12 DS-TE Support for C-TE LSPs 732 The solution MUST support DS-TE [RFC4124] for a C-TE LSP over the 733 VRF instance. In the event that the service provider and the 734 customer have differing bandwidth constraint models, then only 735 the service provider bandwidth model should be supported. 737 Applications, which have different traffic characteristics, are 738 used 739 in BGP/MPLS IP-VPN environments. Service providers try to achieve 740 the fine-grained optimization of transmission resources, 741 efficiency and further enhanced network performance. It may be 742 desirable to perform TE at a per-class level. 744 By mapping the traffic from a given diff-serv class of service on 745 a separate C-TE LSP, it allows this traffic to utilize resources 746 available to the given class on both shortest paths and 747 non-shortest paths, and follow paths that meet TE constraints 748 which are specific to the given class. 750 6. Detailed Requirements for C-RSVP Paths Model 752 This section describes detailed requirements for C-RSVP paths in 753 BGP/MPLS IP-VPN environments. 755 6.1 Admission Control between PE-CE for C-RSVP Paths 757 The solution MUST support the admission control at the ingress PE. 758 PEs MUST control RSVP messages per a vrf. 760 6.2 Aggregation of C-RSVP Paths by P-TE LSPs 762 The solution SHOULD support C-RSVP paths aggregated by P-TE LSPs. 763 P-TE LSPs SHOULD be pre-established manually or dynamically by 764 operators, and MAY be established triggered by C-RSVP messages. 765 Also, the P-TE LSP SHOULD support DS-TE. 767 6.3 Non-TE LSPs support for C-RSVP Paths 769 The solution SHOULD support non-TE LSPs (i.e. LDP-based LSP, 770 etc). They are established by LDP [RFC5036] between PEs, and 771 supports MPLS diffserv [RFC3270]. The solution MAY support local 772 policies to map the customer's reserved flow to the LSP with the 773 appropriate Traffic Class at the PE. 775 6.4 Transparency of C-RSVP Paths 777 The solution SHOULD NOT change RSVP messages from the local CE to 778 the remote CE (Path, Resv, Path Error, Resv Error, etc). 779 The solution SHOULD allow customers to receive RSVP messages 780 transparently between CE sites. 782 7. Common Detailed Requirements for Two Models 783 This section describes common detailed requirements for C-TE LSPs 784 and C-RSVP paths in BGP/MPLS IP-VPN environments. 786 7.1 CE-PE Routing 788 The solution SHOULD support the following routing configuration on 789 the CE-PE links with either RSVP or RSVP-TE on the CE-PE link: 791 1. static routing 792 2. BGP routing 793 3. OSPF 794 4. OSPF-TE (RSVP-TE case only) 796 7.2 Complexity and Risks 798 The solution SHOULD avoid introducing unnecessary complexity to 799 the current operating network to such a degree that it would 800 affect the stability and diminish the benefits of deploying such a 801 solution over SP networks. 803 7.3 Backward Compatibility 805 The deployment of C-RSVP paths and C-TE LSPs SHOULD avoid 806 impacting existing RSVP and MPLS TE mechanisms respectively, but 807 allow for a smooth migration or co-existence. 809 7.4 Scalability Considerations 811 The solution SHOULD minimize the impact on network scalability 812 from a C-RSVP path and a C-TE LSP over the VRF instance. 813 As indentified in earlier sections, PCE provides a method for 814 offloading computation of C-TE LSPs and help with the solution 815 scalability. 817 The solution MUST address the scalability of C-RSVP paths and 818 C-TE LSPs for the following protocols. 820 1. RSVP (e.g. number of RSVP messages, retained state etc). 821 2. RSVP-TE (e.g. number of RSVP control messages, retained state, 822 message size etc). 823 3. BGP (e.g. number of routes, flaps, overloads events etc). 825 7.5 Performance Considerations 827 The solution SHOULD be evaluated with regard to the following 828 criteria. 830 1. Degree of path optimality of the C-TE LSP. 831 2. TE LSP setup time. 833 3. Failure and restoration time. 834 4. Impact and scalability of the control plane due to added 835 overheads. 836 5. Impact and scalability of the data/forwarding plane due to 837 added overheads. 839 7.6 Management Considerations 841 The solution MUST address the manageability of C-RSVP paths and 842 C-TE LSPs for the following considerations. 844 1. Need for a MIB module for control plane (including mapping of 845 P-TE LSP and C-TE LSPs) and bandwidth monitoring. 846 2. Need for diagnostic tools (this include Trace Route and PING). 848 The solution MUST allow routers to support the MIB module for 849 C-RSVP paths and C-TE LSPs per a vrf instance. If a CE is managed 850 by service providers, the solution MUST allow service providers 851 to collect MIB information for C-RSVP paths and C-TE LSPs from 852 the CE per a customer. 854 Diagnostic tools can detect failures of the control plane and the 855 data plane for general MPLS TE LSPs [RFC4379]. The solution MUST 856 allow routers to be able to detect failures of the control and 857 the data plane for C-TE LSPs over a VRF instance. 859 MPLS OAM for C-TE LSPs MUST be supported within the context of VRF 860 except for the above. 862 8. Security Considerations 864 Any solution should consider the following general security 865 requirements: 867 1. The solution SHOULD NOT divulge the service provider topology 868 information to the customer network. 869 2. The solution SHOULD minimize the service provider network 870 vulnerability to Denial of Service (DoS) attacks. 871 3. The solution SHOULD minimize the misconfiguration of DSCP 872 marking, preemption, and holding priorities of the customer 873 traffic. 875 The following additional security issues for C-TE LSPs relate to 876 both control plane and data plane. 878 In terms of the control plane, in the models of C-RSVP paths and 879 C-TE LSPs both, a PE receives IPv4 or IPv6 RSVP control packets 880 from a CE. If the CE is a router that is not trusted by service 881 providers, the PE MUST be able to limit the rate and number of 882 IPv4 or IPv6 RSVP control packets. 884 In terms of the data plane, in the model of C-TE LSPs, a PE 885 receives labeled IPv4 or IPv6 data packets from a CE. If the CE 886 is a router that is not trusted by service providers, the PE 887 MUST be able to limit the rate of labeled IPv4 or IPv6 data 888 packets. If the CE is a trusted router for service providers, 889 the PE MAY be able to limit the rate of labeled IPv4 or IPv6 890 data packets. Specifically, the PE must drop MPLS-labeled 891 packets if the MPLS label was not assigned over the PE-CE link 892 on which the packet was received. The PE must also be able to 893 police traffic to the traffic profile associated with the LSP on 894 which traffic is received on the PE-CE link. 896 Moreover, flooding RSVP/RSVP-TE control packets from malicious 897 customers must be avoided. Therefore, a PE MUST isolate the 898 impact of such customer's RSVP/ RSVP-TE packets from other 899 customers. 901 In the event that C-TE LSPs are diversely routed over VRF 902 instances, the VRF should indicate to the CE how such diversity 903 was provided. 905 9. IANA Considerations 907 This requirement document makes no requests for IANA action. 909 10. References 911 10.1 Normative References 913 [RFC1633] Braden, R., et al., "Integrated Services in the 914 Internet Architecture: an Overview", RFC 1633, June 915 1994. 917 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 918 Requirement Levels", BCP 14, RFC 2119, March 1997. 920 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 921 Services", RFC 2210, September 1997. 923 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 924 V. and Swallow, G., "RSVP-TE: Extensions to RSVP for 925 LSP Tunnels", RFC 3209, December 2001. 927 [RFC3270] Le Faucheur, F., "Multi-Protocol Label Switching 928 (MPLS) Support of Differentiated Services", RFC 3270, 929 May 2002. 931 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 932 Switching(GMPLS) Signaling Resource ReserVation 933 Protocol-Traffic Engineering (RSVP-TE) Extensions", 934 RFC 3473, January 2003. 936 [RFC3623] Moy, J., et al., "Graceful OSPF Restart", RFC3623, 937 November 2003. 939 [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute 940 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 941 2005. 943 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 944 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 945 June 2005. 947 [RFC4364] Rosen, E., and Rekhter, Y., "BGP/MPLS IP Virtual 948 Private Networks (VPNs)", RFC 4364, February 2006. 950 [RFC4379] Kompella, K. and G. Swallow, "Detecting MPLS Data 951 Plane Failures", RFC 4379, February 2006. 953 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "Path 954 Computation Element (PCE) Architecture", RFC 4655, 955 August 2006. 957 [RFC4781] Rekhter, Y. and Aggarwal, R., "Graceful Restart 958 Mechanism for BGP with MPLS", RFC 4781, January 2007. 960 [RFC5036] Andersson, L., Minei, I. and Thomas, B., "LDP 961 Specification", RFC 5036, October 2007. 963 [RFC5462] Andersson, L. and Asati, R., "Multiprotocol Label 964 Switching (MPLS) Label Stack Entry: "EXP" Field 965 Renamed to "Traffic Class" Field", RFC 5462, 966 February 2009. 968 10.2 Informative References 970 [RSVP-L3VPN] Davie, B., et al., "Support for RSVP in Layer 3 VPNs", 971 Work in Progress, February 2008. 973 [RFC4804] Le Faucheur, F., et al., "Aggregation of RSVP 974 Reservations over MPLS TE/DS-TE Tunnels", RFC4804, 975 February 2007. 977 [RFC5330] Vasseur, J.-P., et al., "A Link-Type sub-TLV to convey 978 the number of Traffic Engineering Label Switched Paths 979 signaled with zero reserved bandwidth across a link", 980 RFC5330, October 2008. 982 [RFC5440] Vasseur, J.-P., et al., "Path Computation Element(PCE) 983 communication Protocol (PCEP) - Version 1", RFC5440, 984 March 2009. 986 11. Acknowledgments 988 The author would like to express the thanks to Nabil Bitar, David 989 McDysan and Daniel King for their helpful and useful comments and 990 feedback. 992 12. Author's Addresses 994 Kenji Kumaki (Editor) 995 KDDI Corporation 996 Garden Air Tower 997 Iidabashi, Chiyoda-ku, 998 Tokyo 102-8460, JAPAN 999 Email: ke-kumaki@kddi.com 1001 Raymond Zhang 1002 BT Infonet 1003 2160 E. Grand Ave. 1004 El Segundo, CA 90025 1005 Email: raymond.zhang@bt.infonet.com 1007 Yuji Kamite 1008 NTT Communications Corporation 1009 Tokyo Opera City Tower 1010 3-20-2 Nishi Shinjuku, Shinjuku-ku 1011 Tokyo 163-1421, Japan 1012 Email: y.kamite@ntt.com 1014 Appendix A. Reference Model 1016 In this appendix, a C-RSVP path, a C-TE LSP and a P-TE LSP are 1017 explained. 1019 All scenarios in this appendix assume the following: 1021 - A P-TE LSP is established between PE1 and PE2. This LSP is used 1022 by the VRF instance to forward customer packets within a 1023 BGP/MPLS IP-VPN. 1025 - The Service Provider has ensured that enough bandwidth is 1026 available to meet the service requirements. 1028 A.1 End-to-End C-RSVP Path Model 1030 A C-RSVP path and a P-TE LSP are shown in figure 1 in the context 1031 of a BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e. LDP) in 1032 some cases. In the case of a non-TE mechanism, however, it may 1033 be difficult to guarantee an end-to-end bandwidth as resources 1034 are shared. 1036 CE0/CE1 requests an e2e C-RSVP path to CE3/CE2 with the bandwidth 1037 reservation of X. At PE1, this reservation request received in 1038 the context of a VRF will get aggregated onto a pre-established 1039 P-TE LSP, or trigger the establishment of a new P-TE LSP. 1040 It should be noted that C-RSVP sessions across different BGP/MPLS 1041 IP-VPNs can be aggregated onto the same P-TE LSP between the same 1042 PE pair, achieving further scalability. [RFC4804] defines this 1043 scenario in more detail. 1045 The RSVP control messages (e.g. an RSVP PATH message and an RSVP 1046 RESV message) exchanged among CEs are forwarded by IP packets 1047 through the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive 1048 a reservation message from CE2 and/or CE3, CE0/CE1 establishes 1049 a C-RSVP path through the BGP/MPLS IP-VPN. 1051 C-RSVP path 1052 <------------------------------------------> 1054 P-TE LSP 1055 <---------------------------> 1056 ............. ............. 1057 . --- --- . --- --- --- --- . --- --- . 1058 .|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|. 1059 . --- --- . --- --- --- --- . --- --- . 1060 ............. ............. 1061 ^ ^ 1062 | | 1063 vrf instance vrf instance 1065 <-customer-> <------BGP/MPLS IP-VPN------> <-customer-> 1066 network network 1067 or or 1068 another another 1069 service provider service provider 1070 network network 1072 Figure 1 e2e C-RSVP path model 1074 A.2 End-to-End C-TE LSP Model 1075 A C-TE LSP and a P-TE LSP are shown in figure 2 in the context of 1076 a BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e. LDP) in 1077 some cases. As described in previous sub-section, it may be 1078 difficult to guarantee an end-to-end QoS in some cases. 1080 CE0/CE1 requests an e2e TE LSP path to CE3/CE2 with the bandwidth 1081 reservation of X. At PE1, this reservation request received in the 1082 context of a VRF will get aggregated onto a pre-established P-TE 1083 LSP, or trigger the establishment of a new P-TE LSP. It should be 1084 noted that C-TE LSPs across different BGP/MPLS IP-VPNs can be 1085 aggregated onto the same P-TE LSP between the same PE pair, 1086 achieving further scalability. 1088 The RSVP-TE control messages (e.g. a RSVP PATH message and a RSVP 1089 RESV message) exchanged among CEs are forwarded by a labeled 1090 packet through the BGP/MPLS IP-VPN. After CE0 and/or CE1 receive 1091 a reservation message from CE2 and/or CE3, CE0/CE1 establishes a 1092 C-TE LSP through the BGP/MPLS IP-VPN. 1094 A P-TE LSP is established between PE1 and PE2. This LSP is used 1095 by the VRF instance to forward customer packets within the 1096 BGP/MPLS IP-VPN. 1098 C-TE LSP 1099 <-------------------------------------------------------> 1101 or 1103 C-TE LSP 1104 <-----------------------------------------> 1106 P-TE LSP 1107 <---------------------------> 1108 ............. ............. 1109 . --- --- . --- --- --- --- . --- --- . 1110 .|CE0| |CE1|---|PE1|----|P1 |-----|P2 |----|PE2|---|CE2| |CE3|. 1111 . --- --- . --- --- --- --- . --- --- . 1112 ............. ............. 1113 ^ ^ 1114 | | 1115 vrf instance vrf instance 1117 <-customer-> <-------BGP/MPLS IP-VPN-------> <-customer-> 1118 network network 1119 or or 1120 another another 1121 service provider service provider 1122 network network 1123 Figure 2 e2e C-TE LSP model