idnits 2.17.1 draft-chen-mpls-p2mp-egress-protection-10.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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 28, 2013) is 3800 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) == Missing Reference: 'CE1' is mentioned on line 464, but not defined == Missing Reference: 'La' is mentioned on line 464, but not defined == Missing Reference: 'S' is mentioned on line 147, but not defined == Missing Reference: 'CE2' is mentioned on line 461, but not defined == Missing Reference: 'Lb' is mentioned on line 150, but not defined == Missing Reference: 'R1' is mentioned on line 461, but not defined == Missing Reference: 'R4' is mentioned on line 439, but not defined == Missing Reference: 'R5' is mentioned on line 439, but not defined == Unused Reference: 'RFC2119' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'RFC3692' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'RFC5331' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'P2MP FRR' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 586, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'P2MP FRR' Summary: 0 errors (**), 0 flaws (~~), 21 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: June 1, 2014 Tata Communications 6 A. Liu 7 Ericsson 8 F. Xu 9 Verizon 10 M. Toy 11 Comcast 12 L. Huang 13 China Mobile 14 L. Liu 15 UC Davis 16 November 28, 2013 18 Extensions to RSVP-TE for LSP Egress Local Protection 19 draft-chen-mpls-p2mp-egress-protection-10.txt 21 Abstract 23 This document describes extensions to Resource Reservation Protocol - 24 Traffic Engineering (RSVP-TE) for locally protecting egress nodes of 25 a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- 26 Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 1, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. An Example of Egress Local Protection . . . . . . . . . . 3 64 1.2. Egress Local Protection with FRR . . . . . . . . . . . . . 4 65 2. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. EGRESS_BACKUP_SUB_LSP IPv4/IPv6 Object . . . . . . . . . . 4 67 2.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object . . . . . . 5 68 2.3. Path Message . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Egress Protection Behaviors . . . . . . . . . . . . . . . . . 6 70 3.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 7 71 3.2. Intermediate Node and PLR Behavior . . . . . . . . . . . . 7 72 3.2.1. Signaling for One-to-One Protection . . . . . . . . . 8 73 3.2.2. Signaling for Facility Protection . . . . . . . . . . 8 74 3.2.3. Signaling for S2L Sub LSP Protection . . . . . . . . . 9 75 3.2.4. PLR Procedures during Local Repair . . . . . . . . . . 9 76 4. Considering Application Traffic . . . . . . . . . . . . . . . 10 77 4.1. A Typical Application . . . . . . . . . . . . . . . . . . 10 78 4.2. PLR Procedure for Applications . . . . . . . . . . . . . . 11 79 4.3. Egress Procedures for Applications . . . . . . . . . . . . 11 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 RFC 4090 describes two methods for protecting the transit nodes of a 92 P2P LSP: one-to-one protection and facility bypass protection. RFC 93 4875 specifies how to use them to protect the transit nodes of a P2MP 94 LSP. However, there is no mention of locally protecting any egress 95 of a protected P2P or P2MP LSP in these RFCs. 97 To protect the egresses of an LSP (P2P or P2MP), an existing approach 98 sets up a backup LSP from a backup ingress (or the ingress of the 99 LSP) to the backup egresses, where each egress is paired with a 100 backup egress and protected by the backup egress. 102 The main disadvantage of this approach is that more network resources 103 such as double bandwidths may be used. 105 This document specifies extensions to RSVP-TE for locally protecting 106 an egress of a P2MP or P2P LSP, which overcome this disadvantage. 108 1.1. An Example of Egress Local Protection 110 Figure 1 illustrates an example of using backup LSPs to locally 111 protect egress nodes of a primary P2MP LSP, which is from ingress 112 node R1 to two egress nodes: L1 and L2. The primary LSP is 113 represented by star(*) lines and backup LSPs by hyphen(-) lines. 115 La and Lb are the designated backup egress nodes for egress nodes L1 116 and L2 of the P2MP LSP respectively. To distinguish between an 117 egress (e.g., L1 in the figure) and a backup egress (e.g., La in the 118 figure), an egress is called a primary egress if necessary. 120 The backup LSP for protecting primary egress L1 is from its upstream 121 node R3 to backup egress La. The backup LSP for protecting primary 122 egress L2 is from its upstream node R5 to backup egress Lb. 124 During normal operations, the traffic carried by the P2MP LSP is sent 125 through R3 to L1, which delivers the traffic to its destination CE1. 126 When R3 detects the failure of L1, R3 switches the traffic to the 127 backup LSP to backup egress La, which delivers the traffic to CE1. 128 The time for switching the traffic is within tens of milliseconds. 130 The failure of a primary egress (e.g., L1 in the figure) MAY be 131 detected by its upstream node (e.g., R3 in the figure) through a BFD 132 session between the upstream node and the egress in MPLS networks. 133 Exactly how the failure is detected is out of scope for this 134 document. 136 [R2]*****[R3]*****[L1] 137 * \ :.....: $ **** Primary LSP 138 * \ $ ---- Backup LSP 139 * \ [CE1] .... BFD Session 140 * \ $ $ Link 141 * \ $ $ 142 * [La] $ 143 * 144 [R1]******[R4]*******[R5]*****[L2] 145 $ \ :.....: $ 146 $ \ $ 147 [S] \ [CE2] 148 \ $ 149 \ $ 150 [Lb] 152 Figure 1: Backup LSP for Locally Protecting Egress 154 1.2. Egress Local Protection with FRR 156 Using the egress local protection and the FRR, we can locally protect 157 the egresses, the links and the intermediate nodes of an LSP. The 158 traffic switchover time is within tens of milliseconds whenever an 159 egress, any of the links and the intermediate nodes of the LSP fails. 161 The egress nodes of the LSP can be locally protected via the egress 162 local protection. All the links and the intermediate nodes of the 163 LSP can be locally protected through using the FRR. 165 2. Protocol Extensions 167 A new object EGRESS_BACKUP_SUB_LSP is defined for signaling egress 168 local protection. It contains a backup egress for a primary egress. 170 2.1. EGRESS_BACKUP_SUB_LSP IPv4/IPv6 Object 172 The class of the EGRESS_BACKUP_SUB_LSP IPv4/IPv6 object is 50, which 173 is the same as that of the S2L_SUB_LSP IPv4/IPv6 object defined in 174 RFC 4875. The C-Type of the EGRESS_BACKUP_SUB_LSP IPv4 object is a 175 new number 3 or another number assigned by IANA. 177 EGRESS_BACKUP_SUB_LSP_IPv4 C-Type = 3 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Egress Backup Sub LSP destination IPv4 address | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Egress Primary Sub LSP destination IPv4 address | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | (Subobjects) | 187 ~ ~ 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Egress Backup Sub LSP destination IPv4 address 191 IPv4 address of the backup egress node 192 Egress Primary Sub LSP destination IPv4 address 193 IPv4 address of the primary egress node 194 Subobjects are optional 196 The C-Type of the EGRESS_BACKUP_SUB_LSP IPv6 object is a new number 4 197 or another number assigned by IANA. 199 EGRESS_BACKUP_SUB_LSP_IPv6 C-Type = 4 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Egress Backup Sub LSP destination IPv6 address | 205 ~ (16 bytes) ~ 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Egress Primary Sub LSP destination IPv6 address | 208 ~ (16 bytes) ~ 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | (Subobjects) | 211 ~ ~ 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Egress Backup Sub LSP destination IPv6 address 215 IPv6 address of the backup egress node 216 Egress Primary Sub LSP destination IPv6 address 217 IPv6 address of the primary egress node 218 Subobjects are optional 220 2.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object 222 An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE (EB-SERO) object is defined 223 for signaling protection for a primary egress of a P2MP LSP in a new 224 S2L Sub LSP backup protection method. It contains a path from the 225 upstream node of the primary egress to a backup egress. Its format 226 is identical to an ERO's. 228 The class of an EB-SERO is the same as that of a SERO defined in RFC 229 4873. The EB-SERO uses a new C-Type 3, or another number assigned by 230 IANA. The formats of sub-objects in an EB-SERO are identical to 231 those of sub-objects in an ERO defined in RFC 3209. 233 2.3. Path Message 235 A Path message is enhanced to carry the information about a backup 236 egress for a primary egress of an LSP through including an egress 237 backup sub LSP descriptor list. The format of the enhanced Path 238 message is illustrated below. 240 ::= [ ] 241 [ [ | ] ...] 242 [ ] 243 244 [ ] 245 [ ] 246 [ ... ] 247 [ ] [ ] 248 [ ] [ ... ] 249 250 [] 251 [] 253 The egress backup sub LSP descriptor list in the message is defined 254 below. It is a sequence of EGRESS_BACKUP_SUB_LSP objects, each of 255 which describes a pair of a primary egress and a backup egress. 257 ::= 258 259 [ ] 261 ::= 262 263 [ ] 265 3. Egress Protection Behaviors 266 3.1. Ingress Behavior 268 To protect a primary egress of an LSP, a backup egress must be 269 configured on the ingress of the LSP. 271 The ingress initiates a Path message for the LSP with an egress 272 backup sub LSP descriptor list. For each primary egress of the LSP 273 to be protected, the ingress MUST add an EGRESS_BACKUP_SUB_LSP object 274 into the list. The object contains the primary egress and the backup 275 egress for protecting the primary egress. 277 To protect a primary egress of an LSP via one-to-one backup or 278 facility backup method, the ingress SHOULD include a FAST_REROUTE 279 object and set the One-to-One Backup Desired or Facility Backup 280 Desired flag. 282 To protect a primary egress of a P2MP LSP via S2L Sub LSP backup 283 method, the ingress SHOULD add an EB-SERO object following the 284 EGRESS_BACKUP_SUB_LSP object into the list. The EB-SERO object 285 contains a path from the upstream node of the primary egress to the 286 backup egress. The ingress computes the path if the P2MP LSP is in 287 one area; otherwise, the path may be computed by the Path Computation 288 Element (PCE). 290 3.2. Intermediate Node and PLR Behavior 292 If an intermediate node of an LSP receives the Path message with an 293 egress backup sub LSP descriptor list and it is not an upstream node 294 of any primary egress of the LSP, it forwards the list in the message 295 unchanged. 297 If the intermediate node is the upstream node of a primary egress to 298 be protected, it gets the backup egress for the primary egress from 299 the EGRESS_BACKUP_SUB_LSP object in the list. It acts as a PLR to 300 provide one-to-one or facility backup protection for the primary 301 egress. It provides one-to-one backup protection if the One-to-One 302 Backup Desired flag is set in the message; it provides facility 303 backup protection if the Facility Backup Desired flag is set. 305 The PLR (upstream node of the primary egress) sets the protection 306 flags in the RRO Sub-object for the primary egress in the Resv 307 message according to the status of the primary egress and the backup 308 LSP protecting the primary egress. For example, it will set the 309 "local protection available" and the "node protection" flag to one 310 indicating that the primary egress is protected when the backup LSP 311 to the backup egress is set up for protecting the primary egress. 313 3.2.1. Signaling for One-to-One Protection 315 The behavior of the upstream node of a primary egress of an LSP as a 316 PLR is the same as that of a PLR for one-to-one backup method 317 described in RFC 4090 except for that the upstream node creates a 318 backup LSP from itself to a backup egress. 320 In the case that the LSP is a P2MP LSP and a primary egress of the 321 LSP is a transit node (i.e., bud node), the upstream node of the 322 primary egress as a PLR also creates a backup LSP from itself to each 323 of the next hops of the primary egress. 325 When the PLR detects a failure in the primary egress, it MUST rapidly 326 switch the packets from the primary LSP to the backup LSP to the 327 backup egress. For a failure in the bud node of an P2MP LSP, the PLR 328 MUST also rapidly switch the packets to the backup LSPs to the bud 329 node's next hops, where the packets are merged into the primary LSP. 331 3.2.2. Signaling for Facility Protection 333 Except for backup LSP and downstream label, the behavior of the 334 upstream node of the primary egress as a PLR follows the PLR behavior 335 for facility backup method described in RFC 4090. 337 For a number of primary P2P LSPs going through the same PLR to the 338 same primary egress, the primary egress of these LSPs may be 339 protected by one backup LSP from the PLR to the backup egress 340 designated for protecting the primary egress. 342 The PLR selects or creates a backup LSP from itself to the backup 343 egress. If there exists a backup LSP that satisfies the constraints 344 given in the Path message, then this one is selected; otherwise, a 345 new backup LSP to the backup egress will be created. 347 For a primary LSP carrying IP packets, the PLR does not need any 348 downstream label as an inner label for the LSP when binding the 349 primary LSP with the backup LSP. When the PLR detects a failure in 350 the primary egress, it redirects the IP packets from the primary LSP 351 into the backup LSP to the backup egress, where the IP packets are 352 forwarded according to IP destinations in the packets. 354 For a primary LSP carrying packets with application or service 355 labels, the PLR may not need any downstream label as an inner label 356 for the LSP either when binding the primary LSP with the backup LSP. 357 When the PLR detects a failure in the primary egress, it redirects 358 the packets from the primary LSP into the backup LSP to backup egress 359 through switching the top label with the backup LSP label. The 360 backup egress delivers the packets to the same destinations as the 361 primary egress (see details in section "Considering Application 362 Traffic" below). 364 3.2.3. Signaling for S2L Sub LSP Protection 366 The S2L Sub LSP Protection is used to protect a primary egress of a 367 P2MP LSP. Its major advantage is that the application traffic 368 carried by the P2MP LSP may be easily protected against the egress 369 failure. 371 The PLR determines to protect a primary egress of a P2MP LSP via S2L 372 sub LSP protection when it receives a Path message with an EB-SERO 373 object following the EGRESS_BACKUP_SUB_LSP containing the primary 374 egress and a backup egress. 376 The PLR sets up the backup S2L sub LSP to the backup egress, creates 377 and maintains its state in the same way as of setting up a source to 378 leaf (S2L) sub LSP defined in RFC 4875 from the signaling's point of 379 view. It constructs and sends a PATH message along the path given in 380 the EB-SERO for the backup LSP, receives and processes a RESV message 381 that responses to the PATH message. 383 After receiving the RESV message for the backup LSP, the PLR creates 384 a forwarding entry with an inactive state or flag called inactive 385 forwarding entry. This inactive forwarding entry is not used to 386 forward any data traffic during normal operations. 388 When the PLR detects a failure in the primary egress failure, it 389 changes the forwarding entry for the backup LSP to active. Thus, the 390 PLR forwards the traffic to the backup egress through the backup LSP, 391 which sends the traffic to its destination. 393 3.2.4. PLR Procedures during Local Repair 395 When the upstream node of a primary egress of an LSP as a PLR detects 396 a failure in the primary egress, it follows the procedures defined in 397 section 6.5 of RFC 4090. 399 The PLR (i.e., the upstream node of the primary egress) SHOULD notify 400 the ingress about the failure of the primary egress in the same way 401 as a PLR notifies the ingress about the failure of an intermediate 402 node. 404 In the local revertive mode, the PLR re-signals each of the primary 405 LSPs that used to be routed over the restored resource once it 406 detects that the resource is restored. Every primary LSP 407 successfully re-signaled along the restored resource is switched 408 back. 410 Moreover, the PLR lets the upstream part of the primary LSP stay 411 after the primary egress fails. The downstream part of the primary 412 LSP from the PLR to the primary egress SHOULD be removed. 414 4. Considering Application Traffic 416 This section focuses on the application traffic carried by P2P LSPs. 417 When a primary egress of a P2MP LSP fails, the application traffic 418 carried by the P2MP LSP may be delivered to the same destination by 419 the backup egress since the inner label if any for the traffic is a 420 upstream assigned label for every egress of the P2MP LSP. 422 4.1. A Typical Application 424 L3VPN is a typical application that an LSP carries. An existing 425 solution (refer to Figure 2) for protecting L3VPN traffic against 426 egress failure includes: 1) A multi-hop BFD session between ingress 427 R1 and egress L1 of primary LSP; 2) A backup LSP from ingress R1 to 428 backup egress La; 3) La sends R1 VPN backup label and related 429 information via BGP; 4) R1 has a VRF with two sets of routes: one 430 uses primary LSP and L1 as next hop; the other uses backup LSP and La 431 as next hop. 433 CE1,CE2 in [R2]*****[R3]*****[L1] **** Primary LSP 434 one VPN * : $ ---- Backup LSP 435 * .................: $ .... BFD Session 436 [R1] ..: [CE2] $ Link 437 $ \ $ $ 438 $ \ $ 439 [CE1] [R4]-----[R5]-----[La](BGP sends R1 VPN backup label) 441 Figure 2: Protect Egress for L3VPN Traffic 443 In normal operations, R1 sends the traffic from CE1 through primary 444 LSP with VPN label received from L1 as inner label to L1, which 445 delivers the traffic to CE2 using VPN label. 447 When R1 detects a failure in L1, R1 sends the traffic from CE1 via 448 backup LSP with VPN bakup label received from La as inner label to 449 La, which delivers the traffic to CE2 using VPN backup label. 451 A new solution (refer to Figure 3) with egress local protection for 452 protecting L3VPN traffic includes: 1) A BFD session between R3 and 453 egress L1 of primary LSP; 2) A backup LSP from R3 to backup egress 454 La; 3) L1 sends La VPN label as UA label and related information via 455 BGP or another protocol; 4) L1 and La is virtualized as one from R1's 456 point of view. 458 CE1,CE2 in [R2]*****[R3]*****[L1] **** Primary LSP 459 one VPN * \ :.....: $ ---- Backup LSP 460 * \ $ .... BFD Session 461 [R1] \ [CE2] $ Link 462 $ \ $ $ 463 $ \ $ 464 [CE1] [La](VPN label from L1 as UA label) 466 Figure 3: Locally Protect Egress for L3VPN Traffic 468 When R3 detects a failure in L1, R3 sends the traffic from primary 469 LSP via backup LSP to La, which delivers the traffic to CE2 using VPN 470 label under the backup LSP label as a context label. 472 4.2. PLR Procedure for Applications 474 When the PLR creates a backup LSP from itself to a backup egress for 475 protecting a primary egress, it includes an EGRESS_BACKUP_SUB_LSP 476 object in the Path message for the LSP. The object contains the 477 primary egress and the backup egress and indicates that the backup 478 egress SHOULD consider the backup LSP label as a context label and 479 the inner label as application traffic label when needed. 481 4.3. Egress Procedures for Applications 483 When a primary egress of an LSP sends the ingress of the LSP a label 484 for an application such as a VPN, it SHOULD sends the backup egress 485 for protecting the primary egress the label as a upstream assigned 486 label via BGP or another protocol. Exactly how the label is sent is 487 out of scope for this document. 489 When the backup egress receives a upstream assigned label from the 490 primary egress, it adds a forwarding entry with the label into the 491 LFIB for the primary egress. Using this entry, the backup egress 492 delivers the traffic with this label as inner label from the backup 493 LSP to the same destination as the primary egress. 495 When the backup egress receives a packet from the backup LSP, it uses 496 the top label as a context label to find the LFIB for the primary 497 egress and the inner label to deliver the packet to the same 498 destination as the primary egress according to the LFIB. 500 5. Security Considerations 502 In principle this document does not introduce new security issues. 503 The security considerations pertaining to RFC 4090, RFC 4875 and 504 other RSVP protocols remain relevant. 506 6. IANA Considerations 508 TBD 510 7. Contributors 512 Boris Zhang 513 Telus Communications 514 200 Consilium Pl Floor 15 515 Toronto, ON M1H 3J3 516 Canada 518 Email: Boris.Zhang@telus.com 520 Zhenbin Li 521 Huawei Technologies 522 Huawei Bld., No.156 Beiqing Rd. 523 Beijing 100095 524 China 526 Email: lizhenbin@huawei.com 528 Vic Liu 529 China Mobile 530 No.32 Xuanwumen West Street, Xicheng District 531 Beijing, 100053 532 China 534 8. Acknowledgement 536 The authors would like to thank Richard Li, Tarek Saad, Lizhong Jin, 537 Ravi Torvi, Eric Gray, Olufemi Komolafe, Michael Yue, Rob Rennison, 538 Neil Harrison, Kannan Sampath, Yimin Shen, Ronhazli Adam and Quintin 539 Zhao for their valuable comments and suggestions on this draft. 541 9. References 543 9.1. Normative References 545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", BCP 14, RFC 2119, March 1997. 548 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 549 Considered Useful", BCP 82, RFC 3692, January 2004. 551 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 552 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 553 Functional Specification", RFC 2205, September 1997. 555 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 556 Label Switching Architecture", RFC 3031, January 2001. 558 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 559 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 560 Tunnels", RFC 3209, December 2001. 562 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 563 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 564 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 566 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 567 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 568 May 2005. 570 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 571 "Extensions to Resource Reservation Protocol - Traffic 572 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 573 Switched Paths (LSPs)", RFC 4875, May 2007. 575 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 576 Label Assignment and Context-Specific Label Space", 577 RFC 5331, August 2008. 579 [P2MP FRR] 580 Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux, 581 "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", 582 draft-leroux-mpls-p2mp-te-bypass , March 1997. 584 9.2. Informative References 586 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 587 Multipoint Traffic-Engineered MPLS Label Switched Paths 588 (LSPs)", RFC 4461, April 2006. 590 Authors' Addresses 592 Huaimo Chen 593 Huawei Technologies 594 Boston, MA 595 USA 597 Email: huaimo.chen@huawei.com 599 Ning So 600 Tata Communications 601 2613 Fairbourne Cir. 602 Plano, TX 75082 603 USA 605 Email: ning.so@tatacommunications.com 607 Autumn Liu 608 Ericsson 609 CA 610 USA 612 Email: autumn.liu@ericsson.com 614 Fengman Xu 615 Verizon 616 2400 N. Glenville Dr 617 Richardson, TX 75082 618 USA 620 Email: fengman.xu@verizon.com 622 Mehmet Toy 623 Comcast 624 1800 Bishops Gate Blvd. 625 Mount Laurel, NJ 08054 626 USA 628 Email: mehmet_toy@cable.comcast.com 629 Lu Huang 630 China Mobile 631 No.32 Xuanwumen West Street, Xicheng District 632 Beijing, 100053 633 China 635 Email: huanglu@chinamobile.com 637 Lei Liu 638 UC Davis 639 USA 641 Email: liulei.kddi@gmail.com