idnits 2.17.1 draft-chen-mpls-p2mp-egress-protection-09.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 (May 28, 2013) is 3986 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 522, but no explicit reference was found in the text == Unused Reference: 'RFC3692' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 547, but no explicit reference was found in the text == Unused Reference: 'P2MP FRR' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 559, 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: November 29, 2013 Tata Communications 6 A. Liu 7 Ericsson 8 F. Xu 9 Verizon 10 M. Toy 11 Comcast 12 L. Liu 13 UC Davis 14 May 28, 2013 16 Extensions to RSVP-TE for P2MP LSP Egress Local Protection 17 draft-chen-mpls-p2mp-egress-protection-09.txt 19 Abstract 21 This document describes extensions to Resource Reservation Protocol - 22 Traffic Engineering (RSVP-TE) for locally protecting egress nodes of 23 a Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched 24 Path (LSP) in a Multi-Protocol Label Switching (MPLS) and Generalized 25 MPLS (GMPLS) network. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 29, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 64 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. An Example of Egress Local Protection . . . . . . . . . . 4 66 4.2. Set up of Backup sub LSP . . . . . . . . . . . . . . . . . 5 67 4.3. Forwarding State for Backup sub LSP(s) . . . . . . . . . . 5 68 4.4. Detection of Egress Node Failure . . . . . . . . . . . . . 6 69 5. Egress Local Protection with FRR . . . . . . . . . . . . . . . 7 70 6. Representation of a Backup Sub LSP . . . . . . . . . . . . . . 7 71 6.1. EGRESS_BACKUP_SUB_LSP Object . . . . . . . . . . . . . . . 7 72 6.1.1. EGRESS_BACKUP_SUB_LSP IPv4 Object . . . . . . . . . . 7 73 6.1.2. EGRESS_BACKUP_SUB_LSP IPv6 Object . . . . . . . . . . 8 74 6.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object . . . . . . 9 75 7. Path Message . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 7.1. Format of Path Message . . . . . . . . . . . . . . . . . . 9 77 7.2. Processing of Path Message . . . . . . . . . . . . . . . . 10 78 7.2.1. Backup LSP for One-to-One Protection . . . . . . . . . 10 79 7.2.2. Backup LSP for Facility Protection . . . . . . . . . . 11 80 8. Processing of Resv Message . . . . . . . . . . . . . . . . . . 11 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 12.1. Normative References . . . . . . . . . . . . . . . . . . . 12 86 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 RFC 4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" 92 describes two methods for protecting P2P LSP tunnels or paths at 93 local repair points. The first method is a one-to-one protection 94 method, where a detour backup P2P LSP for each protected P2P LSP is 95 created at each potential point of local repair. The second method 96 is a facility bypass backup protection, where a bypass backup P2P LSP 97 tunnel is created using MPLS label stacking to protect a potential 98 failure point for a set of P2P LSP tunnels. The bypass backup tunnel 99 can protect a set of P2P LSPs having similar backup constraints. 101 RFC 4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to 102 use the one-to-one protection method and facility bypass backup 103 protection method to protect a link or intermediate node failure on 104 the path of a P2MP LSP. However, there is no mention of locally 105 protecting any egress node failure in a protected P2MP LSP. 107 An existing method for protecting the egress nodes of a P2MP LSP sets 108 up a backup P2MP LSP from a backup ingress node to the backup egress 109 nodes, where each egress node is paired with a backup egress node and 110 protected by the backup egress node. The backup P2MP LSP carries the 111 same traffic as the P2MP LSP at the same time. A traffic receiver 112 from the P2MP LSP is normally connected to an egress node and its 113 paired backup egress node. It receives the traffic from the egress 114 node in normal situations. 116 The receiver selects the egress or backup egress node for receiving 117 the traffic according to the route to the source through RPF. In a 118 normal situation, it selects the egress node. When the egress node 119 fails, it selects the backup egress for receiving the traffic since 120 the route to the source through the egress node is gone and the route 121 to the source through the backup egress node is active. 123 The main disadvantage of this method is that double network resources 124 such as double bandwidths are used for protecting the egress nodes 125 since the backup P2MP LSP consumes the same amount of network 126 resource as the primary P2MP LSP. The impact on network efficiency 127 can be significant in case of large P2MP deployments. 129 This document proposes a new method to locally protect the egress 130 nodes of a P2MP LSP, which is called Egress Local Protection. It 131 specifies the mechanism and extensions to RSVP-TE for locally 132 protecting an egress node of a Traffic Engineered (TE) point-to- 133 multipoint (P2MP) Label Switched Path through using a backup P2MP sub 134 LSP. The new method overcomes the disadvantages described above. 135 The same extensions and mechanism can also be used to protect the 136 egress node of a TE P2P LSP. 138 2. Terminology 140 This document uses terminologies defined in RFC 2205, RFC 3031, RFC 141 3209, RFC 3473, RFC 4090, RFC 4461, and RFC 4875. 143 3. Conventions Used in This Document 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119. 149 4. Mechanism 151 This section briefly describes a solution that locally protects an 152 egress node of a P2MP LSP through using a backup sub LSP. We first 153 show an example, and then present different parts of the solution, 154 which includes the creation of the backup sub LSP, the forwarding 155 state for the backup sub LSP, and the detection of a failure in the 156 egress node. 158 4.1. An Example of Egress Local Protection 160 Figure 1 below illustrates an example of using backup sub LSPs to 161 locally protect egress nodes of a P2MP LSP. The P2MP LSP is from 162 ingress node R1 to three egress nodes: L1, L2 and L3. It is 163 represented by double lines in the figure. 165 La, Lb and Lc are the designated backup egress nodes for the egress 166 nodes L1, L2 and L3 of the P2MP LSP respectively. In order to 167 distinguish an egress node (e.g., L1 in the figure) and a backup 168 egress node (e.g., La in the figure), an egress node is called a 169 primary egress node in the follwing description. 171 The backup sub LSP used to protect the primary egress node L1 is from 172 its previous hop node R3 to the backup egress node La. The backup 173 sub LSP used to protect the primary egress node L2 is from its 174 previous hop node R5 to the backup egress node Lb. The backup sub 175 LSP used to protect the primary egress node L3 is from its previous 176 hop node R5 to the backup egress node Lc via the intermediate node 177 Rc. 179 During normal operation, the traffic transported by the P2MP LSP is 180 forwarded through R3 to L1, then delivered to its destination CE1. 181 When the failure of L1 is detected, R3 forwards the traffic to the 182 backup egress node La, which then delivers the traffic to its 183 destination CE1. The time for switching the traffic after L1 fails 184 is within tens of milliseconds. 186 L1's failure CAN be detected by a BFD session between L1 and R3. 188 [R2]=====[R3]=====[L1]----[CE1] 189 // \ / 190 // \ / 191 // \___[La]_/ 192 // 193 // 194 // 195 // 196 +---[R1]====[R4]====[R5]=====[L2]----[CE2] 197 | |\\ \ / 198 | | \\ \ / 199 [S]--| | \\ \__[Lb]_/ 200 | | \\ 201 | | \\ 202 | \\ 203 | \\ 204 | \\ 205 | [L3]----[CE3] 206 | / 207 | / 208 [Rc]_______[Lc]_/ 210 Figure 1: Sub LSP for Locally Protecting Egress 212 4.2. Set up of Backup sub LSP 214 A backup egress node is designated for a primary egress node of a 215 LSP. The previous hop node of the primary egress node sets up a 216 backup sub LSP from itself to the backup egress node after receiving 217 the information about the backup egress node. 219 The previous hop node sets up the backup sub LSP, creates and 220 maintains its state in the same way as of setting up a source to leaf 221 (S2L) sub LSP from the signalling's point of view. It constructs and 222 sends a RSVP-TE PATH message along the path for the backup sub LSP, 223 receives and processes a RSVP-TE RESV message that responses to the 224 PATH message. 226 4.3. Forwarding State for Backup sub LSP(s) 228 The forwarding state for the backup sub LSP is different from that 229 for a P2MP S2L sub LSP. After receiving the RSVP-TE RESV message for 230 the backup sub LSP, the previous hop node creates a forwarding entry 231 with an inactive state or flag called inactive forwarding entry. 232 This inactive forwarding entry is not used to forward any data 233 traffic during normal operations. It SHALL only be used after the 234 failure of the primary egress node. 236 Upon detection of the primary egress node failure, the state or flag 237 of the forwarding entry for the backup sub LSP is set to be active. 238 Thus, the previous hop node of the primary egress node will forward 239 the traffic to the backup egress node through the backup sub LSP, 240 which then sends the traffic to its destination. 242 4.4. Detection of Egress Node Failure 244 The previous hop node of the primary egress node SHALL detect the 245 failures described below: 247 o The failure of the primary egress node (e.g. L1 in Figure 1) 249 o The failure of the link between the primary egress node and its 250 previous hop node (e.g. the link between R3 and L1 in Figure 1) 252 o The failure of the link between the primary egress node and its 253 destination node (e.g. the failure of the link between L1 and CE1 254 in Figure 1). 256 Failure of the primary egress node and the link between itself and 257 its previous hop node CAN be detected through a BFD session between 258 itself and its previous hop node in MPLS networks. 260 In the GMPLS networks where the control plane and data plane are 261 physically separated, the detection and localization of failures in 262 the physical layer can be achieved by introducing the link management 263 protocol (LMP) or assisting by performance monitoring devices. 265 Failure of the destination node and the link between the primary 266 egress node and the destination node CAN be detected by a BFD session 267 between the previous hop node and the destination node. 269 Upon detecting any above mentioned failures, the previous hop node 270 imports the traffic from the LSP into the backup sub LSP. The 271 traffic is then delivered to its destination through the backup 272 egress node. 274 When we use the egress local protection to protect a primary egress 275 node, we SHOULD NOT use any fast re-route to protect the link between 276 the primary egress node and its previous hop node. The failure of 277 the link is protected by the egress protection. 279 5. Egress Local Protection with FRR 281 RFC4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes how to use 282 RFC 4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" (FFR 283 for short) to locally protect failures in a link or intermediate node 284 of a P2MP LSP. However, there is not any standard that locally 285 protects the egresses of the P2MP LSP. The egress local protection 286 mechanism proposed in this document fills this gap. Thus, through 287 using the egress local protection and the FRR, we can locally protect 288 the egress nodes, all the links and the intermediate nodes of a P2MP 289 LSP. The traffic switchover time is within tens of milliseconds 290 whenever any of the egresses, the links and the intermediate nodes of 291 the P2MP LSP fails. 293 All the egress nodes of the P2MP LSP can be locally protected through 294 using the egress local protection. All the links and the 295 intermediate nodes of the LSP can be locally protected by using the 296 FRR. Note that the methods for locally protecting all the links and 297 the intermediate nodes of a P2MP LSP are out of scope of this 298 document. 300 6. Representation of a Backup Sub LSP 302 A backup sub LSP exists within the context of a P2MP LSP in a way 303 similar to a S2L sub LSP. It is identified by the P2MP LSP ID, 304 Tunnel ID, and Extended Tunnel ID in the SESSION object, the tunnel 305 sender address and LSP ID in the SENDER_TEMPLATE object, and the 306 backup sub LSP destination address in the EGRESS_BACKUP_SUB_LSP 307 object (to be defined in the section below). 309 An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object (EB-SERO) is used to 310 specify the explicit route of a backup sub LSP that is from a 311 previous hop node to a backup egress node. The EB-SERO is defined in 312 the following section. 314 6.1. EGRESS_BACKUP_SUB_LSP Object 316 An EGRESS_BACKUP_SUB_LSP object identifies a particular backup sub 317 LSP belonging to the LSP. 319 6.1.1. EGRESS_BACKUP_SUB_LSP IPv4 Object 321 The class of the EGRESS_BACKUP_SUB_LSP IPv4 object is the same as 322 that of the S2L_SUB_LSP IPv4 object defined in RFC 4875. The C-Type 323 of the object is a new number 3, or may be another number assigned by 324 Internet Assigned Numbers Authority (IANA). 326 EGRESS_BACKUP_SUB_LSP Class = 50, 327 EGRESS_BACKUP_SUB_LSP_IPv4 C-Type = 3 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Egress Backup Sub LSP IPv4 destination address | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Egress IPv4 address | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Egress Backup Sub LSP IPv4 destination address 338 IPv4 address of the backup sub LSP destination is the backup 339 egress node. 340 Egress IPv4 address 341 IPv4 address of the egress node 343 6.1.2. EGRESS_BACKUP_SUB_LSP IPv6 Object 345 The class of the EGRESS_BACKUP_SUB_LSP IPv6 object is the same as 346 that of the S2L_SUB_LSP IPv6 object defined in RFC 4875. The C-Type 347 of the object is a new number 4, or may be another number assigned by 348 Internet Assigned Numbers Authority (IANA). 350 EGRESS_BACKUP_SUB_LSP Class = 50, 351 EGRESS_BACKUP_SUB_LSP_IPv6 C-Type = 4 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Egress Backup Sub LSP IPv6 destination address | 357 | (16 bytes) | 358 | .... | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Egress IPv6 address | 361 | (16 bytes) | 362 | .... | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Egress Backup Sub LSP IPv6 destination address 366 IPv6 address of the backup sub LSP destination is the backup 367 egress node. 368 Egress IPv6 address 369 IPv6 address of the egress node 371 6.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object 373 The format of an EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE (EB-SERO) 374 object is defined as identical to that of the ERO. The class of the 375 EB-SERO is the same as that of the SERO defined in RFC 4873. The EB- 376 SERO uses a new C-Type 3, or may use another number assigned by 377 Internet Assigned Numbers Authority (IANA). The formats of sub- 378 objects in an EB-SERO are identical to those of sub-objects in an ERO 379 defined in RFC 3209. 381 7. Path Message 383 This section describes extensions to the Path message defined in RFC 384 4875. The Path message is enhanced to transport the information 385 about a backup egress node to the previous hop node of a primary 386 egress node of a P2MP LSP through including an egress backup sub LSP 387 descriptor list. 389 7.1. Format of Path Message 391 The format of the enhanced Path message is illustrated below. 393 ::= [ ] 394 [ [ | ] ...] 395 [ ] 396 397 398 [ ] 399 400 [ ] 401 [ ... ] 402 [ ] 403 [ ] 404 [ ] 405 [ ... ] 406 407 [] 408 [] 410 The format of the egress backup sub LSP descriptor list in the 411 enhanced Path message is defined as follows. 413 ::= 414 415 [ ] 417 ::= 418 419 [ ] 421 7.2. Processing of Path Message 423 The ingress node of a LSP initiates a Path message with an egress 424 backup sub LSP descriptor list for protecting primary egress nodes of 425 the LSP. In order to protect a primary egress node of the LSP, the 426 ingress node MUST add an EGRESS_BACKUP_SUB_LSP object into the list. 427 The object contains the information about the backup egress node to 428 be used to protect the failure of the primary egress node. An 429 EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE object (EB-SERO), which 430 describes an explicit path to the backup egress node, SHALL follow 431 the EGRESS_BACKUP_SUB_LSP. 433 7.2.1. Backup LSP for One-to-One Protection 435 If the previous hop node of the primary egress node receives the Path 436 message with an egress backup sub LSP descriptor list and the request 437 for protection via the one-to-one backup method, it generates a new 438 Path message based on the information in the EGRESS_BACKUP_SUB_LSP 439 and EB-SERO containing the backup egress node. 441 The format of this new Path message is the same as that of the Path 442 message defined in RFC 4875. This new Path message is used to signal 443 the segment of a special S2L sub-LSP from the previous hop node to 444 the backup egress node. The new Path message is sent to the next-hop 445 node along the path for the backup sub LSP. 447 If an intermediate node receives the Path message with an egress 448 backup sub LSP descriptor list, it MUST put the EGRESS_BACKUP_SUB_LSP 449 containing a backup egress into a Path message to be sent towards the 450 backup egress. This SHALL be done for each EGRESS_BACKUP_SUB_LSP 451 containing a backup egress node in the list. 453 When a primary egress node of the LSP receives the Path message with 454 an egress backup sub LSP descriptor list, it SHOULD ignore the egress 455 backup sub LSP descriptor list and generate a PathErr message. 457 7.2.2. Backup LSP for Facility Protection 459 The facility backup method will be used for locally protecting a 460 primary egress node if the previous hop node of the primary egress 461 node receives the Path message with an egress backup sub LSP 462 descriptor list and the request for protection via the facility 463 backup method. 465 The previous hop node selects or creates a backup LSP tunnel from 466 itself to the backup egress designated for protecting the primary 467 egress. If there exists a backup LSP tunnel from itself to the 468 backup egress that satisifies the constraints given in the PATH 469 message, then this tunnel is selected; otherwise, a new backup LSP 470 tunnel to the backup egress will be created. 472 After having a backup LSP tunnel, the previous hop node assigns the 473 label allocated by the backup egress for the backup LSP as a top 474 label (or called backup label). 476 When the previous hop node detects a failure in the primary egress, 477 it has to imports the traffic for the protected P2MP LSP into the 478 backup bypass tunnel using the backup label as the top label. 480 8. Processing of Resv Message 482 The format of the Resv Message is not changed. The processing of the 483 Resv Message at the previous hop of a primary egress node is enhanced 484 for reporting the status of the primary egress protection. 486 The previous hop node of the primary egress node sets the protection 487 flags in the RRO IPv4/IPv6 Sub-object for the primary egress node 488 according to the status of the primary egress node and the backup LSP 489 protecting the primary egress node. For example, it will set the 490 node protection bit to one indicating that the primary egress node is 491 protected when the backup LSP to the backup egress node is set up for 492 protecting the primary egress node. It will set the bandwidth 493 protection bit to one when the backup LSP guarantees to provide the 494 desired bandwidth that is specified in the FAST_REROUTE object or the 495 bandwidth of the protected LSP. 497 9. IANA Considerations 499 TBD 501 10. Contributors 503 Boris Zhang 504 Telus Communications 505 200 Consilium Pl Floor 15 506 Toronto, ON M1H 3J3 507 Canada 509 Email: Boris.Zhang@telus.com 511 11. Acknowledgement 513 The authors would like to thank Richard Li, Olufemi Komolafe, Michael 514 Yue, Zhenbin Li, Rob Rennison, Neil Harrison, Kannan Sampath, Yimin 515 Shen, Ronhazli Adam and Quintin Zhao for their valuable comments and 516 suggestions on this draft. 518 12. References 520 12.1. Normative References 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, March 1997. 525 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 526 Considered Useful", BCP 82, RFC 3692, January 2004. 528 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 529 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 530 Functional Specification", RFC 2205, September 1997. 532 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 533 Label Switching Architecture", RFC 3031, January 2001. 535 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 536 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 537 Tunnels", RFC 3209, December 2001. 539 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 540 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 541 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 543 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 544 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 545 May 2005. 547 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 548 "Extensions to Resource Reservation Protocol - Traffic 549 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 550 Switched Paths (LSPs)", RFC 4875, May 2007. 552 [P2MP FRR] 553 Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux, 554 "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", 555 draft-leroux-mpls-p2mp-te-bypass , March 1997. 557 12.2. Informative References 559 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 560 Multipoint Traffic-Engineered MPLS Label Switched Paths 561 (LSPs)", RFC 4461, April 2006. 563 Authors' Addresses 565 Huaimo Chen 566 Huawei Technologies 567 Boston, MA 568 USA 570 Email: huaimo.chen@huawei.com 572 Ning So 573 Tata Communications 574 2613 Fairbourne Cir. 575 Plano, TX 75082 576 USA 578 Email: ning.so@tatacommunications.com 580 Autumn Liu 581 Ericsson 582 CA 583 USA 585 Email: autumn.liu@ericsson.com 586 Fengman Xu 587 Verizon 588 2400 N. Glenville Dr 589 Richardson, TX 75082 590 USA 592 Email: fengman.xu@verizon.com 594 Mehmet Toy 595 Comcast 596 1800 Bishops Gate Blvd. 597 Mount Laurel, NJ 08054 598 USA 600 Email: mehmet_toy@cable.comcast.com 602 Lei Liu 603 UC Davis 604 USA 606 Email: liulei.kddi@gmail.com