idnits 2.17.1 draft-ietf-mpls-rsvp-egress-protection-01.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 date (July 3, 2014) is 3132 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 490, but not defined == Missing Reference: 'La' is mentioned on line 490, but not defined == Missing Reference: 'S' is mentioned on line 133, but not defined == Missing Reference: 'CE2' is mentioned on line 487, but not defined == Missing Reference: 'Lb' is mentioned on line 136, but not defined == Missing Reference: 'R1' is mentioned on line 487, but not defined == Missing Reference: 'R4' is mentioned on line 464, but not defined == Missing Reference: 'R5' is mentioned on line 464, but not defined == Unused Reference: 'RFC2119' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'RFC3692' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 585, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC5331' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'RFC5786' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'P2MP FRR' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 613, 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 Z. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 4, 2015 N. So 6 Tata Communications 7 A. Liu 8 Ericsson 9 F. Xu 10 Verizon 11 M. Toy 12 Comcast 13 L. Huang 14 China Mobile 15 L. Liu 16 UC Davis 17 July 3, 2014 19 Extensions to RSVP-TE for LSP Egress Local Protection 20 draft-ietf-mpls-rsvp-egress-protection-01.txt 22 Abstract 24 This document describes extensions to Resource Reservation Protocol - 25 Traffic Engineering (RSVP-TE) for locally protecting egress nodes of 26 a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- 27 Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 4, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. An Example of Egress Local Protection . . . . . . . . . . 3 65 1.2. Egress Local Protection with FRR . . . . . . . . . . . . . 4 66 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 69 4.1. EGRESS_BACKUP Object . . . . . . . . . . . . . . . . . . . 4 70 4.2. Flags in FAST_REROUTE . . . . . . . . . . . . . . . . . . 6 71 4.3. Path Message . . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Egress Protection Behaviors . . . . . . . . . . . . . . . . . 6 73 5.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 6 74 5.2. Intermediate Node and PLR Behavior . . . . . . . . . . . . 7 75 5.2.1. Signaling for One-to-One Protection . . . . . . . . . 8 76 5.2.2. Signaling for Facility Protection . . . . . . . . . . 8 77 5.2.3. Signaling for S2L Sub LSP Protection . . . . . . . . . 9 78 5.2.4. PLR Procedures during Local Repair . . . . . . . . . . 10 79 6. Considering Application Traffic . . . . . . . . . . . . . . . 10 80 6.1. A Typical Application . . . . . . . . . . . . . . . . . . 10 81 6.2. PLR Procedure for Applications . . . . . . . . . . . . . . 11 82 6.3. Egress Procedures for Applications . . . . . . . . . . . . 11 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 RFC 4090 describes two methods for protecting the transit nodes of a 95 P2P LSP: one-to-one and facility protection. RFC 4875 specifies how 96 to use them to protect the transit nodes of a P2MP LSP. However, 97 they do not mention any local protection for an egress of an LSP. 99 To protect the egresses of an LSP (P2P or P2MP), an existing approach 100 sets up a backup LSP from a backup ingress (or the ingress of the 101 LSP) to the backup egresses, where each egress is paired with a 102 backup egress and protected by the backup egress. 104 This approach may use more resources and provide slow fault recovery. 105 This document specifies extensions to RSVP-TE for local protection of 106 an egress of an LSP, which overcomes these disadvantages. 108 1.1. An Example of Egress Local Protection 110 Figure 1 shows an example of using backup LSPs to locally protect 111 egresses of a primary P2MP LSP from ingress R1 to two egresses: L1 112 and L2. The primary LSP is represented by star(*) lines and backup 113 LSPs by hyphen(-) lines. 115 La and Lb are the designated backup egresses for egresses L1 and L2 116 respectively. To distinguish an egress (e.g., L1) from a backup 117 egress (e.g., La), an egress is called a primary egress if needed. 119 The backup LSP for protecting L1 is from its upstream node R3 to 120 backup egress La. The one for protecting L2 is from R5 to Lb. 122 [R2]*****[R3]*****[L1] 123 * \ :.....: $ **** Primary LSP 124 * \ $ ---- Backup LSP 125 * \ [CE1] .... BFD Session 126 * \ $ $ Link 127 * \ $ $ 128 * [La] $ 129 * 130 [R1]******[R4]*******[R5]*****[L2] 131 $ \ :.....: $ 132 $ \ $ 133 [S] \ [CE2] 134 \ $ 135 \ $ 136 [Lb] 138 Figure 1: Backup LSP for Locally Protecting Egress 140 During normal operations, the traffic carried by the P2MP LSP is sent 141 through R3 to L1, which delivers the traffic to its destination CE1. 142 When R3 detects the failure of L1, R3 switches the traffic to the 143 backup LSP to backup egress La, which delivers the traffic to CE1. 144 The time for switching the traffic is within tens of milliseconds. 146 The failure of a primary egress (e.g., L1 in the figure) MAY be 147 detected by its upstream node (e.g., R3 in the figure) through a BFD 148 between the upstream node and the egress in MPLS networks. Exactly 149 how the failure is detected is out of scope for this document. 151 1.2. Egress Local Protection with FRR 153 Using the egress local protection and the FRR, we can locally protect 154 the egresses, the links and the intermediate nodes of an LSP. The 155 traffic switchover time is within tens of milliseconds whenever an 156 egress, any of the links and the intermediate nodes of the LSP fails. 158 The egress nodes of the LSP can be locally protected via the egress 159 local protection. All the links and the intermediate nodes of the 160 LSP can be locally protected through using the FRR. 162 2. Conventions Used in This Document 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119. 168 3. Terminology 170 This document uses terminologies defined in RFC 2205, RFC 3031, RFC 171 3209, RFC 3473, RFC 4090, RFC 4461, and RFC 4875. 173 4. Protocol Extensions 175 A new object EGRESS_BACKUP is defined for egress local protection. 176 It contains a backup egress for a primary egress. 178 4.1. EGRESS_BACKUP Object 180 The class of the EGRESS_BACKUP object is TBD-1 to be assigned by 181 IANA. The C-Type of the EGRESS_BACKUP IPv4/IPv6 object is TBD-2/ 182 TBD-3 to be assigned by IANA. 184 EGRESS_BACKUP Class Num = TBD-1, IPv4/IPv6 C-Type = TBD-2/TBD-3 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 ~ Backup Egress IPv4/IPv6 address ~ 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 ~ Primary Egress IPv4/IPv6 address ~ 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 ~ (Subobjects) ~ 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 o Backup Egress IPv4/IPv6 address: 197 IPv4/IPv6 address of the backup egress node 198 o Primary Egress IPv4/IPv6 address: 199 IPv4/IPv6 address of the primary egress node 201 The Subobjects are optional. One of them is P2P LSP ID IPv4/IPv6 202 subobject, whose body has the following format and Type is TBD-4/ 203 TBD-5. It may be used to identify a backup LSP. 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 ~ P2P LSP Tunnel Egress IPv4/IPv6 Address (4/16 bytes) ~ 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Reserved | Tunnel ID | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 ~ Extended Tunnel ID (4/16 bytes) ~ 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 o P2P LSP Tunnel Egress IPv4/IPv6 Address: 216 IPv4/IPv6 address of the egress of the tunnel 217 o Tunnel ID: 218 A 16-bit identifier that is constant over the life of the tunnel 219 o Extended Tunnel ID: 220 A 4/16-byte identifier being constant over the life of the tunnel 222 Another one is Label subobject, whose body has the format below and 223 Type is TBD-6 to be assigned by IANA. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Label | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 4.2. Flags in FAST_REROUTE 233 A bit of the flags in the FAST_REROUTE object may be used to indicate 234 whether S2L Sub LSP is desired for protecting an egress of a P2MP LSP 235 or One-to-One Backup is preferred for protecting an egress of a P2P 236 LSP when the "Facility Backup Desired" flag is set. This bit is 237 called "S2L Sub LSP Backup Desired" or "One-to-One Backup Preferred". 239 4.3. Path Message 241 A Path message is enhanced to carry the information about a backup 242 egress for a primary egress of an LSP through including an egress 243 backup descriptor list. The format of the enhanced Path message is 244 illustrated below. 246 ::= [ ] 247 [ [ | ] ...] 248 [ ] 249 [ ] 250 [ ] [ ...] 251 [ ] [ ] 252 [ ] [ ... ] 253 [] 254 [] 256 The egress backup descriptor list in the message is defined below. 257 It is a sequence of EGRESS_BACKUP objects, each of which describes a 258 pair of a primary egress and a backup egress. 260 ::= 261 262 [ ] 264 ::= 266 5. Egress Protection Behaviors 268 5.1. Ingress Behavior 270 To protect a primary egress of an LSP, the ingress MUST set the 271 "label recording desired" flag and the "node protection desired" flag 272 in the SESSION_ATTRIBUTE object. 274 If one-to-one backup or facility backup method is desired to protect 275 a primary egress of an LSP, the ingress SHOULD include a FAST_REROUTE 276 object and set the "One-to-One Backup Desired" or "Facility Backup 277 Desired" flag. 279 If S2L Sub LSP backup method is desired to protect a primary egress 280 of a P2MP LSP, the ingress SHOULD include a FAST_REROUTE object and 281 set the "S2L Sub LSP Backup Desired" flag. 283 Note that if "Facility Backup Desired" flag is set for protecting the 284 intermediate nodes of a primary P2P LSP, but we want to use "One-to- 285 One Backup" for protecting the egress of the LSP, then the ingress 286 SHOULD set "One-to-One Backup Preferred" flag. 288 Optionally, a backup egress may be configured on the ingress of an 289 LSP to protect a primary egress of the LSP. 291 The ingress sends a Path message for the LSP with the objects above 292 and an optional egress backup descriptor list. For each primary 293 egress of the LSP to be protected, the ingress adds an EGRESS_BACKUP 294 object into the list if the backup egress is given. The object 295 contains the primary egress and the backup egress for protecting the 296 primary egress. 298 5.2. Intermediate Node and PLR Behavior 300 If an intermediate node of an LSP receives the Path message with an 301 egress backup descriptor list and it is not an upstream node of any 302 primary egress of the LSP, it forwards the list unchanged. 304 If the intermediate node is the upstream node of a primary egress to 305 be protected, it determines the backup egress, obtains a path for the 306 backup LSP and sets up the backup LSP along the path. 308 The PLR (upstream node of the primary egress) tries to get the backup 309 egress from EGRESS_BACKUP in the egress backup descriptor list if the 310 Path message contains the list. If the PLR can not get it, the PLR 311 tries to find the backup egress, which is not the primary egress but 312 has the same IP address as the destination IP address of the LSP. 314 Note that the primary egress and the backup egress SHOULD have a same 315 local address configured, and the cost to the local address on the 316 backup egress SHOULD be much bigger than the cost to the local 317 address on the primary egress. Thus another name such as virtual 318 node based egress protection may be used for egress local protection. 320 After obtaining the backup egress, the PLR tries to compute a backup 321 path from itself to the backup egress. It excludes the primary 322 egress to be protected when computing the path. Thus the PLR will 323 not select any path via the primary egress. 325 The PLR then sets up the backup LSP along the path obtained. It 326 provides one-to-one backup protection for the primary egress if the 327 "One-to-One Backup Desired" or "One-to-One Backup Preferred" flag is 328 set in the message; otherwise, it provides facility backup protection 329 if the "Facility Backup Desired flag" is set. 331 The PLR sets the protection flags in the RRO Sub-object for the 332 primary egress in the Resv message according to the status of the 333 primary egress and the backup LSP protecting the primary egress. For 334 example, it will set the "local protection available" and the "node 335 protection" flag indicating that the primary egress is protected when 336 the backup LSP is up and ready for protecting the primary egress. 338 5.2.1. Signaling for One-to-One Protection 340 The behavior of the upstream node of a primary egress of an LSP as a 341 PLR is the same as that of a PLR for one-to-one backup method 342 described in RFC 4090 except for that the upstream node creates a 343 backup LSP from itself to a backup egress. 345 If the LSP is a P2MP LSP and a primary egress of the LSP is also a 346 transit node (i.e., bud node), the upstream node of the primary 347 egress as a PLR also creates a backup LSP from itself to each of the 348 next hops of the primary egress. 350 When the PLR detects the failure of the primary egress, it MUST 351 switch the packets from the primary LSP to the backup LSP to the 352 backup egress. For the failure of the bud node of a P2MP LSP, the 353 PLR MUST also switch the packets to the backup LSPs to the bud node's 354 next hops, where the packets are merged into the primary LSP. 356 5.2.2. Signaling for Facility Protection 358 Except for backup LSP and downstream label, the behavior of the 359 upstream node of the primary egress of a primary LSP as a PLR follows 360 the PLR behavior for facility backup method described in RFC 4090. 362 For a number of primary P2P LSPs going through the same PLR to the 363 same primary egress, the primary egress of these LSPs may be 364 protected by one backup LSP from the PLR to the backup egress 365 designated for protecting the primary egress. 367 The PLR selects or creates a backup LSP from itself to the backup 368 egress. If there is a backup LSP that satisfies the constraints 369 given in the Path message, then this one is selected; otherwise, a 370 new backup LSP to the backup egress will be created. 372 After getting the backup LSP, the PLR associates the backup LSP with 373 a primary LSP for protecting its primary egress. The PLR records 374 that the backup LSP is used to protect the primary LSP against its 375 primary egress failure and includes an EGRESS_BACKUP object in the 376 Path message to the primary egress. The object contains the backup 377 egress and the backup LSP ID. It indicates that the primary egress 378 SHOULD send the backup egress the primary LSP label as UA label. 380 After receiving the Path message with the EGRESS_BACKUP, the primary 381 egress includes the information about the primary LSP label in the 382 Resv message with an EGRESS_BACKUP object as UA label. When the PLR 383 receives the Resv message with the information about the UA label, it 384 includes the information in the Path message for the backup LSP to 385 the backup egress. Thus the primary LSP label as UA label is sent to 386 the backup egress from the primary egress. 388 When the PLR detects the failure of the primary egress, it redirects 389 the packets from the primary LSP into the backup LSP to backup egress 390 using the primary LSP label from the primary egress as an inner 391 label. The backup egress delivers the packets to the same 392 destinations as the primary egress using the backup LSP label as 393 context label and the inner label as UA label. 395 5.2.3. Signaling for S2L Sub LSP Protection 397 The S2L Sub LSP Protection is used to protect a primary egress of a 398 P2MP LSP. Its major advantage is that the application traffic 399 carried by the LSP is easily protected against the egress failure. 401 The PLR determines to protect a primary egress of a P2MP LSP via S2L 402 sub LSP protection when it receives a Path message with flag "S2L Sub 403 LSP Backup Desired" set. 405 The PLR sets up the backup S2L sub LSP to the backup egress, creates 406 and maintains its state in the same way as of setting up a source to 407 leaf (S2L) sub LSP defined in RFC 4875 from the signaling's point of 408 view. It computes a path for the backup LSP from itself to the 409 backup egress, constructs and sends a Path message along the path, 410 receives and processes a Resv message responding to the Path message. 412 After receiving the Resv message for the backup LSP, the PLR creates 413 a forwarding entry with an inactive state or flag called inactive 414 forwarding entry. This inactive forwarding entry is not used to 415 forward any data traffic during normal operations. 417 When the PLR detects the failure of the primary egress, it changes 418 the forwarding entry for the backup LSP to active. Thus, the PLR 419 forwards the traffic to the backup egress through the backup LSP, 420 which sends the traffic to its destination. 422 5.2.4. PLR Procedures during Local Repair 424 When the upstream node of a primary egress of an LSP as a PLR detects 425 the failure of the primary egress, it follows the procedures defined 426 in section 6.5 of RFC 4090. It SHOULD notify the ingress about the 427 failure of the primary egress in the same way as a PLR notifies the 428 ingress about the failure of an intermediate node. 430 Moreover, the PLR lets the upstream part of the primary LSP stay 431 after the primary egress fails. It continues to send resv message to 432 its upstream node along the primary LSP. The downstream part of the 433 primary LSP from the PLR to the primary egress SHOULD be removed. 435 In the local revertive mode, the PLR re-signals each of the primary 436 LSPs that were routed over the restored resource once it detects that 437 the resource is restored. Every primary LSP successfully re-signaled 438 along the restored resource is switched back. 440 6. Considering Application Traffic 442 This section focuses on the application traffic carried by P2P LSPs. 443 When a primary egress of a P2MP LSP fails, the application traffic 444 carried by the P2MP LSP is delivered to the same destination by the 445 backup egress since the inner label if any for the traffic is a 446 upstream assigned label for every egress of the P2MP LSP. 448 6.1. A Typical Application 450 L3VPN is a typical application. An existing solution (refer to 451 Figure 2) for protecting L3VPN traffic against egress failure 452 includes: 1) A multi-hop BFD session between ingress R1 and egress L1 453 of primary LSP; 2) A backup LSP from ingress R1 to backup egress La; 454 3) La sends R1 VPN backup label and related information via BGP; 4) 455 R1 has a VRF with two sets of routes: one uses primary LSP and L1 as 456 next hop; the other uses backup LSP and La as next hop. 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] [R4]-----[R5]-----[La](BGP sends R1 VPN backup label) 466 Figure 2: Protect Egress for L3VPN Traffic 468 In normal operations, R1 sends the traffic from CE1 through primary 469 LSP with VPN label received from L1 as inner label to L1, which 470 delivers the traffic to CE2 using VPN label. 472 When R1 detects the failure of L1, R1 sends the traffic from CE1 via 473 backup LSP with VPN backup label received from La as inner label to 474 La, which delivers the traffic to CE2 using VPN backup label. 476 A new solution (refer to Figure 3) with egress local protection for 477 protecting L3VPN traffic includes: 1) A BFD session between R3 and 478 egress L1 of primary LSP; 2) A backup LSP from R3 to backup egress 479 La; 3) L1 sends La VPN label as UA label and related information; 4) 480 L1 and La is virtualized as one. This can be achieved by configuring 481 a same local address on L1 and La, using the address as a destination 482 of the LSP and BGP next hop for VPN traffic. 484 CE1,CE2 in [R2]*****[R3]*****[L1] **** Primary LSP 485 one VPN * \ :.....: $ ---- Backup LSP 486 * \ $ .... BFD Session 487 [R1] \ [CE2] $ Link 488 $ \ $ $ 489 $ \ $ 490 [CE1] [La](VPN label from L1 as UA label) 492 Figure 3: Locally Protect Egress for L3VPN Traffic 494 When R3 detects L1's failure, R3 sends the traffic from primary LSP 495 via backup LSP to La, which delivers the traffic to CE2 using VPN 496 label as UA label under the backup LSP label as a context label. 498 6.2. PLR Procedure for Applications 500 When the PLR gets a backup LSP from itself to a backup egress for 501 protecting a primary egress of a primary LSP, it includes an 502 EGRESS_BACKUP object in the Path message for the primary LSP. The 503 object contains the ID information of the backup LSP and indicates 504 that the primary egress SHOULD send the backup egress the application 505 traffic label (e.g., VPN label) as UA label when needed. 507 6.3. Egress Procedures for Applications 509 When a primary egress of an LSP sends the ingress of the LSP a label 510 for an application such as a VPN, it SHOULD send the backup egress 511 for protecting the primary egress the label as a UA label via BGP or 512 another protocol. Exactly how the label is sent is out of scope for 513 this document. 515 When the backup egress receives a UA label from the primary egress, 516 it adds a forwarding entry with the label into the LFIB for the 517 primary egress. When the backup egress receives a packet from the 518 backup LSP, it uses the top label as a context label to find the LFIB 519 for the primary egress and the inner label to deliver the packet to 520 the same destination as the primary egress according to the LFIB. 522 7. Security Considerations 524 In principle this document does not introduce new security issues. 525 The security considerations pertaining to RFC 4090, RFC 4875 and 526 other RSVP protocols remain relevant. 528 8. IANA Considerations 530 IANA considerations for new objects will be specified after the 531 objects used are decided upon. 533 9. Contributors 535 Boris Zhang 536 Telus Communications 537 200 Consilium Pl Floor 15 538 Toronto, ON M1H 3J3 539 Canada 540 Email: Boris.Zhang@telus.com 542 Nan Meng 543 Huawei Technologies 544 Huawei Bld., No.156 Beiqing Rd. 545 Beijing 100095 546 China 547 Email: mengnan@huawei.com 549 Vic Liu 550 China Mobile 551 No.32 Xuanwumen West Street, Xicheng District 552 Beijing, 100053 553 China 554 Email: liuzhiheng@chinamobile.com 556 10. Acknowledgement 558 The authors would like to thank Richard Li, Nobo Akiya, Tarek Saad, 559 Lizhong Jin, Ravi Torvi, Eric Gray, Olufemi Komolafe, Michael Yue, 560 Rob Rennison, Neil Harrison, Kannan Sampath, Yimin Shen, Ronhazli 561 Adam and Quintin Zhao for their valuable comments and suggestions on 562 this draft. 564 11. References 566 11.1. Normative References 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, March 1997. 571 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 572 Considered Useful", BCP 82, RFC 3692, January 2004. 574 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 575 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 576 Functional Specification", RFC 2205, September 1997. 578 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 579 Label Switching Architecture", RFC 3031, January 2001. 581 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 582 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 583 Tunnels", RFC 3209, December 2001. 585 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 586 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 587 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 589 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 590 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 591 May 2005. 593 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 594 "Extensions to Resource Reservation Protocol - Traffic 595 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 596 Switched Paths (LSPs)", RFC 4875, May 2007. 598 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 599 Label Assignment and Context-Specific Label Space", 600 RFC 5331, August 2008. 602 [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's 603 Local Addresses in OSPF Traffic Engineering (TE) 604 Extensions", RFC 5786, March 2010. 606 [P2MP FRR] 607 Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux, 608 "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", 609 draft-leroux-mpls-p2mp-te-bypass , March 1997. 611 11.2. Informative References 613 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 614 Multipoint Traffic-Engineered MPLS Label Switched Paths 615 (LSPs)", RFC 4461, April 2006. 617 Authors' Addresses 619 Huaimo Chen 620 Huawei Technologies 621 Boston, MA 622 USA 624 Email: huaimo.chen@huawei.com 626 Zhenbin Li 627 Huawei Technologies 628 Huawei Bld., No.156 Beiqing Rd. 629 Beijing 100095, 630 China 632 Email: lizhenbin@huawei.com 634 Ning So 635 Tata Communications 636 2613 Fairbourne Cir. 637 Plano, TX 75082 638 USA 640 Email: ningso01@gmail.com 641 Autumn Liu 642 Ericsson 643 CA 644 USA 646 Email: autumn.liu@ericsson.com 648 Fengman Xu 649 Verizon 650 2400 N. Glenville Dr 651 Richardson, TX 75082 652 USA 654 Email: fengman.xu@verizon.com 656 Mehmet Toy 657 Comcast 658 1800 Bishops Gate Blvd. 659 Mount Laurel, NJ 08054 660 USA 662 Email: mehmet_toy@cable.comcast.com 664 Lu Huang 665 China Mobile 666 No.32 Xuanwumen West Street, Xicheng District 667 Beijing, 100053 668 China 670 Email: huanglu@chinamobile.com 672 Lei Liu 673 UC Davis 674 USA 676 Email: liulei.kddi@gmail.com