idnits 2.17.1 draft-mjsraman-pce-inter-as-p2mp-protect-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 89 has weird spacing: '...rations where...' == Line 98 has weird spacing: '...eration insta...' == Line 103 has weird spacing: '...stances which...' == Line 106 has weird spacing: '...S cases such ...' == Line 123 has weird spacing: '...nstance excep...' == (2 more instances...) -- The document date (January 25, 2013) is 4108 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 116, but not defined == Unused Reference: 'KEYWORDS' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 446, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'RFC5151' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'RFC4920' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'RFC4726' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC4206' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC5150' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC5331' is defined on line 495, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 23 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Shankar Raman 3 Internet draft Balaji Venkat 4 Intended Status: Experimental RFC Gaurav Raina 5 Expires: July 2013 I.I.T, Madras 6 January 25, 2013 8 Constructing protection paths for inter-AS, inter-sub-AS P2MP TE-LSPs 9 draft-mjsraman-pce-inter-as-p2mp-protect-03 11 Abstract 13 Constructing primary and backup explicit path Point-to-Multipoint 14 Label Switched Paths is important from the point of view of providing 15 protection switching in case the primary fails. 17 It is absolutely essential that the backup P2MP LSPs constructed do 18 not share risk with any of the links and nodes of the primary path. 19 In the case of inter-AS P2MP TE-LSPs or in the case of inter-sub-AS 20 (in the case of BGP-Confederations being deployed) P2MP TE-LSPs where 21 BGP confederations are deployed within an AS, such protection 22 switching can be provided by calculating primary and backup multicast 23 distribution trees (read P2MP TE-LSPs) that dont intersect with each 24 other. 26 In this paper we propose a method by which inter-sub-AS P2MP TE-LSPs 27 (hence even inter-AS P2MP TE-LSPs) can be constructed by first 28 finding the AS level topology of the network (be it inter-AS or 29 inter-sub-AS within a single AS) in question and secondly to compute 30 the paths in such a way that they dont intersect or if necessary in 31 the worst case partially intersect each other. The proposed scheme is 32 explained with an example and subsequent discussion is done to 33 elucidate its benefits to multicast in particular. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as 43 Internet-Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/1id-abstracts.html 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html 56 Copyright and License Notice 58 Copyright (c) 2013 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2 Methodology of the proposal . . . . . . . . . . . . . . . . . . 3 76 3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.1 Discussion of Algorithms to be used . . . . . . . . . . . . 9 78 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 11 79 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 80 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 6.1 Normative References . . . . . . . . . . . . . . . . . . . 11 82 6.2 Informative References . . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 85 1 Introduction 87 In the context of P2MP TE-LSPs being constructed for carriage of 88 multicast traffic across multiple areas within a given AS employing 89 BGP confederations where such an autonomous system may comprise of 90 more than one BGP confederation instance, and if such multicast 91 traffic is mission critical traffic then it would be most useful to 92 have backup protection trees (where such trees represent entire P2MP 93 TE-LSPs rooted at the same BGP confederation instance as the primary) 94 or sub-trees which cover certain areas of the primary P2MP TE-LSP. 95 The intent is to provide a solution whereby a backup protection P2MP 96 TE-LSP can be laid out in such a way that the set of BGP 97 confederation instances traversed by the primary (except say for the 98 egress BGP confederation instances) inter-sub-AS P2MP TE-LSP is not 99 traversed at all by the backup P2MP TE-LSP. It is also possible that 100 if such a totally distinct backup TE-LSP is not possible, then an 101 effort be made where possible to construct a partially disjoint 102 backup P2MP TE-LSP which tries to avoid to the extent possible those 103 BGP confederation instances which fall in the primary. 105 While this type of a solution is available in the unicast world 106 applying to inter-AS cases such a solution doesn't seem to have 107 been proposed for the multicast world for inter-AS P2MP TE-LSPs or 108 for cases within an autonomous system in which BGP conferderations 109 are deployed. 111 1.1 Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2 Methodology of the proposal 119 Assume that a centralized path calculation engine is available as a 120 facility in the head end BGP confederation instance of the P2MP TE- 121 LSP. And this centralized PCE has a backup PCE that does pretty much 122 the same work as the primary PCE in the head end BGP confederation 123 instance except that it is not contacted for path calculation 124 requests while the active is still up. At the active PCE the 125 following happens. The intention at the active PCE is to gather all 126 routes advertised by BGP peers internal and external/internal (a.k.a 127 EIBGP used for confederations) and collect from each of these routes 128 the AS path information attribute (which is a mandatory well-known) 129 and from each of these AS path info attributes which we will call 130 strands from now on, an entire BGP-confederation-instance-Level 131 topology of the AS involved (in the case of inter-AS the internet) is 132 captured to the extent possible. These strands give us information 133 about sections of a BGP-confederation-instance level graph, where 134 each BGP-confederation-instance is considered to be a node and the 135 edge is connectivity between two or more such confederation- 136 instances. Where a set of BGP-confederation-instances are consecutive 137 in a strand they are assumed to be connected to each other. 139 It is to be noted that the information about such strands may come 140 from iBGP, eiBGP, MBGP (in the case of inter-AS level) (sometimes 141 known as Multi-protocol BGP used for multicast) if it carries AS path 142 information. After the BGP-confederation-instance level topology of 143 the immediate neighborhood of the ingress BGP-confederation instance 144 and the egress BGP-confederation-instances to which the multicast 145 subscribers connect to, has been constructed, the P2MP TE-LSP 146 calculation algorithm is run, that takes into account a path in the 147 topology that is most optimal to help and connect the source to the 148 destinations / receivers. It is possible that source and receivers 149 who may be distributed across multiple BGP-confederation-instances in 150 the neighborhood are multihomed in that they have more than one BGP- 151 confederation instance to which they are connected to. This is 152 particularly of interest to the algorithm presented in this invention 153 (in summary) because the backup P2MP TE-LSP needs to be spread out 154 across links that are disjoint from the primary P2MP TE-LSP to the 155 extent possible and multi-homing in this case helps a great deal. 157 Once the primary has been built and the secondary is sought to be 158 built, the invention proposed would take into account multi-homing 159 characteristics of the egress BGP-confederation instances to their 160 respective receivers (which may be enterprise networks / sites) and 161 build a totally disjoint P2MP TE-LSP or if that is not possible a 162 partially disjoint P2MP TE-LSPs. It is also possible that manual 163 policies may be stated in a suitable format to avoid certain BGP- 164 confederation-instances in the calculation of either a totally 165 disjoint or partially disjoint backup P2MP TE-LSP. 167 It is assumed that RSVP-TE would be used to build such primary and 168 secondary P2MP TE-LSPs be they disjoint or partially disjoint. 170 Building a BGP-confederation-instance topology of the immediate 171 neighborhood of the ingress and egress BGP-confederation-instance for 172 a multicast tree to carry one or more streams of mcast traffic 173 through such a tree. 175 Here the term AS refers to a BGP-confederation-instance. 177 Prefix-A: AS-Path Info: AS1 AS2 AS4 178 Prefix-B: AS-Path Info: AS2 AS3 AS4 179 Prefix-C: AS-Path Info: AS2 AS5 AS6 and so on. 181 Figure 1.0 Strand obtained from a subgraph of the AS having 182 confederations 184 Given the above three strands of information we could build out the 185 following graph. 187 AS5---------> AS6 188 | 189 AS1 -----> AS2 --------> AS4 190 | / 191 --------> AS3 193 Figure 2.0 Strands put together to form a graph of the AS with 194 confederations 196 If we extrapolate this to a number of such prefixes and their 197 respective AS paths we could end up discovering the BGP- 198 confederation-instance level topology for a greater radius than is 199 otherwise possible with the ingress BGP-confederation-instance to 200 which the source is connected as the center. 202 Multi-homing links appear as duplicate edges between receivers / 203 source to their respective egress / ingress BGP-confederation- 204 instances. Thus building out disjoint and partially disjoint P2MP TE- 205 LSPs using RSVP-TE is a helpful technique in protecting mission 206 critical multicast traffic on the primary by obviating the need for 207 fate-sharing of the path that such traffic takes to the extent 208 possible. 210 Assume that the following BGP-confederation-instance topology in the 211 vicinity of the sender / senders is computed. 213 +----------------+ 214 / V 215 / +----> (AS2) ------> (AS3)<--(RcvrB) 216 / / \ | 217 / / \ +------+ 218 / / \V 219 (source/s)--->(AS1)------> (AS5) ------> (AS4)<-(RcvrA) 220 \ /\ / 221 \ ----------+ \ / 222 \ / \ / 223 (AS6)----> (AS7) ------> (AS8)<+ 225 Figure 3.0 Strands put together to form a graph of the AS with 226 confederations 228 In the above diagram you can see that the source/sources are 229 connected using a multi homed connections to the same ISP through 230 BGP-confederation instance AS1 and AS2. Similarly there are two 231 Receiver sites RcvrA and RcvrB that are multihomed to TWO BGP- 232 confederation-instances for RcvrB to AS3 and AS4 and for RcvrA to AS4 233 and AS8 respectively. 235 Given that the path calculation engine in AS1 BGP-confederation- 236 instance is given this picture as it absorbs the AS paths and builds 237 out the BGP-confederation-instances level topology, there are at 238 least 2 possible completely (to the maximum extent possible) disjoint 239 P2MP TE-LSPs possible. Note here of course that the egress BGP- 240 confederation-instance sometimes prevents a totally disjoint P2MP TE- 241 LSP since the two up-until-the-egress-BGP-confederation-instance 242 totally P2MP TE-LSPs may be need to merge to enter the receiver 243 domains / sites. 245 They are illustrated below. 247 Primary P2MP TE-LSP advised could be as illustrated by the dotted 248 lines... 250 +----------------+ 251 / V 252 / +----> (AS2) ------> (AS3)<--(RcvrB) 253 / / \ | 254 / / \ +------+ 255 / / \V 256 (source/s)...>(AS1)------> (AS5) ------> (AS4)<-(RcvrA) 257 . .\ / 258 . ........... \ / 259 . . \ / 260 (AS6).....>(AS7) .......>(AS8)<+ 262 Figure 4.0 Strands put together to form a graph of the AS with 263 confederations 265 Secondary P2MP TE-LSP advicsed could be as illustrated by the dotted 266 lines... 267 .................. 268 . V 269 . +----> (AS2).......> (AS3)<--(RcvrB) 270 . / . | 271 . / . +------+ 272 . / .V 273 (source/s)--->(AS1)------> (AS5) ------> (AS4)<-(RcvrA) 274 \ /\ / 275 \ ----------+ \ / 276 \ / \ / 277 (AS6)----> (AS7) ------> (AS8)<+ 279 It is important to note that multicast P2MP TE-LSPs constructed are 280 considered to be stitched sections of unicast paths and may include 281 multicast topologies reserved for multicast use alone that may have 282 been advertised by Multi-protocol BGP just for multicast purposes (in 283 the case of inter-AS). The normal mechanism of discovering receivers 284 could be employed. 286 It is to be noted that while constructing the BGP-confederation- 287 instance-Level topology the routes which have been advertised in BGP 288 that carry multicast NLRIs can be preferred and such inter-BGP- 289 confederation-instance links can be given a higher priority for 290 constructing the P2MP TE-LSPs. Please read the term AS in the 291 following paras to represent a BGP-confederation instance. 293 It is to be noted that this applies to centralized schemes of path 294 calculations. What is being calculated is a tree of ASes that form a 295 P2MP tree where each node can conceptualized as an AS and each edge 296 the border link connecting one AS to another to carry multicast 297 traffic from several sources located at the head end ingress AS to 298 several receiver nodes connected to egress ASes. We will call this 299 calculated tree as a P2MP AS tree. Once the tree is calculated the 300 PCE in the head end / ingress AS through which sources connect 301 calculates the intra-AS P2MP path (the literal P2MP TE-LSP within the 302 AS) within that ingress AS and hands off the elements in the P2MP AS 303 tree in suitable form to the branch ASes which branch off from the 304 ingress AS. This is followed as the information about the elements of 305 the P2MP AS tree are handed off at branches from the PCE of one AS to 306 another until the final inter-AS P2MP literal TE-LSP is complete. The 307 backup P2MP AS tree is constructed as well and the same procedure is 308 followed. This completes the construction of the primary and the 309 backup P2MP AS Trees. 311 The failover mechanism could be derived from any one of the available 312 mechanisms in existence or a novel method for failover could also be 313 deduced. But that is outside the scope of this document. 315 This method could be applied for multicast traffic to be transported 316 through L3VPNs and L2VPNs as well through such inter-AS tree 317 construction of a P2MP AS tree. Also this method of constructing 318 inter-AS disjoint P2MP AS trees is independent of how the egress ASes 319 and the ingress AS are discovered. The method of such discovery is 320 left to existing mechanisms. The primary input to the invention 321 proposed is a list of ingress AS and their respective egress ASes. 322 The other input to the construction of P2MP AS tree part of the 323 invention of course is the BGP-confederation-AS-instance level 324 topology (in case of inter-AS the AS level topology of the 325 neighborhood). 327 It is also possible to apply policies in such a way that the 328 construction of the P2MP AS tree is done in a partially disjoint 329 fashion. That is if there exist certain policies that dictate that a 330 given AS in the path of the P2MP AS tree is to be present in both the 331 primary and backup P2MP AS trees, then it would be applied at the PCE 332 and the resultant tree would contain that AS as policy dictates. Thus 333 the mechanism could churn out disjoint (totally) P2MP AS trees or 334 partially disjoint P2MP AS trees depending on policy dictats. 336 3 Discussion 338 A centralized picture of a AS level topology of the immediate 339 vicinity of the egress and ingress ASes of a multicast tree to be 340 built using a P2MP TE LSP, helps build a backup P2MP TE-LSP without 341 traversing wherever possible the ASes in the primary for the backup 343 Backup / protection switching is a lot more reliable since the fate- 344 sharing is precluded to the maximum extent possible. 346 Also the multi-homing characteristics of the sites / receivers as 347 well as the multi-homing characteristics of the source to its ingress 348 PEs which may be located in different ISP ASes helps in building out 349 a disjoint path that may well help in avoid in fate-sharing if an 350 edge between two ASes or an AS itself goes down. 352 Whether it be OPTIONS A,B or C as listed in the inter-AS RFCs the 353 method we propose can be used to calculate the P2MP AS tree and the 354 actual construction left to those methods applying to those options 355 respectively. 357 Multicast NLRI information could be used to give priority to routes 358 learnt in that fashion and AS path information used to construct the 359 P2MP AS tree may be favourably passed through ASes listed within it. 360 Thus if there exist in-congruent multicast and unicast topologies 361 then this method could use the appropriate multicast topology hints 362 apart from using the unicast topology information for constructing 363 P2MP AS trees that are more suited to multicast topology hints 364 provided. 366 AS sequences which are not ordered ASes representing AS paths toward 367 a destination may be dropped from consideration while constructing 368 the topology of ASes in the immediate neighborhood or in toto. 370 This proposal will also be applicable to ASes which are independent 371 administrative domains in a literal sense (as against BGP- 372 confederation instances) as outlined. 374 3.1 Discussion of Algorithms to be used 376 The basic first cut algorithm that can be used for implementing this 377 scheme is to account or collate the list of ASes the primary P2MP TE- 378 LSP has passed through. These set of ASes can be enclosed in a set 379 EXCLUDE_ASes and the algorithm for the secondary P2MP TE-LSP run with 380 the constraint that any of the elements / ASes in this set are to be 381 avoided. The set EXCLUDE_ASes is ordered with the branch points in 382 order of traversal from the egress AS to the source ASes where the 383 receivers are located. So the first check is applied for the elements 384 / ASes in the beginning of the EXCLUDE_ASes set working backwards 385 from the receivers to the source ASes. Only in cases where disjoint 386 paths are not possible will the overlap occur. 388 Another way is to weight the edges in the primary P2MP TE-LSP with 389 higher weights and simply run the algorithm on the topology again. If 390 the CSPF algorithm finds edges which are high it can be made to avoid 391 such nodes and edges thus excluding the ASes in the primary path. The 392 weights that can be assigned for the primary P2MP tree edges is 1/n 393 where n was the lower weight for these edges when the primary P2MP 394 LSP was constructed. All the edges in the graph are assigned 1/n as 395 well. This way the lowest weights of the previous run become the 396 higher weights of the secondary run. Once this is done one could use 397 graph clipping and rejoining as explained below. This algorithm too 398 can run backwards from the egress ASes to the source AS. 400 Another way is to use graph clipping and rejoining without coupling 401 with the previous algorithm. The primary path ASes are simply clipped 402 along with the edges from the graph at the PCE and the algorithm run 403 again to build a P2MP TE-LSP covering all receivers. Notably if the 404 receivers are multi-homed the primary P2MP TE-LSP ASes can be removed 405 first for such cases. If they are single-homed then it would be 406 worthwhile retaining such egress ASes for the second run. The re-run 407 can then try to build the tree, and if incrementally such an attempt 408 fails those ASes in the Primary P2MP TE-LSP which are necessarily 409 needed in the secondary P2MP tree can be added to the secondary tree 410 till the completion of the secondary P2MP TE-LSP occurs. So the CSPF 411 would operate on the graph clipping first and then rejoining those 412 ASes without which a secondary cannot be built. This again could be 413 run backwards from the egress AS to the source AS. 415 An intermediary meeting point akin to the Rendezvous point can be 416 chosen such that the primary RP AS is disjoint from the secondary RP 417 AS. Working backwards this will in most cases produce the optimal 418 result. Further proof of this algorithm will be furnished in future 419 versions of this document. 421 4 Security Considerations 423 When receiving BGP updates from BGP-confederation-instances the PCE 424 or the head end which is expected to do the calculation of the 425 totally disjoint or partially disjoint P2MP TE-LSP paths MUST ensure 426 the authenticity of the updates received from other BGP- 427 confederation-instances through existing mechanisms that assure that 428 the updates are not spoofed thus misleading the receiver of such 429 updates. No additional security hole is seen under these 430 circumstances apart from the above. 432 5 IANA Considerations 434 No IANA requirements exist as of the time of writing of this draft. 436 6 References 438 6.1 Normative References 440 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 443 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 444 1 1995. 446 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 447 April 1 1996. 449 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 450 Yasukawa, Ed., "Extensions to Resource Reservation 451 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 452 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 453 2007. 455 [RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter- 456 Domain MPLS and GMPLS Traffic Engineering -- Resource 457 Reservation Protocol-Traffic Engineering (RSVP-TE) 458 Extensions", RFC 5151, February 2008. 460 [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., 461 and G. Ash, "Crankback Signaling Extensions for MPLS and 462 GMPLS RSVP-TE", RFC 4920, July 2007. 464 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 465 Networks", RFC 5920, July 2010. 467 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 468 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 469 Tunnels", RFC 3209, December 2001. 471 6.2 Informative References 473 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 474 RFC 3514, April 1 2003. 476 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 477 Acronyms", RFC 5513, April 1 2009. 479 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 480 2009. 482 [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework 483 for Inter-Domain Multiprotocol Label Switching Traffic 484 Engineering", RFC 4726, November 2006. 486 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 487 Hierarchy with Generalized Multi-Protocol Label Switching 488 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 490 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 491 "Label Switched Path Stitching with Generalized 492 Multiprotocol Label Switching Traffic Engineering (GMPLS 493 TE)", RFC 5150, February 2008. 495 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 496 Label Assignment and Context-Specific Label Space", 497 RFC 5331, August 2008. 499 Authors' Addresses 501 Shankar Raman 502 Department of Computer Science and Engineering 503 I.I.T Madras, 504 Chennai - 600036 505 TamilNadu, 506 India. 508 EMail: mjsraman@cse.iitm.ac.in 510 Balaji Venkat Venkataswami 511 Department of Electrical Engineering, 512 I.I.T Madras, 513 Chennai - 600036, 514 TamilNadu, 515 India. 517 EMail: balajivenkat299@gmail.com 519 Prof.Gaurav Raina 520 Department of Electrical Engineering, 521 I.I.T Madras, 522 Chennai - 600036, 523 TamilNadu, 524 India. 526 EMail: gaurav@ee.iitm.ac.in