idnits 2.17.1 draft-balaji-mpls-csc-te-lsp-splice-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 4 instances of lines with control characters in the document. == There are 30 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 163 has weird spacing: '...fferent than...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 25, 2013) is 4078 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'PE-Pa' is mentioned on line 630, but not defined == Missing Reference: 'PE-Lo' is mentioned on line 630, but not defined == Missing Reference: 'P1' is mentioned on line 637, but not defined == Missing Reference: 'CE-A' is mentioned on line 524, but not defined == Missing Reference: 'PE-X' is mentioned on line 524, but not defined == Missing Reference: 'PE-Y' is mentioned on line 524, but not defined == Missing Reference: 'CE-B' is mentioned on line 524, but not defined == Unused Reference: 'RFC4364' is defined on line 740, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 746, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 754, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'RFC5420' is defined on line 765, but no explicit reference was found in the text == Unused Reference: 'RFC4379' is defined on line 772, but no explicit reference was found in the text == Unused Reference: 'RFC4761' is defined on line 776, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 780, but no explicit reference was found in the text == Unused Reference: 'RFC5921' is defined on line 783, but no explicit reference was found in the text == Unused Reference: 'MPLSVPN-ARCH' is defined on line 787, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 22 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Bhargav Bhikkaji 3 Internet-Draft Balaji Venkat Venkataswami 4 Intended Status: Experimental RFC DELL 5 Expires: August 2013 Shankar Raman 6 Gaurav Raina 7 IIT Madras 8 February 25, 2013 10 An Architecture for splicing TE-LSPs in Hierarchical CsC scenarios 11 draft-balaji-mpls-csc-te-lsp-splice-02 13 Abstract 15 Hierarchical Carrier Supporting Carrier deployments involve a Carrier 16 Core which hereinafter is called the Tier-1 provider and two or more 17 VPN sites that are carriers themselves hereinafter called Tier-2 18 providers that offer MPLS VPN services to their own customers. In 19 such cases normally LDP is used to distribute labels amongst the 20 routers (P and PE devices) in the Tier-2 provider's sites. When RSVP 21 based TE-LSPs are constructed to explicitly route traffic for Tier-2 22 ISP's customers from the Tier-2 PEs to the CE of the Tier-1 provider 23 and such TE-LSPs exist on multiple sites of the Tier-2 provider, the 24 Tier-2 ISP may require splicing together through an "auto-match-and- 25 splice-together" facility such that traffic flows from the PE of the 26 Tier-2 ISP through the TE-LSP onto the CE of the Tier-1 ISP and then 27 onto the other site and takes a path through a specific TE-LSP from 28 the CE of the other site to the destination Tier-2 PE and then onto 29 the final customer. 31 This solution offers a lot of advantages such as providing adequate 32 assurance that the bandwidth for the traffic flowing through these 33 spliced TE-LSPs is met. It also provides a explicit routing of the 34 traffic rather than through the regular LDP (which follows IGP) 35 scenarios. Such explicitly routed TE-LSPs would have been constructed 36 taking into account factors such as using under-utilized links for 37 example. Splicing together these TE-LSPs in various sites and doing 38 the splicing on an auto-match based on bandwidth or delay metrics 39 would be a good service to offer to the Tier-2 ISPs customers. 41 This draft outlines a scheme that offers such a feature and service 42 to the Tier-2 ISPs through the addition of certain additional label 43 exchanges and some additional labels such as the RSVP-stitch label 44 and the RSVP-splicing-LDP label in the label stack which can be used 45 to splice together these tunnels. In case of re-optimization of the 46 LSP end-to-end there is a wide variety of choices for the near-end PE 47 to hook up with a suitable far-end tunnel in the other Tier-2 site. 49 Explicit tunnel setup can be obviated by merely choosing from a set 50 of already constructed tunnels based on criterion that may involve 51 various parameters. Also fast-reroute in case of remote tunnel 52 failure is taken care of. 54 Status of this Memo 56 This Internet-Draft is submitted to IETF in full conformance with the 57 provisions of BCP 78 and BCP 79. 59 Internet-Drafts are working documents of the Internet Engineering 60 Task Force (IETF), its areas, and its working groups. Note that 61 other groups may also distribute working documents as 62 Internet-Drafts. 64 Internet-Drafts are draft documents valid for a maximum of six months 65 and may be updated, replaced, or obsoleted by other documents at any 66 time. It is inappropriate to use Internet-Drafts as reference 67 material or to cite them other than as "work in progress." 69 The list of current Internet-Drafts can be accessed at 70 http://www.ietf.org/1id-abstracts.html 72 The list of Internet-Draft Shadow Directories can be accessed at 73 http://www.ietf.org/shadow.html 75 Copyright and License Notice 77 Copyright (c) 2013 IETF Trust and the persons identified as the 78 document authors. All rights reserved. 80 This document is subject to BCP 78 and the IETF Trust's Legal 81 Provisions Relating to IETF Documents 82 (http://trustee.ietf.org/license-info) in effect on the date of 83 publication of this document. Please review these documents 84 carefully, as they describe your rights and restrictions with respect 85 to this document. Code Components extracted from this document must 86 include Simplified BSD License text as described in Section 4.e of 87 the Trust Legal Provisions and are provided without warranty as 88 described in the Simplified BSD License. 90 Table of Contents 92 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 93 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 8 94 1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . 8 95 2.0 Constructing spliced TE-LSPs between the Tier-2 sites . . . 10 96 2.0.1 RSVP-splicing-LDP label . . . . . . . . . . . . . . . . 11 97 2.0.2 RFC 6511 applicability . . . . . . . . . . . . . . . . . 11 98 2.1 Decison at CE-B or the upstream CE in the Tier-2 ISP site. . 11 99 2.1.1 RSVP-stitch label . . . . . . . . . . . . . . . . . . . 12 100 2.2 Across the Carrier's Core . . . . . . . . . . . . . . . . . 12 101 2.3 Decision at PE-Lo . . . . . . . . . . . . . . . . . . . . . 12 102 2.4 Decision at CE-B . . . . . . . . . . . . . . . . . . . . . . 12 103 2.5 Multiplicity of TE-LSP sections . . . . . . . . . . . . . . 13 104 2.6 Illustration . . . . . . . . . . . . . . . . . . . . . . . . 13 105 2.7 Utility . . . . . . . . . . . . . . . . . . . . . . . . . . 16 106 2.8 Tunnel Re-optimization by mere choice and not 107 reconstruction . . . . . . . . . . . . . . . . . . . . . . . 17 108 2.9 Fast-Reroute facility . . . . . . . . . . . . . . . . . . . 17 109 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 19 110 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 19 111 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 112 5.1 Normative References . . . . . . . . . . . . . . . . . . . 19 113 5.2 Informative References . . . . . . . . . . . . . . . . . . 20 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 116 1 Introduction 118 Some ISP customers of the MPLS/VPN backbone may want to provide 119 MPLS/VPN services for their own customers. These Tier-2 ISPs that we 120 will call them henceforth obtain the services for MPLS/VPN from a Top 121 level Carrier which we will henceforth call as a Tier-1 ISP for their 122 connectivity when these Tier-2 ISPs do not have networks that span 123 across the region, between geographical regions or across the globe. 125 This type of connectivity is known as hierarchical VPN sometimes 126 referred to as recursive VPN. Its deployment is similar to the other 127 Carrier's Carrier VPNs except Multi-protocol iBGP is introduced for 128 the distribution of the prefixes and label information between ISP 129 sites. 131 An example topology is provided below... 133 _________ _________ 134 ( ) ( ) 135 ( ISP2 ) ( ISP2 ) 136 ( Customer) ( Customer) 137 ( Paris ) ( London ) 138 ( ) ( ) 139 (_[CE-Pa]_) (_[CE-Lo]_) 140 | | 141 | MP-iBGP session between PE routers | 142 _____|_____ PE-Pa,PE-Lo for VPN-IPv4 prefix ______|______ 143 ( [PE-Pa]..).................................(...[PE-Lo] ) 144 ( Tier-2 ) and Label Exchange ( Tier-2 ) 145 ( ISP2 ) ( ISP2 ) 146 ( Site-A ) ______________________ ( Site-B ) 147 ((1) ) ( ) ( (2)) 148 (______[CE-A]--[PE-X] [PE-Y]-----[CE-B]________) 149 ^ ( . . ) ^ 150 IPv4 Routes. ( ........[P1]........ ) . IPv4 Routes 151 with LDP . ( ) . with LDP 152 Distribution ( Tier-1 ISP1 Core ) Distribution 153 (______________________) 155 Legend : 156 (1) IGP routes with LDP distribution 157 (2) IGP routes with LDP distribution 159 Figure 1: Reference Architecture Diagram 161 Within each Tier-2 ISP site in Figure 1 the PE-Routers PE-Pa and PE- 162 Lo hold VRF routing information for any VPN customers that are 163 attached to the POP at Paris and London. This is no different than 164 the standard MPLS/VPN architecture so VPN-IPv4 prefixes are assigned 165 to customer VPN routes and are distribted between Tier-2 ISP sites 166 using MP-iBGP with BGP extended community attributes (Router Target 167 and Site of Origin). 169 Because each POP site for the Tier-2 ISP at London and Paris may hold 170 several PE routers a full mesh of MP-iBGP is necessary among all PE- 171 routers within the ISP MPLS/VPN topology. However again route 172 reflectors can be deployed to cut down on the number of required 173 peering sessions. In the example shown in Figure 1 it would be 174 possible for example for the Tier-2 ISP2 London and Paris PE-routers 175 to be route reflectors for their own Tier-2 ISP site. One could even 176 deploy totally separate devices and make each PE-router a route 177 reflector client so that MP-iBGP updates can be successfully 178 reflected to all PE-routers that need the VPN information contained 179 within the updates. 181 In the following figure 2 we provide an example of the relevant label 182 assignment for the 146.22.15.0/24 prefix which is learned from a VPN 183 customer of the Tier-2 ISP in the Paris area. 185 _________ _________ 186 ( ) ( ) 187 ( ISP2 ) ( ISP2 ) 188 ( Customer)...146.22.15.0/24 ( Customer) 189 ( Paris ) ( London ) 190 ( ) ( ) 191 (_[CE-Pa]_) (_[CE-Lo]_) 192 | (2) | 193 (1)| MP-iBGP session between PE routers | (10) 194 _____|_____ PE-Pa,PE-Lo for VPN-IPv4 prefix ______|______ 195 ( [PE-Pa]..).................................(...[PE-Lo] ) 196 ( Tier-2 ) and Label Exchange ( Tier-2 ) 197 ( ISP2 (3) ) ( ISP2 ) 198 ( Site-A ) ______________________ ( Site-B ) 199 ((x) ) ( (7) ) ((y) (9)) 200 (______[CE-A]--[PE-X] [PE-Y]-----[CE-B]________) 201 ^ ( . (5) (6) . ) ^ 202 IPv4 Routes. ( ........[P1]........ ) . IPv4 Routes 203 with LDP . ( ) . with LDP 204 Distribution ( Tier-1 ISP1 Core ) Distribution 205 (4) (______________________) (8) 207 Legend : 208 (x) IGP routes with LDP distribution 209 (y) IGP routes with LDP distribution 211 Figure 2: Reference Diagram for normal control plane exchange for 212 HCsC 214 Legend for the control plane exchang3 is as follows : 216 (1) CE-Pa sends update for 146.22.15.0/24 to PE-Pa 218 (2) An MP-iBGP update for Net=146.22.15.0/24 with next hop as PE-Pa 219 and label assignment as 99 is sent to PE-Lo from PE-Pa 221 (3) An IGP + LDP update for Net=PE-Pa with label as pop action is 222 sent to CE-A from PE-Pa 224 (4) The CE-A device sends an update with Net=PE-Pa with NH=CE-A and a 225 label assignment of 1 to PE-X. 227 (7) An MP-iBGP update is sent from PE-X to PE-Y with Net=PE-Pa NH=PE- 228 X and Label as 4. 230 (5) An LDP update goes from PE-X with Net as PE-X and Label as pop 231 action to P1. 233 (6) An LDP update goes from P1 with Net=PE-X and label as 2 to PE-Y 235 (8) An LDP update with Net=PE-Pa and NH=PE-Y with label as 3 from PE- 236 Y to CE-B. 238 (9) An IGP update goes from CE-B with Net=PE-Pa with NH as PE-Y to 239 PE-Lo 241 (10) An LDP Update goes from CE-B to PE-Lo with Net=PE-Pa and label 242 as 5. 244 The figure shows again that labels are advertised both within the 245 MPLS/VPN backbone and within each ISP site, for each of the Tier-2 246 ISP (Tier-1's customer) internal routes. ISP-customer (Tier-2 247 customer) external routes are distributed between the sites as VPN- 248 IPv4 routes. This mean that the iBGP session between sites becomes an 249 MP-iBGP session so that the VPN-IPv4 routes and associated labels can 250 be successfully advertised. 252 The actual traffic flow for a packet destined for a host on the 253 146.22.15.0/24 subnet and arriving at the Tier-2 ISP's PE-Lo router 254 is illustrated in figure 2. 256 _________ _________ 257 ( ) ( ) 258 ( ISP2 ) ( ISP2 ) 259 ( Customer)...146.22.15.0/24 ( Customer) 260 ( Paris ) ( London ) 261 ( ) ( ) 262 (_[CE-Pa]_) (_[CE-Lo]_) 263 | | 264 (8)| MP-iBGP session between PE routers | (1) 265 _____|_____ PE-Pa,PE-Lo for VPN-IPv4 prefix ______|______ 266 ( [PE-Pa]..).................................(...[PE-Lo] ) 267 ( Tier-2 ) and Label Exchange ( Tier-2 ) 268 ( ISP2 (7) ) ( ISP2 ) 269 ( Site-A ) ______________________ ( Site-B ) 270 ( ) ( ) ( (2)) 271 (______[CE-A]--[PE-X] [PE-Y]-----[CE-B]________) 272 ^ ( . (5) (4) . ) ^ 273 IPv4 Routes. ( ........[P1]........ ) . IPv4 Routes 274 with LDP . ( ) . with LDP 275 Distribution ( Tier-1 ISP1 Core ) Distribution 276 (6) (______________________) (3) 278 Figure 2: Reference Diagram for normal Data Plane exchange for HCsC 280 (1) IP packet with IP-DA as 146.22.15.1 281 (2) Label packet with MPLS labels 5,99, IP-DA 146.22.15.1 282 (3) Label packet with MPLS labels 3,99, IP-DA 146.22.15.1 283 (4) Label packet with MPLS labels 2,4,99, IP-DA 146.22.15.1 284 (5) Label packet with MPLS labels 4,99, IP-DA 146.22.15.1 285 (6) Label packet with MPLS labels 1,99, IP-DA 146.22.15.1 286 (7) Label packet with MPLS labels 99, IP-DA 146.22.15.1 287 (8) IP packet with IP-DA as 146.22.15.1 289 1.1 Terminology 291 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 292 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 293 document are to be interpreted as described in RFC 2119 [RFC2119]. 295 1.2 Problem Statement 297 Disparate ISPs or the same ISP could have multiple Tier-2 sites 298 spread across geographies. This will entail that the these disparate 299 sites be interconnected through a Tier-1 ISP who has presence in 300 these disparate geographies and is willing to provide the 301 interconnect service for these Tier-2 sites. 303 Each Tier-2 site could have pre-built TE-LSPs that possess different 304 characteristic with respect to bandwidth, resource color, delay etc. 305 In order that these disparate sites be interconnected by using such 306 pre-built TE-LSPs through matching the characteristics of these TE- 307 LSPs appropriately between a pair of Tier-2 sites there exists a need 308 for a solution that exports RSVP-TE built TE-LSPs in the MP-iBGP / 309 MP-eBGP protocol between such sites through prior arrangement. The 310 solution also requires that such exported TE-LSPs are spliced 311 together with a Tier-1 ISP's Grand Forwarding Adjacency LSP which 312 spans across multiple areas of a Tier-1 ISP/ ISPs (in the case of 313 inter-AS). 315 Thus each Tier-2 site could have pre-built TE-LSP having different 316 characteristics such as 318 - available bandwidth characteristics 319 - Number of hops as a characteristic 320 - Delay bound characteristics. 322 Tier-2 sites do not have capability to choose TE-tunnel in respective 323 remote site based on such characteristics etc.. Similar need exists 324 for Inter-AS scenarios as well with the multiple Tier-1 ISPs serving 325 disparate Tier-2 sites. 327 RSVP-TE tunnels mechanisms are available at Inter-AS level. But there 328 are certain issues with them. 330 - These tunnels are setup end-to-end 331 - Requires administrative permissions across ASes 333 Security issues with respect to requesting LSPs to be setup in one 334 shot from PE in Tier-2 to PE in another Tier-2 is thus manifested. 335 Providers may have policies that prevent LSPs being setup right 336 through to their end customer facing PEs. In case of re-optimization 337 of the LSP end-to-end there is a wide variety of choices for the 338 near-end PE to hookup with a suitable far-end tunnel in the other 339 Tier-2 site. Explicit tunnel setup can be obviated by merely choosing 340 from a set of already constructed tunnels based on criterion that may 341 involve various parameters. 343 To overcome these issues the following draft provides a solution in 344 that problem statement's space. 346 2.0 Constructing spliced TE-LSPs between the Tier-2 sites 348 It is possible that there be requirements to establish TE LSPs for a 349 variety of reasons between the PE routers in the Tier-2 sites for 350 example between PE-Lo and PE-Pa. These variety of reasons could 351 include Traffic engineering necessities that may arise for the sake 352 of allocating a certain amount of bandwidth for sets of traffic from 353 the Tier-2 customer sites or for guaranteeing a certain delay budget 354 or merely for utilizing under-utilized links (which otherwise would 355 not have been used if left to IGP paths). 357 Consider a situation where there exists requirements to establish TE- 358 LSPs between PE-Lo and PE-Pa for traffic direction from PE-Lo towards 359 PE-Pa. 361 These TE-LSP needs to traverse the Tier-1 ISP core. To traverse the 362 core it is possible to envisage that there exists sufficient 363 bandwidth between PE-X and PE-Y. One possibility is to establish a 364 TE-LSP between PE-X and PE-Y and use that LSP as a forwarding 365 adjacency LSP for carrying the traffic over the core. The other 366 possibility is to use normal LDP to carry the traffic over the core. 368 In both cases the TE-LSP established at the Tier-2 Customer sites 369 need to be spliced together. And that splicing should be done 370 automatically with reference to the characteristics that the TE-LSP 371 advertises. In case of using both schemes for traversing the core, 372 the TE-LSP in Site-B needs to be spliced to the section in Site-A. 374 Again it is possible that the section of the TE-LSP in Site-B was 375 constructed independently of Site-A TE-LSP section. The TE-LSP 376 section in Site-B being between PE-Lo and CE-B and the Site-A TE-LSP 377 section between CE-A and PE-Pa. 379 Now there has to be a mechanism of conveying the section information 380 between Site-A and Site-B. For traffic direction from Site-B to Site- 381 A the draft solution that we propose intends to convey this TE-LSP 382 information with TE-LSP characteristics such as bandwidth, delay, 383 cost et... through a MP-iBGP update from CE-A to CE-B. This mechanism 384 conveys the existence of a TE-LSP between PE-Pa and CE-A. 386 For the reverse direction of traffic the MP-iBGP update for the vice- 387 versa occurs. 389 In our case in the diagram Figure 3 the PE-Pa-to-CE-A TE-LSP is 390 advertised to CE-B. This information is thus sent from CE-A to CE-B. 391 This is sent thus as a MP-iBGP update. This MP-iBGP update is sent to 392 the PE-Pa and the PE-Lo Provider Edge routers as well. This is 393 required since the PE-Lo in our example can take a decision to use 394 the TE-LSP or the normal LDP path at its end based on knobs 395 configured or based on certain policy decisions at that time of 396 sending the traffic where such policies could be configured. These 397 policy decisions could be built in as an algorithm with a set of 398 rules. This mechanism is outside the scope of the current document. 400 2.0.1 RSVP-splicing-LDP label 402 CE-B then generates two different labels towards PE-Y one for LDP and 403 another for RSVP-splicing-LDP. The LDP label is used when the packet 404 reaches CE-B towards PE-Y when the labels in the packet are LDP based 405 labels. If the packet arrives with a RSVP Label for the TE-LSP 406 between PE-Lo and CE-B at the head of the stack of labels at CE-B 407 then the RSVP-splicing-LDP label is used. 409 This also means that the MP-iBGP exchange between PE-X and PE-Y has 410 to have two classes of labels one for LDP and another for RSVP- 411 splicing-LDP. 413 Additionally PE-X to CE-A labels have to be of two kinds. One for LDP 414 and another for RSVP-splicing-LDP. 416 2.0.2 RFC 6511 applicability 418 For RSVP tunnels proposed in this mechanism it is important that non- 419 PHP behaviour be observed by the egress LSRs in the Carrier's core 420 and in the TE-LSP sections in the Tier-2 ISP as per [RFC6511]. 422 2.1 Decison at CE-B or the upstream CE in the Tier-2 ISP site. 424 If the CE-B is our example has received MP-iBGP updates about the TE- 425 LSP at the remote site (CE-A to PE-Lo) it can take a decision as to 426 whether it has to use that TE-LSP or use an ordinary LDP based LSP by 427 choosing either the LDP label or the RSVP-splicing-LDP label. MP-iBGP 428 updates can be expected to keep the information of the TE-LSPs at the 429 remote Tier-2 site current by periodically but not too often updating 430 the information through a MP-iBGP update. This MP-iBGP update should 431 have characteristics of the TE-LSP at the remote end. The 432 characteristics relate to bandwidth and/or delay and/or MTU etc. The 433 exact set of characteristics would also include available bandwidth 434 on that TE-LSP. The end-point PE on the remote side connecting to the 435 Tier-2 ISP's customer is also part of the update. In our case the PE- 436 Pa and CE-B will know that to reach the 144.22.15.0/24 prefix there 437 exists a TE-LSP from CE-A to PE-Pa. The MP-iBGP update from CE-A 438 about the TE-LSP section from CE-A to PE-Pa also contains a label 439 called the RSVP-stitch label. This RSVP-stitch label will have to be 440 imposed by the upstream CE-B at the Tier-2 ISP Site-B. 442 2.1.1 RSVP-stitch label 444 When the packet to 144.22.15.1 heads from PE-Lo towards CE-B, the 445 RSVP label for the TE-LSP to be used for that traffic is the topmost 446 label in the packet while the VPN instance label is the second label. 447 Assume that the PE-Lo has chosen to use the TE-LSP with the stitch 448 option in the remote Tier-2 site, then the packets are forwarded on 449 the TE-LSP as specified. At CE-B two things happen. The RSVP label at 450 the head of the stack of labels is swapped with the the RSVP-stitch 451 label. 453 An outer label is added which is the RSVP-splicing-LDP label 454 propositioned by PE-Y to CE-B instead of the regular LDP label. The 455 forwarding tables are spliced with the RSVP-splicing-LDP label to be 456 used if the incoming labeled traffic is exiting out of the RSVP 457 tunnel at CE-B with the RSVP-stitch label. 459 2.2 Across the Carrier's Core 461 This then carries the packet to PE-Y where the outer label which is 462 either a LDP label or a forwarding adjacency TE-LSP RSVP label is 463 added. This makes it four labels in the Carrier's core. Once the 464 packet reaches PE-X the RSVP-stitch label is exposed and the packet 465 is sent to the CE-A with the RSVP-splicing-LDP label at the top of 466 the stack. CE-A on receiving this has already stitched the forwarding 467 action for such a label in its forwarding table to pop the RSVP- 468 splicing-LDP label and swap the RSVP-stitch label so that the TE-LSP 469 section from CE-A to PE-Pa is used. The packet is then sent through 470 the TE-LSP section thereof. This action is programmed whenever a 471 RSVP-splicing-LDP label is the incoming label into the CE-A. 473 The packet then reaches the end of that TE-LSP section on to the 474 Tier-2 Provider's Site-A customer site. 476 2.3 Decision at PE-Lo 478 The decision to send the packets for a prefix through the TE-LSP at 479 Tier-2 Site-B is first made by PE-Lo since it has information that 480 TE-LSP between itself and CE-B exists and that there also exists a 481 TE-LSP section at Site-A between PE-Pa and CE-A. 483 2.4 Decision at CE-B 485 On arriving at CE-B the traffic is also subject to another decision 486 at the CE-B as to whether to use the LDP label or the RSVP-splicing- 487 LDP label. The latter would take the traffic through the TE-LSP 488 section in Site-A of the Tier-2 ISP. 490 Thus policies can be enforced as per section 2.3 and/or 2.4. The 491 flexibility is left to the Tier-2 ISP administrator. The choice is 492 two-fold. 494 2.5 Multiplicity of TE-LSP sections 496 There could be multiple TE-LSP section between CE-A and PE-Pa. These 497 are conveyed through the MP-iBGP updates from CE-A to CE-B. For the 498 reverse direction of traffic the vice-versa applies. So CE-B in our 499 example could choose which one of these TE-LSP sections in Site-A 500 could be the most appropriate. A suitable decision algorithm may be 501 arrived at given the choices to be made at CE-B in our example. 503 2.6 Illustration 505 In other words to diagramatically illustrate the methodology 506 described above we provide the control and data plane exchanges for 507 the same... 509 _________ _________ 510 ( ) ( ) 511 ( ISP2 ) ( ISP2 ) 512 ( Customer)...146.22.15.0/24 ( Customer) 513 ( Paris ) ( London ) 514 ( ) ( ) 515 (_[CE-Pa]_) (_[CE-Lo]_) 516 | (2) | 517 (1)| MP-iBGP session between PE routers | (10) 518 _____|_____ PE-Pa,PE-Lo for VPN-IPv4 prefix ______|______ 519 ( .[PE-Pa]..).................................(...[PE-Lo] ) 520 ( .Tier-2 ) .TE-LSP section details and . ( Tier-2. ) 521 ( .ISP2 (3) ) .consequent Label Exchanges . ( ISP2 . ) 522 ( .Site-A ) . ______________________ . ( Site-B. ) 523 ( ........ ) . ( (7) ) . ( ..... (9)) 524 (______[CE-A]..[PE-X] [PE-Y]---..[CE-B]________) 525 ^ ( . (5) . ) ^ 526 IPv4 Routes. ( ........[P1]........ ) . IPv4 Routes 527 RSVP-splicing ( ) . RSVP-splicing 528 -LDP Distrib. ( Tier-1 ISP1 Core ) . LDP Distrib. 529 (4) (______________________) (8) 531 Figure 3: Reference Diagram for proposed control plane exchange for 532 HCsC with stitch and splice TE-LSP method 534 Assumption is that there exist TE-LSP sections in Site-A and Site-B 535 between CE-A and PE-Pa in the direction specified and between PE-Lo 536 and CE-B in that specified direction. Methods to adopt Non-PHP 537 behaviour at CE-B is to be implemented as per [RFC6511]. 539 We demonstrate the use of the Tier-1 ISP core RSVP TE-LSP that ties 540 together the two TE-LSP sections in Site-A and Site-B in the data 541 plane example. This RSVP TE-LSP too has non-PHP behaviour for its 542 egress LSR PE-X for traffic in the London to Paris direction. The 543 same non-PHP behaviour for the RSVP TE-LSP between CE-A and PE-Pa is 544 also in vogue. 546 Legend for the control plane exchange is as follows : 548 (1) CE-Pa sends update for 146.22.15.0/24 to PE-Pa 550 (2) An MP-iBGP update for Net=146.22.15.0/24 with next hop as PE-Pa 551 and label assignment as 99 is sent to PE-Lo from PE-Pa 553 (2.1) An MP-iBGP update for TE-LSP section between CE-A to PE-Pa 554 describing a RSVP-stitch label 1000 with characteristics of Site-A 555 TE-LSP is sent to CE-B and PE-Lo. 557 (3) An RSVP TE-LSP between CE-A and PE-Pa with label as 500 with Non- 558 PHP behaviour is assumed to exist 560 (4) The CE-A device sends an LDP update with Net=PE-Pa with NH=CE-A 561 and a label assignment of 12 to PE-X where the label 12 is a RSVP- 562 splicing-LDP label. It also sends a normal LDP label for the same 563 FEC. 565 (7) An MP-iBGP update is sent from PE-X to PE-Y with Net=PE-Pa NH=PE- 566 X and Label as 4 where label 4 is identified as a RSVP-splicing-LDP 567 label. 569 (5) An RSVP forwarding Adjacency TE-LSP is assumed to exist between 570 PE-X and PE-Y from latter to former with non-PHP behaviour as per 571 [RFC6511]. The labels between PE-X and P1 is 2001 and PE-Y and P1 is 572 2000. 574 (8) An LDP update with Net=PE-Pa and NH=PE-Y with label as 11 from 575 PE-Y to CE-B where 11 is a RSVP-splicing-LDP label. There is also an 576 LDP update sent for normal LDP for the same FEC. 578 (9) An RSVP TE-LSP between PE-Lo and CE-B with label as 400 with non- 579 PHP behaviour is assumed to exist. 581 (10) null 582 _________ _________ 583 ( ) ( ) 584 ( ISP2 ) ( ISP2 ) 585 ( Customer)...146.22.15.0/24 ( Customer) 586 ( Paris ) ( London ) 587 ( ) ( ) 588 (_[CE-Pa]_) (_[CE-Lo]_) 589 | | 590 (8)| MP-iBGP session between PE routers | (1) 591 _____|_____ PE-Pa,PE-Lo for VPN-IPv4 prefix ______|______ 592 ( [PE-Pa]..).................................(...[PE-Lo] ) 593 ( Tier-2 ) and Label Exchange ( Tier-2 ) 594 ( ISP2 (7) ) ( ISP2 ) 595 ( Site-A ) ______________________ ( Site-B ) 596 ( ) ( ) ( (2)) 597 (______[CE-A]--[PE-X] [PE-Y]-----[CE-B]________) 598 ^ ( . (5) (4) . ) ^ 599 IPv4 Routes. ( ........[P1]........ ) . IPv4 Routes 600 with LDP . ( ) . with RSVP-splicing 601 Distribution ( Tier-1 ISP1 Core ) ..LDP Distrib. 602 (6) (______________________) (3) 604 Figure 4: Reference Diagram for proposed Data Plane exchange for HCsC 605 splicing method 607 Assume TE-LSPs exist between PE-Lo and CE-B in Site-B and CE-A and 608 PE-Pa in Site-A. Also assume a forwarding adjacency LSP constructed 609 using RSVP exists between PE-Y and PE-X in the said direction from Y 610 to X. 612 (1) IP packet with IP-DA as 146.22.15.1 613 (2) Label packet with RSVP label 400,99, IP-DA 146.22.15.1 614 (3) Label packet with MPLS labels 11,1000,99, IP-DA 146.22.15.1 615 (4) Label packet with MPLS labels 2000,4,1000,99, IP-DA 146.22.15.1 616 (5) Label packet with MPLS labels 2001,4,1000,99, IP-DA 146.22.15.1 617 (6) Label packet with MPLS labels 12,1000,99, IP-DA 146.22.15.1 618 (7) Label packet with MPLS labels 500,99, IP-DA 146.22.15.1 619 (8) IP packet with IP-DA as 146.22.15.1 620 _________ _________ 621 ( ) ( ) 622 ( ISP2 ) ( ISP2 ) 623 ( Customer)...146.22.15.0/24 ( Customer) 624 ( Paris ) ( London ) 625 ( ) ( ) 626 (_[CE-Pa]_) (_[CE-Lo]_) 627 | | 628 (8)| MP-iBGP session between PE routers | (1) 629 _____|_____ PE-Pa,PE-Lo for VPN-IPv4 prefix ______|______ 630 ( [PE-Pa]..).................................(...[PE-Lo] ) 631 ( Tier-2 ) and Label Exchange ( Tier-2 ) 632 ( ISP2 (7) ) ( ISP2 ) 633 ( Site-A ) ______________________ ( Site-B ) 634 ( ) ( ) ( (2)) 635 (______[CE-A]--[PE-X] [PE-Y]-----[CE-B]________) 636 ^ ( . (5) (4) . ) ^ 637 IPv4 Routes. ( ........[P1]........ ) . IPv4 Routes 638 with LDP . ( ) . with LDP 639 Distribution ( Tier-1 ISP1 Core ) Distribution 640 (6) (______________________) (3) 642 Figure 5: Reference Diagram for Data Plane exchange for proposed 643 scheme with HCsC with LDP labels in the Carrier's Core. 645 Note : Control plane has not been shown for sake of brevity. 647 Assume TE-LSPs exist between PE-Lo and CE-B in Site-B and CE-A and 648 PE-Pa in Site-A. Also assume there is no forwarding adjacency LSP 649 constructed using RSVP exists between PE-Y and PE-X in the said 650 direction from Y to X. There are only LDP labels assigned in that 651 direction. 653 (1) IP packet with IP-DA as 146.22.15.1 654 (2) Label packet with RSVP label 400,99, IP-DA 146.22.15.1 655 (3) Label packet with MPLS labels 11,1000,99, IP-DA 146.22.15.1 656 (4) Label packet with MPLS labels 3000,4,1000,99, IP-DA 146.22.15.1 657 (5) Label packet with MPLS labels 4,1000,99, IP-DA 146.22.15.1 658 (6) Label packet with MPLS labels 12,1000,99, IP-DA 146.22.15.1 659 (7) Label packet with MPLS labels 500,99, IP-DA 146.22.15.1 660 (8) IP packet with IP-DA as 146.22.15.1 662 2.7 Utility 664 It is possible to envisage the following advantages as coming out of 665 this proposed architecture. 667 o TE-LSPs in multiple sites may be needed to be spliced together. 669 o Such TE-LSPs may have been constructed to give a specific QoS for 670 select FECs / Prefixes. 672 o Without this scheme that ties the TE-LSP sections in multiple 673 sites together, traffic may pass through TE-LSP with a given QoS in 674 one site and may not pass through similar TE-LSP sections in other 675 sites. 677 o Splicing them together with a TE-LSP in the Tier-1 ISP gives the 678 traffic a complete QoS experience from start to finish. 680 o Multiple TE-LSP sections with different characteristics may exist 681 in multiple sites. As per MP-iBGP updates coming in the CE devices in 682 the Tier-2 ISP sites may choose one of them to provide the said QoS 683 to such traffic. 685 o The decision / choice to use either LDP in the sites and/or in the 686 Carrier's core may be done by suitable algorithms that sense 687 degradation in delay or bandwidth or a cost metric. 689 2.8 Tunnel Re-optimization by mere choice and not reconstruction 691 Through merely choosing from an available choice of multiple TE- 692 tunnel sections in the other Tier-2 site the appropriate far-end 693 tunnel can be hooked up with and re-signalling of the entire tunnel 694 can be obviated. By merely matching the characteristics with the 695 criterion applied a suitable label that will ensure choice of the 696 far-end tunnel can be applied. This does obviate the need for re- 697 construction of the tunnel in the far-end site. Suitable tunnels 698 could have been constructed a-priori for this very purpose before the 699 choice is made. 701 2.9 Fast-Reroute facility 703 A quicker fast re-route facility can be ensured if the BGP 704 advertisement of the TE-Tunnel in the far-end site withdraws it from 705 the near-end site. If the BGP advertisement is too late regular RSVP 706 messaging that is targeted at the head end of the tunnel could inform 707 such a head-end of the need to switch over to another tunnel and an 708 appropriate choice can be made of the suitable label to ensure this. 710 Alternate tunnels with their respective suitable labels to impose 711 could be chosen well in advance and the near-end PE in the Tier-2 712 site closest to the Tier-1 site could run a BFD session with the far- 713 end PEs in the far-end Tier-2 sites to check the health of the far- 714 end tunnel. When the BFD session fails and reports an error in the 715 health of the far-end tunnel then the appropriate alternate far-end 716 tunnel could be chosen and a suitable label imposed at the near-end 717 to facilitate choice of the alternate far-end tunnel. 719 3 Security Considerations 721 No additional security considerations exist except those that apply 722 already in the current specifications. 724 4 IANA Considerations 726 MP-iBGP PDU formats for TE-LSP characteristics and for passing the 727 RSVP-stitch label need to be added to this document. 729 Changes to LDP updates to indicate plain LDP labels and RSVP- 730 splicing-LDP labels need to be incorporated. A single bit or type / 731 code value needs to indicate whether the LDP label exchanged is 732 either a LDP label or a RSVP-splicing-LDP label. 734 These will be done in the future versions of the document. 736 5 References 738 5.1 Normative References 740 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 741 Networks (VPNs)", RFC 4364, February 2006. 743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 744 Requirement Levels", BCP 14, RFC 2119, March 1997. 746 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 747 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 748 Functional Specification", RFC 2205, September 1997. 750 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 751 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 752 Tunnels", RFC 3209, December 2001. 754 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 755 Switching (GMPLS) Signaling Resource ReserVation Protocol- 756 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 757 January 2003. 759 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 760 Yasukawa, Ed., "Extensions to Resource Reservation 761 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 762 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 763 2007. 765 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 766 Ayyangarps, "Encoding of Attributes for MPLS LSP 767 Establishment Using Resource Reservation Protocol Traffic 768 Engineering (RSVP-TE)", RFC 5420, February 2009. 770 5.2 Informative References 772 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 773 Label Switched (MPLS) Data Plane Failures", RFC 4379, 774 February 2006. 776 [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private 777 LAN Service (VPLS) Using BGP for Auto-Discovery and 778 Signaling", RFC 4761, January 2007. 780 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 781 Networks", RFC 5920, July 2010. 783 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 784 L., and L. Berger, "A Framework for MPLS in Transport 785 Networks", RFC 5921, July 2010. 787 [MPLSVPN-ARCH] Jim Guichard et.al, MPLS and VPN Architectures, ISBN- 788 1-58705-002-1 790 [RFC6511] Zafar Ali et.al, Non-Penultimate Hop Popping Behavior and 791 Out-of-Band Mapping for RSVP-TE Label Switched Paths 793 Authors' Addresses 795 Bhargav Bhikkaji 796 Dell-Force10, 797 350 Holger Way, 798 San Jose, CA 799 U.S.A 801 Email: Bhargav_Bhikkaji@dell.com 803 Balaji Venkat Venkataswami 804 Dell-Force10, 805 Olympia Technology Park, 806 Fortius block, 7th & 8th Floor, 807 Plot No. 1, SIDCO Industrial Estate, 808 Guindy, Chennai - 600032. 809 TamilNadu, India. 810 Tel: +91 (0) 44 4220 8400 811 Fax: +91 (0) 44 2836 2446 813 EMail: BALAJI_VENKAT_VENKAT@dell.com 815 Shankar Raman 816 Department of Computer Science and Engineering 817 IIT Madras, 818 Chennai - 600036 819 TamilNadu, 820 India. 822 EMail: mjsraman@cse.iitm.ac.in 824 Prof.Gaurav Raina 825 Department of Electrical Engineering, 826 IIT Madras, 827 Chennai - 600036, 828 TamilNadu, 829 India. 831 EMail: gaurav@ee.iitm.ac.in