idnits 2.17.1 draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 983. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 990. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 996. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- 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: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 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 Category: Informational KDDI R&D Labs 5 Created: February 18, 2008 R. Zhang 6 Expires: August 18, 2008 BT 7 Y. Kamite 8 NTT Communications 10 Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS 11 IP-VPN 13 draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 Some service providers want to build a service which guarantees QoS 44 or bandwidth from a local CE to a remote CE through the network. 45 Today, customers expect to run triple play services through BGP/MPLS 46 IP-VPNs. As a result, their requirements for end-to-end QoS of 47 applications are increasing. Depending on the application (e.g., 48 voice, video, bandwidth-guaranteed data pipe, etc.), an end-to-end 49 native RSVP path and/or an end-to-end MPLS TE LSP are required, and 50 they need to meet some constraints. 51 This document describes service provider requirements for supporting 52 customer RSVP and RSVP-TE over a BGP/MPLS VPN. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in [RFC2119]. 60 Table of Contents 62 1. Introduction..................................................3 63 2. Terminology...................................................4 64 3. Problem Statement.............................................4 65 4. Reference Model...............................................6 66 4.1 End-to-End C-RSVP Path Model...............................6 67 4.2 End-to-End C-TE LSP Model..................................7 68 5. Application Scenarios..........................................8 69 5.1 Scenario I: Fast Recovery over BGP/MPLS IP-VPN.............8 70 5.2 Scenario II: Strict C-TE LSP QoS Guarantees................9 71 5.3 Scenario III: Load Balance of CE-to-CE Traffic............10 72 5.4 Scenario IV: RSVP Aggregation over MPLS TE Tunnels........11 73 5.5 Scenario V: RSVP over Non-TE LSP..........................12 74 6. Detailed Requirements for C-TE LSPs Model.....................12 75 6.1 Selective P-TE LSPs.....................................13 76 6.2 Graceful Restart Support for C-TE LSPs..................13 77 6.3 Rerouting Support for C-TE LSPs.........................13 78 6.4 FRR Support for C-TE LSPs...............................13 79 6.5 Admission Control Support on P-TE LSP Head-Ends.........13 80 6.6 Policy Control Support for C-TE LSPs....................14 81 6.7 PCE Features Support for C-TE LSPs......................14 82 6.8 Diversely Routed C-TE LSPs Support......................14 83 6.9 Optimal Path Support for C-TE LSPs......................15 84 6.10 Reoptimization Support for C-TE LSPs....................15 85 6.11 DS-TE Support for C-TE LSPs.............................15 86 7. Detailed Requirements for C-RSVP Paths Model..................15 87 7.1 Admission Control between PE-CE for C-RSVP Paths..........15 88 7.2 Aggregation of C-RSVP Paths by P-TE LSPs..................16 89 7.3 Non-TE LSPs support for C-RSVP Paths......................16 90 7.4 Transparency of C-RSVP Paths..............................16 91 8. Common Detailed Requirements for Two Models...................16 92 8.1 CE-PE Routing...........................................16 93 8.2 Complexity and Risks....................................16 94 8.3 Backward Compatibility..................................16 95 8.4 Scalability Considerations..............................17 96 8.5 Performance Considerations..............................17 97 8.6 Management Considerations...............................17 99 9. Security Considerations......................................18 100 10. IANA Considerations..........................................18 101 11. References...................................................18 102 11.1 Normative References....................................18 103 11.2 Informative References...................................19 104 12. Acknowledgments..............................................20 105 13. Author's Addresses...........................................20 107 1. Introduction 109 Some service providers want to build a service which guarantees QoS 110 or bandwidth from a local CE to a remote CE through the network. A CE 111 could be broadened to include network client equipment owned and 112 operated by the service provider. However, the CE is not part of the 113 MPLS provider network. 114 Today, customers expect to run triple play services through BGP/MPLS 115 IP-VPNs [RFC4364]. As a result, their requirements for end-to-end QoS 116 of applications are increasing. Depending on the application (e.g., 117 voice, video, bandwidth-guaranteed data pipe, etc.), an end-to-end 118 native RSVP path and/or an end-to-end MPLS TE LSP are required, and 119 they need to meet some constraints. For example, an RSVP path may be 120 used to provide for bandwidth and QoS guarantees. An end-to-end MPLS 121 TE LSP may be used to guarantee bandwidth, and provide for MPLS fast 122 reroute (FRR) [RFC4090] around node and link failure. It should be 123 noted that an RSVP session between two CEs may also be mapped and 124 tunneled into a TE LSP across an MPLS provider network in a most 125 likely scenario. 127 If service providers offer the above services in BGP/MPLS IP-VPNs, 128 they can have the following two advantages. 130 The first advantage is for customers to receive these network 131 services while being able to use both private addresses and global 132 addresses as they desire. 134 The second advantage is for service providers to offer these network 135 services while protecting confidentiality from customers. Customers 136 join a Virtual Routing and Forwarding (VRF) instance and cannot 137 forward packets through the service provider's global forwarding 138 instance, nor can they join the service provider's intra-domain 139 routing. 141 This document defines a reference model, application scenarios and 142 detailed requirements for supporting customer RSVP and RSVP-TE over a 143 BGP/MPLS IP-VPN. 145 Also, specification for this solution itself is out of scope in this 146 document. 148 2. Terminology 150 LSP: Label Switched Path 152 TE LSP: Traffic Engineering Label Switched Path 154 MPLS TE LSP: Multi Protocol Label Switching TE LSP 156 C-RSVP path: Customer RSVP path: a native RSVP path with bandwidth 157 reservation of X for customers 159 C-TE LSP: Customer Traffic Engineering Label Switched Path: 160 an end-to-end MPLS TE LSP for customers 162 P-TE LSP: Provider Traffic Engineering Label Switched Path: a 163 transport TE LSP between two PEs 165 VPN: Virtual Private Network 167 CE: Customer Edge Equipment 169 PE: Provider Edge Equipment that has direct connections to CEs from 170 the Layer3 point of view. 172 P: Provider Equipment that has backbone trunk connections only. 174 VRF: Virtual Private Network (VPN) Routing and Forwarding Instance 176 PCC: Path Computation Client: any client application requesting a 177 path computation to be performed by a Path Computation Element. 179 PCE: Path Computation Element: an entity (component, application or 180 network node) that is capable of computing a network path or 181 route based on a network graph and applying computational 182 constraints. 184 Head-end LSR: ingress LSR 186 Tail-end LSR: egress LSR 188 LSR: Label Switched Router 190 3. Problem Statement 192 Some service providers think that they can offer advanced services 193 using RSVP or RSVP-TE over BGP/MPLS IP-VPNs. In addition, in many 194 cases, BGP/MPLS IP-VPNs can be used within the service provider 195 network to carry network services. For example, a C-RSVP path with 196 bandwidth reservation of X can be used to transport voice. In order 197 to achieve sub-50msec recovery during link/node/SRLG failure and to 198 provide strict QoS guarantees, a C-TE LSP with bandwidth X between 199 data centers or customer sites can be used to carry voice and video 200 traffic. Thus, service providers or customers can choose a C-RSVP 201 path or a C-TE LSP to meet their requirements. Please note that there 203 When service providers offer a C-RSVP path between hosts or CEs over 204 BGP/MPLS IP-VPNs, the CE/host requests an end-to-end C-RSVP path with 205 bandwidth reservation of X to the remote CE/host. However, if a C- 206 RSVP signaling is to send within VPN, the service provider network 207 will face scalability issues. Therefore, in order to solve 208 scalability issues, multiple C-RSVP reservations can be aggregated at 209 PE, where a P-TE LSP head-end can perform admission control using the 210 aggregated C-RSVP reservations. The method that is described in 211 RFC4804 can be considered as a useful approach. In this case, a 212 reservation request from within the context of a VRF can get 213 aggregated onto a P-TE LSP. The P-TE LSP can be pre-established, 214 resized based on the request, or triggered by the request. Service 215 providers, however, can not provide a C-RSVP path over vrf instance 216 as defined in RFC4364. The current BGP/MPLS IP-VPN architecture also 217 does not support an RSVP instance running in the context of a vrf to 218 process RSVP messages and integrated services (int-serv) 219 [RFC1633][RFC2210]. One of solutions is described in [RSVP-L3VPN]. 221 If service providers offer a C-TE LSP from CE to CE over BGP/MPLS IP- 222 VPN, they require that a MPLS TE LSP from a local CE to a remote CE 223 be established. However, if a C-TE LSP signaling is to send within 224 VPN, the service provider network will face scalability issues. 225 Therefore, in order to solve scalability issues, multiple C-TE LSPs 226 can be aggregated at PE, where a P-TE LSP head-end can perform 227 admission control using hierarchical methods. Furthermore, if service 228 providers provide the C-TE LSP over a BGP/MPLS IP-VPN, they can not 229 provide it over vrf instance as defined in RFC4364. The current 230 BGP/MPLS IP-VPN architecture does not support an RSVP-TE instance 231 running in the context of a vrf to process RSVP messages and trigger 232 the establishment of the C-TE LSP over the service provider core 233 network. If every C-TE LSP is to trigger the establishment or 234 resizing of a P-TE LSP, the service provider network will also face 235 scalability issues that arise from maintaining a large number of P-TE 236 LSPs and/or dynamic signaling of these P-TE LSPs. 238 Thus, in the models of C-RSVP paths and C-TE LSPs both, the solution 239 must address these scalability concerns. 241 Two different models are described above. The differences between C- 242 RSVP paths and C-TE LSPs are as follows: 244 - C-RSVP path model: data packets among CEs are forwarded by "native 245 IP packets" (i.e. not labeled packets). 247 - C-TE LSP model: data packets among CEs are forwarded by "labeled IP 248 packets". 250 The following items are mainly required to support C-RSVP paths and 251 C-TE LSPs over BGP/MPLS IP-VPNs. Detailed requirements are described 252 in sections 6, 7 and 8. 254 - C-RSVP path QoS guarantees. 255 - Fast recovery over BGP/MPLS IP-VPN to protect traffic for C-TE LSP 256 against CE-PE link failure and PE node failure. 257 - Strict C-TE LSP bandwidth and QoS guarantees. 258 - Resource optimization for C-RSVP paths and C-TE LSPs. 259 - Scalability for C-RSVP paths and C-TE LSPs. 261 4. Reference Model 263 In this section, a C-RSVP path, a C-TE LSP and a P-TE LSP are 264 explained. 266 4.1 End-to-End C-RSVP Path Model 268 A C-RSVP path and a P-TE LSP are shown in figure 1 in the context of 269 a BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e., LDP) in some 270 cases. In some cases, however, it may be difficult to guarantee end- 271 to-end QoS. (e.g. If a P-TE LSP has enough bandwidth in service 272 provider backbone, a C-RSVP path can reserve a bandwidth.) 274 CE0/CE1 requests an e2e C-RSVP path to CE3/CE2 with bandwidth 275 reservation of X. At PE1, this reservation request received in the 276 context of a VRF will get aggregated onto a pre-established P-TE LSP, 277 or trigger the establishment of a new P-TE LSP. It should be noted 278 that C-RSVP sessions across different BGP/MPLS IP-VPNs can be 279 aggregated onto the same P-TE LSP between the same PE pair, achieving 280 further scalability. 282 The RSVP control messages (e.g. an RSVP PATH message and an RSVP RESV 283 message) exchanged among CEs are forwarded by IP packets through 284 BGP/MPLS IP-VPN. After CE0 and/or CE1 receive a reservation message 285 from CE2 and/or CE3, CE0/CE1 establishes a C-RSVP path through the 286 BGP/MPLS IP-VPN. 288 A P-TE LSP is established between PE1 and PE2. This LSP is used by 289 the vrf instance to forward customer packets within BGP/MPLS IP-VPN. 291 Generally speaking, C-RSVP paths are used by customers and P-TE LSPs 292 are used by service providers. 294 C-RSVP path 295 <----------------------------------------------> 297 P-TE LSP 298 <---------------------------> 299 ............. ............. 300 . --- --- . --- --- --- --- . --- --- . 301 .|CE0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |CE3|. 302 . --- --- . --- --- --- --- . --- --- . 303 ............. ............. 304 ^ ^ 305 | | 306 vrf instance vrf instance 308 <--customer--> <--------BGP/MPLS IP-VPN-------> <--customer-> 309 network network 310 or or 311 another another 312 service provider service provider 313 network network 315 Figure 1 e2e C-RSVP path model 317 4.2 End-to-End C-TE LSP Model 319 A C-TE LSP and a P-TE LSP are shown in figure 2 in the context of a 320 BGP/MPLS IP-VPN. A P-TE LSP may be a non-TE LSP (i.e., LDP) in some 321 cases. As described in previous sub-section, it may be difficult to 322 guarantee end-to-end QoS in some cases. 324 CE0/CE1 requests an e2e TE LSP path to CE3/CE2 with bandwidth 325 reservation of X. At PE1, this reservation request received in the 326 context of a VRF will get aggregated onto a pre-established P-TE LSP, 327 or trigger the establishment of a new P-TE LSP. It should be noted 328 that C-TE LSPs across different BGP/MPLS IP-VPNs can be aggregated 329 onto the same P-TE LSP between the same PE pair, achieving further 330 scalability. 332 The RSVP-TE control messages (e.g. a RSVP PATH message and a RSVP 333 RESV message) exchanged among CEs are forwarded by labeled packet 334 through BGP/MPLS IP-VPN. After CE0 and/or CE1 receive a reservation 335 message from CE2 and/or CE3, CE0/CE1 establishes a C-TE LSP through 336 the BGP/MPLS IP-VPN. 338 A P-TE LSP is established between PE1 and PE2. This LSP is used by 339 the vrf instance to forward customer packets within BGP/MPLS IP-VPN. 341 Generally speaking, C-TE LSPs are used by customers and P-TE LSPs are 342 used by service providers. 344 C-TE LSP 345 <-----------------------------------------------------------> 347 or 349 C-TE LSP 350 <----------------------------------------------> 352 P-TE LSP 353 <---------------------------> 354 ............. ............. 355 . --- --- . --- --- --- --- . --- --- . 356 .|CE0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |CE3|. 357 . --- --- . --- --- --- --- . --- --- . 358 ............. ............. 359 ^ ^ 360 | | 361 vrf instance vrf instance 363 <--customer--> <--------BGP/MPLS IP-VPN-------> <--customer-> 364 network network 365 or or 366 another another 367 service provider service provider 368 network network 370 Figure 2 e2e C-TE LSP model 372 5. Application Scenarios 374 The following sections present a few application scenarios for C-RSVP 375 paths and C-TE LSPs in BGP/MPLS IP-VPN environments. 377 5.1 Scenario I: Fast Recovery over BGP/MPLS IP-VPN 379 In this scenario, as shown in figure 3, a customer uses a VoIP 380 application between its sites (i.e., between CE1 and CE2). H0 and H1 381 are voice equipment. 382 In this case, the customer establishes C-TE LSP1 as a primary path 383 and C-TE LSP2 as a backup path. If the link between PE1 and CE1 or 384 the node PE1 fails, C-TE LSP1 needs C-TE LSP2 as a path protection. 386 C-TE LSP1 387 <----------------------------------------------> 388 P-TE LSP1 389 <---------------------------> 390 ............. ............. 392 . --- --- . --- --- --- --- . --- --- . 393 .|H0 | |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |H1 |. 394 . --- --- . --- --- --- --- . --- --- . 395 .........|... --- --- --- --- ...|......... 396 +-------|PE3|----|P3 |-----|P4 |----|PE4|-------+ 397 --- --- --- --- 399 <---------------------------> 400 P-TE LSP2 401 <----------------------------------------------> 402 C-TE LSP2 404 <--customer--> <--------BGP/MPLS IP-VPN-------> <--customer-> 405 network network 407 Figure 3 Scenario I 409 5.2 Scenario II: Strict C-TE LSP QoS Guarantees 411 In this scenario, as shown in figure 4, a service provider B 412 transports voice and video traffic between its sites (i.e., between 413 CE1 and CE2). 414 In this case, service provider B establishes C-TE LSP1 with 415 preemption priority 0 and bandwidth 100Mbps for voice traffic, and C- 416 TE LSP2 with preemption priority 1 and bandwidth 200Mbps for unicast 417 video traffic. On the other hand, service provider A also pre- 418 establishes P-TE LSP1 with preemption priority 0 and bandwidth 1Gbps 419 for voice traffic, and P-TE LSP2 with preemption priority 1 and 420 bandwidth 2Gbps for video traffic. These P-TE LSP1 and P-TE LSP2 421 should support DS-TE. [RFC4124] 423 PE1 and PE3 should choose an appropriate P-TE LSP based on preemption 424 priority. In this case, C-TE LSP1 must be associated with P-TE LSP1 425 at PE1 and C-TE LSP2 must be associated with P-TE LSP2 at PE3. 427 Furthermore, PE1 and PE3 head-ends should control the bandwidth of C- 428 TE LSPs. In this case, PE1 and PE3 can choose C-TE LSPs by the amount 429 of max available bandwidth for each P-TE LSP, respectively. 431 C-TE LSP1 432 <----------------------------------------------> 433 P-TE LSP1 434 <---------------------------> 435 ............. ............. 436 . --- --- . --- --- --- --- . --- --- . 437 .|CE0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |CE3|. 438 . --- --- . --- --- --- --- . --- --- . 439 .........|... --- --- --- --- ...|......... 440 +-------|PE3|----|P3 |-----|P4 |----|PE4|-------+ 441 --- --- --- --- 443 <---------------------------> 444 P-TE LSP2 445 <----------------------------------------------> 446 C-TE LSP2 448 <---SP B----> <--------BGP/MPLS IP-VPN-------> <---SP B---> 449 network SP A network network 451 Figure 4 Scenario II 453 5.3 Scenario III: Load Balance of CE-to-CE Traffic 455 In this scenario, as shown in figure 5, service provider C uses voice 456 and video traffic between its sites (i.e., between CE0 and CE5/CE7, 457 between CE2 and CE5/CE7, between CE5 and CE0/CE2, and between CE7 and 458 CE0/CE2). H0 and H1 are voice and video equipment. 460 In this case, service provider C establishes C-TE LSP1, C-TE LSP3, C- 461 TE LSP5 and C-TE LSP7 with preemption priority 0 and bandwidth 462 100Mbps for voice traffic, and establishes C-TE LSP2, C-TE LSP4, C-TE 463 LSP6 and C-TE LSP8 with preemption priority 1 and bandwidth 200Mbps 464 for video traffic. On the other hand, service provider A also pre- 465 establishes P-TE LSP1 and P-TE LSP3 with preemption priority 0 and 466 bandwidth 1Gbps for voice traffic, and P-TE LSP2 and P-TE LSP4 with 467 preemption priority 1 and bandwidth 2Gbps for video traffic. These P- 468 TE LSP1, P-TE LSP2, P-TE LSP3 and P-TE LSP4 should support DS-TE. 469 [RFC4124] 471 All PEs should choose an appropriate P-TE LSP based on preemption 472 priority. To minimize the traffic disruption due to a single network 473 failure, diversely routed C-TE LSPs are established. In this case, 474 FRR [RFC4090] is not necessarily required. 476 Also, unconstrained TE LSPs (i.e., C-TE LSPs/P-TE LSPs with 0 477 bandwidth) [ZERO-BANDWIDTH] are applicable to this scenario. 479 Furthermore, load balancing for a communication between H0 and H1 can 480 be done by setting up full mesh C-TE LSPs between CE0/CE2 and CE5/CE7. 482 C-TE LSP1(P=0),2(P=1) (CE0->CE1->...->CE4->CE5) 483 (CE0<-CE1<-...<-CE4<-CE5) 484 <--------------------------------------------------> 485 C-TE LSP3(P=0),4(P=1) (CE2->CE1->...->CE4->CE7) 486 (CE2<-CE1<-...<-CE4<-CE7) 487 <--------------------------------------------------> 488 P-TE LSP1 (p=0) 489 <-----------------------> 490 P-TE LSP2 (p=1) 491 <-----------------------> 492 .................. .................. 493 . --- --- . --- --- --- --- . --- --- . 494 . |CE0|-|CE1|---|PE1|---|P1 |---|P2 |---|PE2|---|CE4|-|CE5| . 495 . --- /--- --- . --- --- --- --- . --- ---\ --- . 496 .|H0 | + . + . + |H1 |. 497 . --- \--- --- . --- --- --- --- . --- ---/ --- . 498 . |CE2|-|CE3|---|PE3|---|P3 |---|P4 |---|PE4|---|CE6|-|CE7| . 499 . --- --- . --- --- --- --- . --- --- . 500 .................. .................. 501 <-----------------------> 502 P-TE LSP3 (p=0) 503 <-----------------------> 504 P-TE LSP4 (p=1) 505 <--------------------------------------------------> 506 C-TE LSP5(P=0),6(P=1) (CE0->CE3->...->CE6->CE5) 507 (CE0<-CE3<-...<-CE6<-CE5) 508 <--------------------------------------------------> 509 C-TE LSP7(P=0),8(P=1) (CE2->CE3->...->CE6->CE7) 510 (CE2<-CE3<-...<-CE6<-CE7) 512 <-----SP C-----> <--------BGP/MPLS IP-VPN-------> <-----SP C-----> 513 network SP A network network 515 Figure 5 Scenario III 517 5.4 Scenario IV: RSVP Aggregation over MPLS TE Tunnels 519 In this scenario, as shown in figure 6, the customer has two hosts 520 connecting off CE1 and CE2 respectively. CE1 and CE2 are connected 521 to PE1 and PE2, respectively, within a VRF instance belonging to the 522 same VPN. The requesting host (H1) may request to H2 an RSVP path 523 with bandwidth reservation of X. This reservation request from 524 within the context of VRF will get aggregated onto a pre-established 525 P-TE/DS-TE LSP based upon procedures similar to [RFC4804]. As in the 526 case of [RFC4804], there may be multiple P-TE LSPs belonging to 527 different DS-TE class-types. Local policies can be implemented to 528 map the incoming RSVP path request from H1 to the P-TE LSP with the 529 appropriate class-type. Please note that the e2e RSVP path request 530 may also be initiated by the CE devices themselves. 532 C-RSVP path 533 <----------------------------------------------> 535 P-TE LSP 536 <---------------------------> 537 ............. ............. 538 . --- --- . --- --- --- --- . --- --- . 540 .|H1 | |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |H2 |. 541 . --- --- . --- --- --- --- . --- --- . 542 ............. ............. 543 ^ ^ 544 | | 545 vrf instance vrf instance 547 <--customer--> <--------BGP/MPLS IP-VPN-------> <--customer-> 548 network network 550 Figure 6 Scenario IV 552 5.5 Scenario V: RSVP over Non-TE LSP 554 In this scenario, as shown in figure 7, the customer has two hosts 555 connecting off CE1 and CE2 respectively. CE1 and CE2 are connected to 556 PE1 and PE2, respectively, within a VRF instance belonging to the 557 same VPN. The requesting host (H1) may request to H2 an RSVP path 558 with bandwidth reservation of X. In this case, a non-TE LSP (i.e. LDP 559 etc) is provided between PEs and supports MPLS diffserv [RFC3270]. 560 Local policies can be implemented to map customer's reserved flow to 561 the LSP with the appropriate EXP at PE1. Please note that there is 562 always enough bandwidth available in service provider backbone. 564 C-RSVP path 565 <----------------------------------------------> 567 Non-TE LSP 568 <---------------------------> 569 ............. ............. 570 . --- --- . --- --- --- --- . --- --- . 571 .|H1 | |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |H2 |. 572 . --- --- . --- --- --- --- . --- --- . 573 ............. ............. 574 ^ ^ 575 | | 576 vrf instance vrf instance 578 <--customer--> <--------BGP/MPLS IP-VPN-------> <--customer-> 579 network network 581 Figure 7 Scenario V 583 6. Detailed Requirements for C-TE LSPs Model 585 This section describes detailed requirements for C-TE LSPs in 586 BGP/MPLS IP-VPN environments. 588 6.1 Selective P-TE LSPs 590 The solution MUST provide the ability to decide which P-TE LSP a PE 591 uses for a C-RSVP path and a C-TE LSP. When a PE receives a native 592 RSVP and/or a path messages from a CE, it may be able to decide which 593 P-TE LSP it uses. In this case, various kinds of P-TE LSPs exist in 594 service provider network. For example, the PE MUST choose an 595 appropriate P-TE LSP based on local policies such as: 596 1. preemption priority 597 2. affinity 598 3. class-type 599 4. on the data plane: (DSCP or EXP bits) 601 6.2 Graceful Restart Support for C-TE LSPs 603 The solution SHOULD provide graceful restart capability for a C-TE 604 LSP over vrf instance. Graceful restart mechanisms related to this 605 architecture are described in [RFC3473] [RFC3623] [RFC4781]. 607 6.3 Rerouting Support for C-TE LSPs 609 The solution MUST provide rerouting of a C-TE LSP in case of 610 link/node/SRLG failures or preemption. Such rerouting may be 611 controlled by a CE or by a PE depending on the failure. Rerouting 612 capability MUST be provided against a CE-PE link failure or a PE 613 failure if another is available between the head-end and the tail-end 614 of the C-TE LSP. 616 6.4 FRR Support for C-TE LSPs 618 The solution MUST support FRR [RFC4090] features for a C-TE LSP over 619 vrf instance. 620 In BGP/MPLS IP-VPN environments, a C-TE LSP from a CE traverses 621 multiple PEs and Ps, albeit tunneled over a P-TE LSP. In order to 622 avoid PE-CE link/PE node/SRLG failures, a CE (a customer's head-end 623 router) needs to support a fast local protection or a fast path 624 protection. 626 The following protection MUST be supported: 627 1. CE link protection 628 2. PE node protection 629 3. CE node protection (supposed that there are one or more C-TE nodes 630 at customer sites) 632 6.5 Admission Control Support on P-TE LSP Head-Ends 634 The solution MUST support admission control on a P-TE LSP tunnel 635 head-end. C-TE LSPs may potentially reserve over the bandwidth of a 636 P-TE LSP. The P-TE LSP tunnel head-end SHOULD control the number of 637 C-TE LSPs and/or the bandwidth of C-TE LSPs. 638 For example, the transport TE LSP head-end MUST have a configurable 639 limit on the maximum number of C-TE LSPs that it can admit from a CE. 640 As for the amount of bandwidth that can be reserved by C-TE LSPs: 641 there could be two situations: 642 1. Let the P-TE LSP do its natural bandwidth admission 643 2. Set a cap on the amount of bandwidth and have the configuration 644 option to: 645 a. Reserve the minimum of the cap bandwidth or the C-TE LSP bandwidth 646 on the P-TE LSP if the required bandwidth is available 647 b. Reject the C-TE LSP if the required bandwidth by the C-TE LSP is 648 not available 650 6.6 Policy Control Support for C-TE LSPs 652 The solution MUST support policy control for a C-TE LSP at a PE. 653 The PE MUST be able to perform the following: 654 1. Limit the rate of RSVP messages per CE link 655 2. Accept or reject requests for a given affifinity 656 3. Accept or reject requests with a specified setup and/or pre- 657 emption priorities. 658 4. Accept or reject requests for fast reroutes 659 5. Neglect the requested setup and/or pre-emption priorities and 660 select a P-TE LSP based on a local policy that applies to the CE-PE 661 link or VRF. 662 6. Neglect the requested affinity and select a P-TE LSP based on a 663 local policy that applies to the CE-PE link or VRF. 664 7. Perform mapping in data plane between customer exp bits and 665 transport P-TE LSP exp bits. 667 6.7 PCE Features Support for C-TE LSPs 669 The solution MAY support PCE architecture for a C-TE LSP 670 establishment in the context of a vrf instance. When a C-TE LSP is 671 provided, CEs, PEs and Ps may support PCE [RFC4655] [PCEP] features. 672 In this case, CE routers or PE routers may be PCCs and PE routers 673 and/or P routers may be PCEs. 675 6.8 Diversely Routed C-TE LSPs Support 677 The solution MUST provide for setting up diversely routed C-TE LSPs 678 over vrf instance. These diverse C-TE LSPs MAY be traversing over two 679 different P-TE LSPs that are fully disjoint within a service provider 680 network. When a single CE has multiple uplinks which connect to 681 different PEs, it is desirable that multiple C-TE LSPs over vrf 682 instance are established between a pair of LSRs. When two CEs have 683 multiple uplinks which connect to different PEs, it is desirable that 684 multiple C-TE LSPs over vrf instance are established between two 685 different pairs of LSRs. In these cases, for example, the following 686 points will be beneficial to customers. 688 1. load balance of CE-to-CE traffic across diverse C-TE LSPs so as to 689 minimize the traffic disruption in case of a single network element 690 failure 691 2. path protection (e.g. 1:1, 1:N) 693 6.9 Optimal Path Support for C-TE LSPs 695 The solution MUST support an optimal path for a C-TE LSP over vrf 696 instance. 697 Depending on an application (e.g. voice and video), an optimal path 698 is needed for a C-TE LSP over vrf instance. An optimal path may be a 699 shortest path based on TE metric or IGP metric. 701 6.10 Reoptimization Support for C-TE LSPs 703 The solution MUST support reoptimization of a C-TE LSP over vrf 704 instance. These LSPs MUST be reoptimized using make-before-break. 705 In this case, it is desirable for a customer's head-end LSR to be 706 configured with regard to timer-based or event-driven reoptimization. 707 Furthermore, customers SHOULD be able to reoptimize a C-TE LSP 708 manually. 709 To provide delay- or jitter-sensitive traffic (i.e. voice traffic), a 710 C-TE LSP is expected to be kept optimal. 712 6.11 DS-TE Support for C-TE LSPs 714 The solution MUST support DS-TE [RFC4124] for a C-TE LSP over vrf 715 instance. 716 Applications, which have different traffic characteristics, are used 717 in BGP/MPLS IP-VPN environments. Service providers try to achieve 718 fine-grained optimization of transmission resources, efficiency and 719 further enhanced network performance. It may be desirable to perform 720 TE at a per-class level. 721 By mapping the traffic from a given diff-serv class of service on a 722 separate C-TE LSP, it allows this traffic to utilize resources 723 available to the given class on both shortest paths and non-shortest 724 paths, and follow paths that meet TE constraints which are specific 725 to the given class. 727 7. Detailed Requirements for C-RSVP Paths Model 729 This section describes detailed requirements for C-RSVP paths in 730 BGP/MPLS IP-VPN environments. 732 7.1 Admission Control between PE-CE for C-RSVP Paths 733 The solution MUST support admission control at ingress/egress PE. PEs 734 MUST control RSVP messages per a vrf. 736 7.2 Aggregation of C-RSVP Paths by P-TE LSPs 738 The solution SHOULD support C-RSVP paths aggregated by P-TE LSPs. 739 P-TE LSPs SHOULD be pre-established by manually or dynamically, MAY 740 be established triggered by C-RSVP message. Also, P-TE LSP SHOULD 741 support DS-TE. 743 7.3 Non-TE LSPs support for C-RSVP Paths 745 The solution MUST support non-TE LSPs (i.e. LDP-based LSP, etc). They 746 are provided between PEs and supports MPLS diffserv [RFC3270]. Local 747 policies can be implemented to map customer's reserved flow to the 748 LSP with the appropriate EXP at PE. 749 Please note that there is always enough bandwidth available in 750 service provider backbone. 752 7.4 Transparency of C-RSVP Paths 754 The solution SHOULD NOT change RSVP messages from local CE to remote 755 CE (Path, Resv, Path Error, Resv Error, etc). Customers SHOULD deal 756 RSVP messages transparently between CE sites. 758 8. Common Detailed Requirements for Two Models 760 This section describes common detailed requirements for C-TE LSPs and 761 C-RSVP paths in BGP/MPLS IP-VPN environments. 763 8.1 CE-PE Routing 765 The solution MUST support the following routing configuration on the 766 CE-PE links with either RSVP or RSVP-TE on the CE-PE link: 768 1. static routing 769 2. BGP routing 770 3. OSPF 771 4. OSPF-TE (RSVP-TE case only) 773 8.2 Complexity and Risks 775 The solution SHOULD NOT introduce unnecessary complexity to the 776 current operating network to such a degree that it would affect the 777 stability and diminish the benefits of deploying such a solution over 778 SP networks. 780 8.3 Backward Compatibility 781 The deployment of C-RSVP paths and C-TE LSPs SHOULD NOT impact 782 existing RSVP and MPLS TE mechanisms respectively, but allow for a 783 smooth migration or co-existence. 785 8.4 Scalability Considerations 787 The solution MUST have a minimum impact on network scalability from a 788 C-RSVP path and a C-TE LSP over vrf instance. 789 Scalability of C-RSVP paths and C-TE LSPs MUST address the following 790 consideration. 792 1. RSVP (e.g. number of RSVP messages, retained state etc). 793 2. RSVP-TE (e.g. number of RSVP control messages, retained state, 794 message size etc). 795 3. BGP (e.g. number of routes, flaps, overloads events etc). 797 8.5 Performance Considerations 799 The solution SHOULD be evaluated with regard to the following 800 criteria. 802 1. Degree of path optimality of the C-TE LSP. 803 2. TE LSP setup time. 804 3. Failure and restoration time. 805 4. Impact and scalability of the control plane due to added 806 overheads and so on. 807 5. Impact and scalability of the data/forwarding plane due to added 808 overheads and so on. 810 8.6 Management Considerations 812 Manageability of C-RSVP paths and C-TE LSPs MUST addresses the 813 following considerations. 815 1. Need for a MIB module for control plane and monitoring. 816 2. Need for diagnostic tools. 818 MIB module for C-RSVP paths and C-TE LSPs MUST collect per a vrf 819 instance. 820 If a CE is managed by service providers, MIB information for C-RSVP 821 paths and C-TE LSPs from the CE MUST be collected per a customer. 823 Today, diagnostic tools can detect failures of control plane and data 824 plane for general MPLS TE LSPs [RFC4379]. 825 The diagnostic tools MUST detect failures of control and data plane 826 for C-TE LSPs over a vrf instance. 828 MPLS OAM for C-TE LSPs MUST be supported within the context of VRF 829 except for the above. 831 In BGP/MPLS IP-VPN environments, from a CE point of view, IP TTL 832 decreases at a local PE and a remote PE. But from a PE point of view, 833 both IP TTL and MPLS TTL decreases between PEs. 835 9. Security Considerations 837 Security issues for C-TE LSPs relate to both control plane and data 838 plane. 840 In terms of control plane, in the models of C-RSVP paths and C-TE 841 LSPs both, a PE receives IPv4 or IPv6 RSVP control packets from a CE. 842 If the CE is an untrusted router for service providers, the PE MUST 843 be able to limit IPv4 or IPv6 RSVP control packets. If the CE is a 844 trusted router for service providers, the PE MAY be able to limit 845 IPv4 or IPv6 control packets. 847 In terms of data plane, in the model of C-TE LSPs, a PE receives 848 labeled IPv4 or IPv6 data packets from a CE. If the CE is an 849 untrusted router for service providers, the PE MUST be able to limit 850 labeled IPv4 or IPv6 data packets. If the CE is a trusted router for 851 service providers, the PE MAY be able to limit labeled IPv4 or IPv6 852 data packets. Specifically, the PE must drop MPLS-labeled packets if 853 the MPLS label was not assigned over the PE-CE link on which the 854 packet was received. The PE must also be able to police traffic to 855 the traffic profile associated with the LSP on which traffic is 856 received on the PE-CE link. 858 Moreover, flooding RSVP/RSVP-TE control packets from malicious 859 customers enables other customers to impact themselves on their 860 communication. Therefore, a PE MUST isolate the impact of such 861 customer's packets from other customers. 863 In BGP/MPLS IP-VPN environments, from a CE point of view, IP TTL 864 should decrease at a local PE and a remote PE to hide service 865 provider network topology. 867 10. IANA Considerations 869 This requirement document makes no requests for IANA action. 871 11. References 873 11.1 Normative References 875 [RFC1633] Braden, R., et al., "Integrated Services in the Internet 876 Architecture: an Overview", RFC 1633, June 1994. 878 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 879 Requirement Levels", BCP 14, RFC 2119, March 1997. 881 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 882 Services", RFC 2210, September 1997. 884 [RFC3270] Le Faucheur, F., "Multi-Protocol Label Switching (MPLS) 885 Support of Differentiated Services", RFC 3270, May 2002. 887 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 888 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 889 Engineering (RSVP-TE) Extensions", RFC 3473, January 890 2003. 892 [RFC3623] Moy, J., et al., "Graceful OSPF Restart", RFC3623, 893 November 2003. 895 [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute 896 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 897 2005. 899 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 900 Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 901 2005. 903 [RFC4364] Rosen, E., and Rekhter, Y., "BGP/MPLS IP Virtual Private 904 Networks (VPNs)", RFC 4364, February 2006. 906 [RFC4379] Kompella, K. and G. Swallow, "Detecting MPLS Data Plane 907 Failures", RFC 4379, February 2006. 909 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "Path Computation 910 Element (PCE) Architecture", RFC 4655, August 2006. 912 [RFC4781] Rekhter, Y., and Aggarwal, R., "Graceful Restart 913 Mechanism for BGP with MPLS", RFC 4781, January 2007. 915 11.2 Informative References 917 [RSVP-L3VPN] Davie, B., et al., "Support for RSVP in Layer 3 VPNs", 918 Work in Progress, June 2007. 920 [PCEP] Vasseur, J.-P., et al., "Path Computation Element(PCE) 921 communication Protocol (PCEP) - Version 1", Work in 922 Progress, February 2007. 924 [RFC4804] Le Faucheur, F., et al., "Aggregation of RSVP 925 Reservations over MPLS TE/DS-TE Tunnels", RFC4804, 926 February 2007. 928 [ZERO-BANDWIDTH] Vasseur, J.-P., et al., "A Link-Type sub-TLV to 929 convey the number of Traffic Engineering Label 930 Switched Paths signaled with zero reserved bandwidth 931 across a link", Work in Progress, February 2008. 933 12. Acknowledgments 935 The author would like to express the thanks to Nabil Bitar for his 936 helpful and useful comments and feedback. 938 13. Author's Addresses 940 Kenji Kumaki 941 KDDI R&D Laboratories, Inc. 942 2-1-15 Ohara Fujimino 943 Saitama 356-8502, JAPAN 944 Email: ke-kumaki@kddi.com 946 Raymond Zhang 947 BT Infonet 948 2160 E. Grand Ave. 949 El Segundo, CA 90025 950 Email: raymond.zhang@bt.infonet.com 952 Yuji Kamite 953 NTT Communications Corporation 954 Tokyo Opera City Tower 955 3-20-2 Nishi Shinjuku, Shinjuku-ku 956 Tokyo 163-1421, Japan 957 Email: y.kamite@ntt.com 959 Full Copyright Statement 961 Copyright (C) The IETF Trust (2008). 963 This document is subject to the rights, licenses and restrictions 964 contained in BCP 78, and except as set forth therein, the authors 965 retain all their rights. 967 This document and the information contained herein are provided on an 968 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 969 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 970 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 971 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 972 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 973 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 975 Intellectual Property 976 The IETF takes no position regarding the validity or scope of any 977 Intellectual Property Rights or other rights that might be claimed to 978 pertain to the implementation or use of the technology described in 979 this document or the extent to which any license under such rights 980 might or might not be available; nor does it represent that it has 981 made any independent effort to identify any such rights. Information 982 on the procedures with respect to rights in RFC documents can be 983 found in BCP 78 and BCP 79. 985 Copies of IPR disclosures made to the IETF Secretariat and any 986 assurances of licenses to be made available, or the result of an 987 attempt made to obtain a general license or permission for the use of 988 such proprietary rights by implementers or users of this 989 specification can be obtained from the IETF on-line IPR repository at 990 http://www.ietf.org/ipr. 992 The IETF invites any interested party to bring to its attention any 993 copyrights, patents or patent applications, or other proprietary 994 rights that may cover technology that may be required to implement 995 this standard. Please address the information to the IETF at 996 ietf-ipr@ietf.org. 998 Acknowledgement 1000 Funding for the RFC Editor function is provided by the IETF 1001 Administrative Support Activity (IASA).