idnits 2.17.1 draft-chen-mpls-p2mp-egress-protection-07.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 (October 20, 2012) is 4206 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 504, but no explicit reference was found in the text == Unused Reference: 'RFC3692' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 521, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'P2MP FRR' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 541, 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: April 23, 2013 Tata Communications 6 A. Liu 7 Ericsson 8 L. Liu 9 KDDI R&D Lab Inc. 10 October 20, 2012 12 Extensions to RSVP-TE for P2MP LSP Egress Local Protection 13 draft-chen-mpls-p2mp-egress-protection-07.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 April 23, 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) . . . . . . . . . . 5 64 4.4. Detection of Egress Node Failure . . . . . . . . . . . . . 6 65 5. Egress Local Protection with FRR . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . 7 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 7.2.1. Backup LSP for One-to-One Protection . . . . . . . . . 10 75 7.2.2. Backup LSP for Facility Protection . . . . . . . . . . 11 76 8. Processing of Resv Message . . . . . . . . . . . . . . . . . . 11 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 RFC 4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" 87 describes two methods for protecting P2P LSP tunnels or paths at 88 local repair points. The first method is a one-to-one protection 89 method, where a detour backup P2P LSP for each protected P2P LSP is 90 created at each potential point of local repair. The second method 91 is a facility bypass backup protection, where a bypass backup P2P LSP 92 tunnel is created using MPLS label stacking to protect a potential 93 failure point for a set of P2P LSP tunnels. The bypass backup tunnel 94 can protect a set 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. 130 The same extensions and mechanism can also be used to protect the 131 egress node of a TE P2P LSP. 133 2. Terminology 135 This document uses terminologies defined in RFC 2205, RFC 3031, RFC 136 3209, RFC 3473, RFC 4090, RFC 4461, and RFC 4875. 138 3. Conventions Used in This Document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119. 144 4. Mechanism 146 This section briefly describes a solution that locally protects an 147 egress node of a P2MP LSP through using a backup P2MP sub LSP. We 148 first show an example, and then present different parts of the 149 solution, which includes the creation of the backup sub LSP, the 150 forwarding state for the backup sub LSP, and the detection of a 151 failure in the egress node. 153 4.1. An Example of Egress Local Protection 155 Figure 1 below illustrates an example of using backup sub LSPs to 156 locally protect egress nodes of a P2MP LSP. The P2MP LSP is from 157 ingress node R1 to three egress nodes: L1, L2 and L3. It is 158 represented by double lines in the figure. 160 La, Lb and Lc are the designated backup egress nodes for the egress 161 nodes L1, L2 and L3 of the P2MP LSP respectively. In order to 162 distinguish an egress node (e.g., L1 in the figure) and a backup 163 egress node (e.g., La in the figure), an egress node is called a 164 primary egress node in the follwing description. 166 The backup sub LSP used to protect the primary egress node L1 is from 167 its previous hop node R3 to the backup egress node La. The backup 168 sub LSP used to protect the primary egress node L2 is from its 169 previous hop node R5 to the backup egress node Lb. The backup sub 170 LSP used to protect the primary egress node L3 is from its previous 171 hop node R5 to the backup egress node Lc via the intermediate node 172 Rc. 174 During normal operation, the traffic transported by the P2MP LSP is 175 forwarded through R3 to L1, then delivered to its destination CE1. 176 When the failure of L1 is detected, R3 forwards the traffic to the 177 backup egress node La, which then delivers the traffic to its 178 destination CE1. The time for switching the traffic after L1 fails 179 is within tens of milliseconds. 181 L1's failure CAN be detected by a BFD session between L1 and R3. 183 [R2]=====[R3]=====[L1]----[CE1] 184 // \ / 185 // \ / 186 // \___[La]_/ 187 // 188 // 189 // 190 // 191 +---[R1]====[R4]====[R5]=====[L2]----[CE2] 192 | |\\ \ / 193 | | \\ \ / 194 [S]--| | \\ \__[Lb]_/ 195 | | \\ 196 | | \\ 197 | \\ 198 | \\ 199 | \\ 200 | [L3]----[CE3] 201 | / 202 | / 203 [Rc]_______[Lc]_/ 205 Figure 1: P2MP sub LSP for Locally Protecting Egress 207 4.2. Set up of Backup sub LSP 209 A backup egress node is designated for a primary egress node of a 210 LSP. The previous hop node of the primary egress node sets up a 211 backup sub LSP from itself to the backup egress node after receiving 212 the information about the backup egress node. 214 The previous hop node sets up the backup sub LSP, creates and 215 maintains its state in the same way as of setting up a source to leaf 216 (S2L) sub LSP from the signalling's point of view. It constructs and 217 sends a RSVP-TE PATH message along the path for the backup sub LSP, 218 receives and processes a RSVP-TE RESV message that responses to the 219 PATH message. 221 4.3. Forwarding State for Backup sub LSP(s) 223 The forwarding state for the backup sub LSP is different from that 224 for a P2MP S2L sub LSP. After receiving the RSVP-TE RESV message for 225 the backup sub LSP, the previous hop node creates a forwarding entry 226 with an inactive state or flag called inactive forwarding entry. 227 This inactive forwarding entry is not used to forward any data 228 traffic during normal operations. It SHALL only be used after the 229 failure of the primary egress node. 231 Upon detection of the primary egress node failure, the state or flag 232 of the forwarding entry for the backup sub LSP is set to be active. 233 Thus, the previous hop node of the primary egress node will forward 234 the traffic to the backup egress node through the backup sub LSP, 235 which then send the traffic to its destination. 237 4.4. Detection of Egress Node Failure 239 The previous hop node of the primary egress node SHALL detect the 240 failures described below: 242 o The failure of the primary egress node (e.g. L1 in Figure 1) 244 o The failure of the link between the primary egress node and its 245 previous hop node (e.g. the link between R3 and L1 in Figure 1) 247 o The failure of the link between the primary egress node and its 248 destination node (e.g. the failure of the link between L1 and CE1 249 in Figure 1). 251 Failure of the primary egress node and the link between itself and 252 its previous hop node CAN be detected through a BFD session between 253 itself and its previous hop node in MPLS networks. 255 In the GMPLS networks where the control plane and data plane are 256 physically separated, the detection and localization of failures in 257 the physical layer can be achieved by introducing the link management 258 protocol (LMP) or assisting by performance monitoring devices. 260 Failure of the destination node and the link between the primary 261 egress node and the destination node CAN be detected by a BFD session 262 between the previous hop node and the destination node. 264 Upon detecting any above mentioned failures, the previous hop node 265 imports the traffic from the LSP into the backup sub LSP. The 266 traffic is then delivered to its destination through the backup 267 egress node. 269 5. Egress Local Protection with FRR 271 RFC4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to use 272 RFC 4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" (FFR 273 for short) to locally protect failures in a link or intermediate node 274 of a P2MP LSP. However, there is not any standard that locally 275 protects the egresses of the P2MP LSP. The egress local protection 276 mechanism proposed in this document fills this gap. Thus, through 277 using the egress local protection and the FRR, we can locally protect 278 the egress nodes, all the links and the intermediate nodes of a P2MP 279 LSP. The traffic switchover time is within tens of milliseconds 280 whenever any of the egresses, the links and the intermediate nodes of 281 the P2MP LSP fails. 283 All the egress nodes of the P2MP LSP can be locally protected through 284 using the egress local protection. All the links and the 285 intermediate nodes of the LSP can be locally protected by using the 286 FRR. Note that the methods for locally protecting all the links and 287 the intermediate nodes of a P2MP LSP are out of scope of this 288 document. 290 6. Representation of a Backup Sub LSP 292 A backup sub LSP exists within the context of a P2MP LSP in a way 293 similar to a S2L sub LSP. It is identified by the P2MP LSP ID, 294 Tunnel ID, and Extended Tunnel ID in the SESSION object, the tunnel 295 sender address and LSP ID in the SENDER_TEMPLATE object, and the 296 backup sub LSP destination address in the EGRESS_BACKUP_SUB_LSP 297 object (to be defined in the section below). 299 An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object (EB-SERO) is used to 300 optionally specify the explicit route of a backup sub LSP that is 301 from a previous hop node to a backup egress node. The EB-SERO is 302 defined in the following section. 304 6.1. EGRESS_BACKUP_SUB_LSP Object 306 An EGRESS_BACKUP_SUB_LSP object identifies a particular backup sub 307 LSP belonging to the LSP. 309 6.1.1. EGRESS_BACKUP_SUB_LSP IPv4 Object 311 The class of the EGRESS_BACKUP_SUB_LSP IPv4 object is the same as 312 that of the S2L_SUB_LSP IPv4 object defined in RFC 4875. The C-Type 313 of the object is a new number 3, or may be another number assigned by 314 Internet Assigned Numbers Authority (IANA). 316 EGRESS_BACKUP_SUB_LSP Class = 50, 317 EGRESS_BACKUP_SUB_LSP_IPv4 C-Type = 3 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Egress Backup Sub LSP IPv4 destination address | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Egress IPv4 address | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Egress Backup Sub LSP IPv4 destination address 328 IPv4 address of the backup sub LSP destination is the backup 329 egress node. 330 Egress IPv4 address 331 IPv4 address of the egress node 333 6.1.2. EGRESS_BACKUP_SUB_LSP IPv6 Object 335 The class of the EGRESS_BACKUP_SUB_LSP IPv6 object is the same as 336 that of the S2L_SUB_LSP IPv6 object defined in RFC 4875. The C-Type 337 of the object is a new number 4, or may be another number assigned by 338 Internet Assigned Numbers Authority (IANA). 340 EGRESS_BACKUP_SUB_LSP Class = 50, 341 EGRESS_BACKUP_SUB_LSP_IPv6 C-Type = 4 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Egress Backup Sub LSP IPv6 destination address | 347 | (16 bytes) | 348 | .... | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Egress IPv6 address | 351 | (16 bytes) | 352 | .... | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Egress Backup Sub LSP IPv6 destination address 356 IPv6 address of the backup sub LSP destination is the backup 357 egress node. 358 Egress IPv6 address 359 IPv6 address of the egress node 361 6.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object 363 The format of an EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE (EB-SERO) 364 object is defined as identical to that of the ERO. The class of the 365 EB-SERO is the same as that of the SERO defined in RFC 4873. The EB- 366 SERO uses a new C-Type 3, or may use another number assigned by 367 Internet Assigned Numbers Authority (IANA). The formats of sub- 368 objects in an EB-SERO are identical to those of sub-objects in an ERO 369 defined in RFC 3209. 371 7. Path Message 373 This section describes extensions to the Path message defined in RFC 374 4875. The Path message is enhanced to transport the information 375 about a backup egress node to the previous hop node of a primary 376 egress node of a P2MP LSP through including an egress backup sub LSP 377 descriptor list. 379 7.1. Format of Path Message 381 The format of the enhanced Path message is illustrated below. 383 ::= [ ] 384 [ [ | ] ...] 385 [ ] 386 387 388 [ ] 389 390 [ ] 391 [ ... ] 392 [ ] 393 [ ] 394 [ ] 395 [ ... ] 396 397 [] 398 [] 400 The format of the egress backup sub LSP descriptor list in the 401 enhanced Path message is defined as follows. 403 ::= 404 405 [ ] 407 ::= 408 409 [ ] 411 7.2. Processing of Path Message 413 The ingress node of a LSP initiates a Path message with an egress 414 backup sub LSP descriptor list for protecting primary egress nodes of 415 the LSP. In order to protect a primary egress node of the LSP, the 416 ingress node MUST add an EGRESS_BACKUP_SUB_LSP object into the list. 417 The object contains the information about the backup egress node to 418 be used to protect the failure of the primary egress node. An 419 EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE object (EB-SERO), which 420 describes an explicit path to the backup egress node, SHALL follow 421 the EGRESS_BACKUP_SUB_LSP. 423 7.2.1. Backup LSP for One-to-One Protection 425 If the previous hop node of the primary egress node receives the Path 426 message with an egress backup sub LSP descriptor list and the request 427 for protection via the one-to-one backup method, it generates a new 428 Path message based on the information in the EGRESS_BACKUP_SUB_LSP 429 (and according to EB-SERO if it exists) containing the backup egress 430 node. 432 The format of this new Path message is the same as that of the Path 433 message defined in RFC 4875. This new Path message is used to signal 434 the segment of a special S2L sub-LSP from the previous hop node to 435 the backup egress node. The new Path message is sent to the next-hop 436 node along the path for the backup sub LSP. 438 If an intermediate node receives the Path message with an egress 439 backup sub LSP descriptor list. Then it MUST put the 440 EGRESS_BACKUP_SUB_LSP (according to EB-SERO if exists) containing a 441 backup egress into a Path message to be sent towards the backup 442 egress. This SHALL be done for each EGRESS_BACKUP_SUB_LSP containing 443 a backup egress node in the list. 445 When a primary egress node of the LSP receives the Path message with 446 an egress backup sub LSP descriptor list, it SHOULD ignore the egress 447 backup sub LSP descriptor list and generate a PathErr message. 449 7.2.2. Backup LSP for Facility Protection 451 The facility backup method will be used for locally protecting a 452 primary egress node if the previous hop node of the primary egress 453 node receives the Path message with an egress backup sub LSP 454 descriptor list and the request for protection via the facility 455 backup method. 457 The previous hop node selects or creates a backup LSP tunnel from 458 itself to the backup egress designated for protecting the primary 459 egress. If there exists a backup LSP tunnel from itself to the 460 backup egress that satisifies the constraints given in the PATH 461 message, then this tunnel is selected; otherwise, a new backup LSP 462 tunnel to the backup egress will be created. 464 After having a backup LSP tunnel, the previous hop node assigns the 465 label allocated by the backup egress for the backup LSP as a top 466 label (or called backup label). 468 When the previous hop node detects a failure in the primary egress, 469 it has to imports the traffic for the protected P2MP LSP into the 470 backup bypass tunnel using the backup label as the top label. 472 8. Processing of Resv Message 474 The format of the Resv Message is not changed. The processing of the 475 Resv Message at the previous hop of a primary egress node is enhanced 476 for reporting the status of the primary egress protection. 478 The previous hop node of the primary egress node sets the protection 479 flags in the RRO IPv4/IPv6 Sub-object for the primary egress node 480 according to the status of the primary egress node and the backup sub 481 LSP protecting the primary egress node. For example, it will set the 482 node protection bit to one indicating that the primary egress node is 483 protected when the backup sub LSP to the backup egress node is set up 484 for protecting the primary egress node. It will set the bandwidth 485 protection bit to one when the backup sub LSP guarantees to provide 486 the desired bandwidth that is specified in the FAST_REROUTE object or 487 the bandwidth of the protected LSP. 489 9. IANA Considerations 491 TBD 493 10. Acknowledgement 495 The authors would like to thank Richard Li, Olufemi Komolafe, Rob 496 Rennison, Neil Harrison, Kannan Sampath, Yimin Shen, Ronhazli Adam 497 and Quintin Zhao for their valuable comments and suggestions on this 498 draft. 500 11. References 502 11.1. Normative References 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, March 1997. 507 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 508 Considered Useful", BCP 82, RFC 3692, January 2004. 510 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 511 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 512 Functional Specification", RFC 2205, September 1997. 514 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 515 Label Switching Architecture", RFC 3031, January 2001. 517 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 518 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 519 Tunnels", RFC 3209, December 2001. 521 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 522 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 523 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 525 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 526 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 527 May 2005. 529 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 530 "Extensions to Resource Reservation Protocol - Traffic 531 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 532 Switched Paths (LSPs)", RFC 4875, May 2007. 534 [P2MP FRR] 535 Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux, 536 "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", 537 draft-leroux-mpls-p2mp-te-bypass , March 1997. 539 11.2. Informative References 541 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 542 Multipoint Traffic-Engineered MPLS Label Switched Paths 543 (LSPs)", RFC 4461, April 2006. 545 Authors' Addresses 547 Huaimo Chen 548 Huawei Technologies 549 Boston, MA 550 USA 552 Email: huaimo.chen@huawei.com 554 Ning So 555 Tata Communications 556 2613 Fairbourne Cir. 557 Plano, TX 75082 558 USA 560 Email: ning.so@tatacommunications.com 562 Autumn Liu 563 Ericsson 564 CA 565 USA 567 Email: autumn.liu@ericsson.com 569 Lei Liu 570 KDDI R&D Lab Inc. 571 2-1-15 572 Ohara Fujimino-shi, Saitama 573 Japan 575 Email: le-liu@kddilabs.jp