idnits 2.17.1 draft-chen-mpls-p2mp-egress-protection-06.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 4295 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC3692' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'P2MP FRR' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 519, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'P2MP FRR' Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Chen 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track N. So 5 Expires: January 17, 2013 Tata Communications 6 A. Liu 7 Ericsson 8 L. Liu 9 KDDI R&D Lab Inc. 10 July 16, 2012 12 Extensions to RSVP-TE for P2MP LSP Egress Local Protection 13 draft-chen-mpls-p2mp-egress-protection-06.txt 15 Abstract 17 This document describes extensions to Resource Reservation Protocol - 18 Traffic Engineering (RSVP-TE) for locally protecting egress nodes of 19 a Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched 20 Path (LSP) in a Multi-Protocol Label Switching (MPLS) and Generalized 21 MPLS (GMPLS) network. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 17, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 60 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. An Example of Egress Local Protection . . . . . . . . . . 4 62 4.2. Set up of Backup sub LSP . . . . . . . . . . . . . . . . . 5 63 4.3. Forwarding State for Backup sub LSP(s) . . . . . . . . . . 6 64 4.4. Detection of Egress Node Failure . . . . . . . . . . . . . 6 65 5. Egress Local Protection with FRR . . . . . . . . . . . . . . . 7 66 6. Representation of a Backup Sub LSP . . . . . . . . . . . . . . 7 67 6.1. EGRESS_BACKUP_SUB_LSP Object . . . . . . . . . . . . . . . 7 68 6.1.1. EGRESS_BACKUP_SUB_LSP IPv4 Object . . . . . . . . . . 8 69 6.1.2. EGRESS_BACKUP_SUB_LSP IPv6 Object . . . . . . . . . . 8 70 6.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object . . . . . . 9 71 7. Path Message . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7.1. Format of Path Message . . . . . . . . . . . . . . . . . . 9 73 7.2. Processing of Path Message . . . . . . . . . . . . . . . . 10 74 8. Processing of Resv Message . . . . . . . . . . . . . . . . . . 11 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 79 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 RFC 4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" 85 describes two methods for protecting P2P LSP tunnels or paths at 86 local repair points. The first method is a one-to-one protection 87 method, where a detour backup P2P LSP for each protected P2P LSP is 88 created at each potential point of local repair, which is an 89 intermediate node between the ingress node and the egress node of the 90 protected LSP. The second method is a facility bypass backup 91 protection method, where a bypass backup P2P LSP tunnel is created 92 using MPLS label stacking to protect a potential failure point for a 93 set of P2P LSP tunnels. The bypass backup tunnel can protect a set 94 of P2P LSPs having similar backup constraints. 96 RFC 4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to 97 use the one-to-one protection method and facility bypass backup 98 protection method to protect a link or intermediate node failure on 99 the path of a P2MP LSP. However, there is no mention of locally 100 protecting any egress node failure in a protected P2MP LSP. 102 An existing method for protecting the egress nodes of a P2MP LSP sets 103 up a backup P2MP LSP from a backup ingress node to the backup egress 104 nodes, where each egress node is paired with a backup egress node and 105 protected by the backup egress node. The backup P2MP LSP carries the 106 same traffic as the P2MP LSP at the same time. A traffic receiver 107 from the P2MP LSP is normally connected to an egress node and its 108 paired backup egress node. It receives the traffic from the egress 109 node in normal situations. 111 The receiver selects the egress or backup egrss node for receiving 112 the traffic according to the route to the source through RPF. In a 113 normal situation, it selects the egress node. When the egress node 114 fails, it selects the backup egress for receiving the traffic since 115 the route to the source through the egress node is gone and the route 116 to the source through the backup egress node is active. 118 The main disadvantage of this method is that double network resources 119 such as double bandwidths are used for protecting the egress nodes 120 since the backup P2MP LSP consumes the same amount of network 121 resource as the primary P2MP LSP. The impact on network efficiency 122 can be significant in case of large P2MP deployments. 124 This document proposes a new method to locally protect the egress 125 nodes of a P2MP LSP, which is called Egress Local Protection. It 126 specifies the mechanism and extensions to RSVP-TE for locally 127 protecting an egress node of a Traffic Engineered (TE) point-to- 128 multipoint (P2MP) Label Switched Path through using a backup P2MP sub 129 LSP. The new method overcomes the disadvantages described above. 131 The same extensions and mechanism can also be used to protect the 132 egress node of a TE P2P LSP. 134 2. Terminology 136 This document uses terminologies defined in RFC 2205, RFC 3031, RFC 137 3209, RFC 3473, RFC 4090, RFC 4461, and RFC 4875. 139 3. Conventions Used in This Document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119. 145 4. Mechanism 147 This section briefly describes a solution that locally protects an 148 egress node of a P2MP LSP through using a backup P2MP sub LSP. We 149 first show an example, and then present different parts of the 150 solution, which includes the creation of the backup sub LSP, the 151 forwarding state for the backup sub LSP, and the detection of a 152 failure in the egress node. 154 4.1. An Example of Egress Local Protection 156 Figure 1 below illustrates an example of using backup sub LSPs to 157 locally protect egress nodes of a P2MP LSP. The P2MP LSP is from 158 ingress node R1 to three egress nodes: L1, L2 and L3. It is 159 represented by double lines in the figure. 161 La, Lb and Lc are the designated backup egress nodes for the egress 162 nodes L1, L2 and L3 of the P2MP LSP respectively. In order to 163 distinguish an egress node (e.g., L1 in the figure) and a backup 164 egress node (e.g., La in the figure), an egress node is called a 165 primary egress node in the follwing description. 167 The backup sub LSP used to protect the primary egress node L1 is from 168 its previous hop node R3 to the backup egress node La. The backup 169 sub LSP used to protect the primary egress node L2 is from its 170 previous hop node R5 to the backup egress node Lb. The backup sub 171 LSP used to protect the primary egress node L3 is from its previous 172 hop node R5 to the backup egress node Lc via the intermediate node 173 Rc. 175 During normal operation, the traffic transported by the P2MP LSP is 176 forwarded through R3 to L1, then delivered to its destination CE1. 177 When the failure of L1 is detected, R3 forwards the traffic to the 178 backup egress node La, which then delivers the traffic to its 179 destination CE1. The time for switching the traffic after L1 fails 180 is within tens of milliseconds. 182 L1's failure CAN be detected by a BFD session between L1 and R3. 184 [R2]=====[R3]=====[L1]----[CE1] 185 // \ / 186 // \ / 187 // \___[La]_/ 188 // 189 // 190 // 191 // 192 +---[R1]====[R4]====[R5]=====[L2]----[CE2] 193 | |\\ \ / 194 | | \\ \ / 195 [S]--| | \\ \__[Lb]_/ 196 | | \\ 197 | | \\ 198 | \\ 199 | \\ 200 | \\ 201 | [L3]----[CE3] 202 | / 203 | / 204 [Rc]_______[Lc]_/ 206 Figure 1: P2MP sub LSP for Locally Protecting Egress 208 4.2. Set up of Backup sub LSP 210 A backup egress node is designated for a primary egress node of a 211 LSP. The previous hop node of the primary egress node sets up a 212 backup sub LSP from itself to the backup egress node after receiving 213 the information about the backup egress node. 215 The previous hop node sets up the backup sub LSP, creates and 216 maintains its state in the same way as of setting up a source to leaf 217 (S2L) sub LSP from the signalling's point of view. It constructs and 218 sends a RSVP-TE PATH message along the path for the backup sub LSP, 219 receives and processes a RSVP-TE RESV message that responses to the 220 PATH message. 222 4.3. Forwarding State for Backup sub LSP(s) 224 The forwarding state for the backup sub LSP is different from that 225 for a P2MP S2L sub LSP. After receiving the RSVP-TE RESV message for 226 the backup sub LSP, the previous hop node creates a forwarding entry 227 with an inactive state or flag called inactive forwarding entry. 228 This inactive forwarding entry is not used to forward any data 229 traffic during normal operations. It SHALL only be used after the 230 failure of the primary egress node. 232 Upon detection of the primary egress node failure, the state or flag 233 of the forwarding entry for the backup sub LSP is set to be active. 234 Thus, the previous hop node of the primary egress node will forward 235 the traffic to the backup egress node through the backup sub LSP, 236 which then send the traffic to its destination. 238 4.4. Detection of Egress Node Failure 240 The previous hop node of the primary egress node SHALL detect four 241 types of failures described below: 243 o The failure of the primary egress node (e.g. L1 in Figure 1) 245 o The failure of the link between the primary egress node and its 246 previous hop node (e.g. the link between R3 and L1 in Figure 1) 248 o The failure of the destination node for the primary egress node 249 (e.g. CE1 in Figure 1) 251 o The failure of the link between the primary egress node and its 252 destination node (e.g. the failure of the link between L1 and CE1 253 in Figure 1). 255 Failure of the primary egress node and the link between itself and 256 its previous hop node CAN be detected through a BFD session between 257 itself and its previous hop node in MPLS networks. 259 In the GMPLS networks where the control plane and data plane are 260 physically separated, the detection and localization of failures in 261 the physical layer can be achieved by introducing the link management 262 protocol (LMP) or assisting by performance monitoring devices. 264 Failure of the destination node and the link between the primary 265 egress node and the destination node CAN be detected by a BFD session 266 between the previous hop node and the destination node. 268 Upon detecting any above mentioned failures, the previous hop node 269 imports the traffic from the LSP into the backup sub LSP. The 270 traffic is then delivered to its destination through the backup 271 egress node. 273 5. Egress Local Protection with FRR 275 RFC4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to use 276 RFC 4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" (FFR 277 for short) to locally protect failures in a link or intermediate node 278 of a P2MP LSP. However, there is not any standard that locally 279 protects the egresses of the P2MP LSP. The egress local protection 280 mechanism proposed in this document fills this gap. Thus, through 281 using the egress local protection and the FRR, we can locally protect 282 the egress nodes, all the links and the intermediate nodes of a P2MP 283 LSP. The traffic switchover time is within tens of milliseconds 284 whenever any of the egresses, the links and the intermediate nodes of 285 the P2MP LSP fails. 287 All the egress nodes of the P2MP LSP can be locally protected through 288 using the egress local protection. All the links and the 289 intermediate nodes of the LSP can be locally protected by using the 290 FRR. Note that the methods for locally protecting all the links and 291 the intermediate nodes of a P2MP LSP are out of scope of this 292 document. 294 6. Representation of a Backup Sub LSP 296 A backup sub LSP exists within the context of a P2MP LSP in a way 297 similar to a S2L sub LSP. It is identified by the P2MP LSP ID, 298 Tunnel ID, and Extended Tunnel ID in the SESSION object, the tunnel 299 sender address and LSP ID in the SENDER_TEMPLATE object, and the 300 backup sub LSP destination address in the EGRESS_BACKUP_SUB_LSP 301 object (to be defined in the section below). 303 An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object (EB-SERO) is used to 304 optionally specify the explicit route of a backup sub LSP that is 305 from a previous hop node to a backup egress node. The EB-SERO is 306 defined in the following section. 308 6.1. EGRESS_BACKUP_SUB_LSP Object 310 An EGRESS_BACKUP_SUB_LSP object identifies a particular backup sub 311 LSP belonging to the LSP. 313 6.1.1. EGRESS_BACKUP_SUB_LSP IPv4 Object 315 The class of the EGRESS_BACKUP_SUB_LSP IPv4 object is the same as 316 that of the S2L_SUB_LSP IPv4 object defined in RFC 4875. The C-Type 317 of the object is a new number 3, or may be another number assigned by 318 Internet Assigned Numbers Authority (IANA). 320 EGRESS_BACKUP_SUB_LSP Class = 50, 321 EGRESS_BACKUP_SUB_LSP_IPv4 C-Type = 3 323 0 1 2 3 324 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Egress Backup Sub LSP IPv4 destination address | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Egress IPv4 address | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Egress Backup Sub LSP IPv4 destination address 332 IPv4 address of the backup sub LSP destination is the backup 333 egress node. 334 Egress IPv4 address 335 IPv4 address of the egress node 337 6.1.2. EGRESS_BACKUP_SUB_LSP IPv6 Object 339 The class of the EGRESS_BACKUP_SUB_LSP IPv6 object is the same as 340 that of the S2L_SUB_LSP IPv6 object defined in RFC 4875. The C-Type 341 of the object is a new number 4, or may be another number assigned by 342 Internet Assigned Numbers Authority (IANA). 344 EGRESS_BACKUP_SUB_LSP Class = 50, 345 EGRESS_BACKUP_SUB_LSP_IPv6 C-Type = 4 347 0 1 2 3 348 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Egress Backup Sub LSP IPv6 destination address | 351 | (16 bytes) | 352 | .... | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Egress IPv6 address | 355 | (16 bytes) | 356 | .... | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Egress Backup Sub LSP IPv6 destination address 360 IPv6 address of the backup sub LSP destination is the backup 361 egress node. 362 Egress IPv6 address 363 IPv6 address of the egress node 365 6.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object 367 The format of an EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE (EB-SERO) 368 object is defined as identical to that of the ERO. The class of the 369 EB-SERO is the same as that of the SERO defined in RFC 4873. The EB- 370 SERO uses a new C-Type 3, or may use another number assigned by 371 Internet Assigned Numbers Authority (IANA). The formats of sub- 372 objects in an EB-SERO are identical to those of sub-objects in an ERO 373 defined in RFC 3209. 375 7. Path Message 377 This section describes extensions to the Path message defined in RFC 378 4875. The Path message is enhanced to transport the information 379 about a backup egress node to the previous hop node of a primary 380 egress node of a P2MP LSP through including an egress backup sub LSP 381 descriptor list. 383 7.1. Format of Path Message 385 The format of the enhanced Path message is illustrated below. 387 ::= [ ] 388 [ [ | ] ...] 389 [ ] 390 391 392 [ ] 393 394 [ ] 395 [ ... ] 396 [ ] 397 [ ] 398 [ ] 399 [ ... ] 400 401 [] 402 [] 404 The format of the egress backup sub LSP descriptor list in the 405 enhanced Path message is defined as follows. 407 ::= 408 409 [ ] 411 ::= 412 413 [ ] 415 7.2. Processing of Path Message 417 The ingress node of a LSP initiates a Path message with an egress 418 backup sub LSP descriptor list for protecting primary egress nodes of 419 the LSP. In order to protect a primary egress node of the LSP, the 420 ingress node MUST add an EGRESS_BACKUP_SUB_LSP object into the list. 421 The object contains the information about the backup egress node to 422 be used to protect the failure of the primary egress node. An 423 EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE object (EB-SERO), which 424 describes an explicit path to the backup egress node, SHALL follow 425 the EGRESS_BACKUP_SUB_LSP. 427 If the previous hop node of the primary egress node receives the Path 428 message with an egress backup sub LSP descriptor list, it generates a 429 new Path message based on the information in the 430 EGRESS_BACKUP_SUB_LSP (and according to EB-SERO if it exists) 431 containing the backup egress node. 433 The format of this new Path message is the same as that of the Path 434 message defined in RFC 4875. This new Path message is used to signal 435 the segment of a special S2L sub-LSP from the previous hop node to 436 the backup egress node. The new Path message is sent to the next-hop 437 node along the path for the backup sub LSP. 439 If an intermediate node receives the Path message with an egress 440 backup sub LSP descriptor list. Then it MUST put the 441 EGRESS_BACKUP_SUB_LSP (according to EB-SERO if exists) containing a 442 backup egress into a Path message to be sent towards the backup 443 egress. This SHALL be done for each EGRESS_BACKUP_SUB_LSP containing 444 a backup egress node in the list. 446 When a primary egress node of the LSP receives the Path message with 447 an egress backup sub LSP descriptor list, it SHOULD ignore the egress 448 backup sub LSP descriptor list and generate a PathErr message. 450 8. Processing of Resv Message 452 The format of the Resv Message is not changed. The processing of the 453 Resv Message at the previous hop of a primary egress node is enhanced 454 for reporting the status of the primary egress protection. 456 The previous hop node of the primary egress node sets the protection 457 flags in the RRO IPv4/IPv6 Sub-object for the primary egress node 458 according to the status of the primary egress node and the backup sub 459 LSP protecting the primary egress node. For example, it will set the 460 node protection bit to one indicating that the primary egress node is 461 protected when the backup sub LSP to the backup egress node is set up 462 for protecting the primary egress node. It will set the bandwidth 463 protection bit to one when the backup sub LSP guarantees to provide 464 the desired bandwidth that is specified in the FAST_REROUTE object or 465 the bandwidth of the protected LSP. 467 9. IANA Considerations 469 TBD 471 10. Acknowledgement 473 The authors would like to thank Richard Li, Olufemi Komolafe, Rob 474 Rennison, Neil Harrison, Kannan Sampath, Yimin Shen, Ronhazli Adam 475 and Quintin Zhao for their valuable comments and suggestions on this 476 draft. 478 11. References 480 11.1. Normative References 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, March 1997. 485 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 486 Considered Useful", BCP 82, RFC 3692, January 2004. 488 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 489 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 490 Functional Specification", RFC 2205, September 1997. 492 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 493 Label Switching Architecture", RFC 3031, January 2001. 495 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 496 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 497 Tunnels", RFC 3209, December 2001. 499 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 500 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 501 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 503 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 504 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 505 May 2005. 507 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 508 "Extensions to Resource Reservation Protocol - Traffic 509 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 510 Switched Paths (LSPs)", RFC 4875, May 2007. 512 [P2MP FRR] 513 Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux, 514 "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", 515 draft-leroux-mpls-p2mp-te-bypass , March 1997. 517 11.2. Informative References 519 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 520 Multipoint Traffic-Engineered MPLS Label Switched Paths 521 (LSPs)", RFC 4461, April 2006. 523 Authors' Addresses 525 Huaimo Chen 526 Huawei Technologies 527 Boston, MA 528 USA 530 Email: Huaimochen@huawei.com 532 Ning So 533 Tata Communications 534 2613 Fairbourne Cir. 535 Plano, TX 75082 536 USA 538 Email: ning.so@tatacommunications.com 540 Autumn Liu 541 Ericsson 542 CA 543 USA 545 Email: autumn.liu@ericsson.com 547 Lei Liu 548 KDDI R&D Lab Inc. 549 2-1-15 550 Ohara Fujimino-shi, Saitama 551 Japan 553 Email: le-liu@kddilabs.jp