idnits 2.17.1 draft-ietf-mpls-rsvp-egress-protection-02.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 (October 26, 2014) is 3469 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 502, but not defined == Missing Reference: 'La' is mentioned on line 502, but not defined == Missing Reference: 'S' is mentioned on line 137, but not defined == Missing Reference: 'CE2' is mentioned on line 499, but not defined == Missing Reference: 'Lb' is mentioned on line 140, but not defined == Missing Reference: 'R1' is mentioned on line 499, but not defined == Missing Reference: 'R4' is mentioned on line 476, but not defined == Missing Reference: 'R5' is mentioned on line 476, but not defined == Unused Reference: 'RFC2119' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'RFC3692' is defined on line 608, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'RFC5331' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'RFC5786' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'P2MP FRR' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 650, 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: April 29, 2015 N. So 6 Tata Communications 7 A. Liu 8 Ericsson 9 T. Saad 10 Cisco Systems 11 F. Xu 12 Verizon 13 M. Toy 14 Comcast 15 L. Huang 16 China Mobile 17 L. Liu 18 UC Davis 19 October 26, 2014 21 Extensions to RSVP-TE for LSP Egress Local Protection 22 draft-ietf-mpls-rsvp-egress-protection-02.txt 24 Abstract 26 This document describes extensions to Resource Reservation Protocol - 27 Traffic Engineering (RSVP-TE) for locally protecting egress nodes of 28 a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- 29 Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 29, 2015. 48 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. An Example of Egress Local Protection . . . . . . . . . . 3 66 1.2. Egress Local Protection with FRR . . . . . . . . . . . . . 4 67 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 70 4.1. EGRESS_BACKUP Object . . . . . . . . . . . . . . . . . . . 4 71 4.2. Flags in FAST_REROUTE . . . . . . . . . . . . . . . . . . 6 72 4.3. Path Message . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Egress Protection Behaviors . . . . . . . . . . . . . . . . . 6 74 5.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 7 75 5.2. Transit Node and PLR Behavior . . . . . . . . . . . . . . 7 76 5.2.1. Signaling for One-to-One Protection . . . . . . . . . 8 77 5.2.2. Signaling for Facility Protection . . . . . . . . . . 8 78 5.2.3. Signaling for S2L Sub LSP Protection . . . . . . . . . 9 79 5.2.4. PLR Procedures during Local Repair . . . . . . . . . . 10 80 6. Considering Application Traffic . . . . . . . . . . . . . . . 10 81 6.1. A Typical Application . . . . . . . . . . . . . . . . . . 10 82 6.2. PLR Procedure for Applications . . . . . . . . . . . . . . 11 83 6.3. Egress Procedures for Applications . . . . . . . . . . . . 12 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 8.1. New RSVP C-Num and C-Types . . . . . . . . . . . . . . . . 12 87 8.2. New TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 8.3. Flags in FAST_REROUTE . . . . . . . . . . . . . . . . . . 13 89 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 RFC 4090 describes two methods for protecting the transit nodes of a 99 P2P LSP: one-to-one and facility protection. RFC 4875 specifies how 100 to use them to protect the transit nodes of a P2MP LSP. However, 101 they do not mention any local protection for an egress of an LSP. 103 To protect the egresses of an LSP (P2P or P2MP), an existing approach 104 sets up a backup LSP from a backup ingress (or the ingress of the 105 LSP) to the backup egresses, where each egress is paired with a 106 backup egress and protected by the backup egress. 108 This approach may use more resources and provide slow fault recovery. 109 This document specifies extensions to RSVP-TE for local protection of 110 an egress of an LSP, which overcomes these disadvantages. 112 1.1. An Example of Egress Local Protection 114 Figure 1 shows an example of using backup LSPs to locally protect 115 egresses of a primary P2MP LSP from ingress R1 to two egresses: L1 116 and L2. The primary LSP is represented by star(*) lines and backup 117 LSPs by hyphen(-) lines. 119 La and Lb are the designated backup egresses for egresses L1 and L2 120 respectively. To distinguish an egress (e.g., L1) from a backup 121 egress (e.g., La), an egress is called a primary egress if needed. 123 The backup LSP for protecting L1 is from its upstream node R3 to 124 backup egress La. The one for protecting L2 is from R5 to Lb. 126 [R2]*****[R3]*****[L1] 127 * \ :.....: $ **** Primary LSP 128 * \ $ ---- Backup LSP 129 * \ [CE1] .... BFD Session 130 * \ $ $ Link 131 * \ $ $ 132 * [La] $ 133 * 134 [R1]******[R4]*******[R5]*****[L2] 135 $ \ :.....: $ 136 $ \ $ 137 [S] \ [CE2] 138 \ $ 139 \ $ 140 [Lb] 142 Figure 1: Backup LSP for Locally Protecting Egress 144 During normal operations, the traffic carried by the P2MP LSP is sent 145 through R3 to L1, which delivers the traffic to its destination CE1. 146 When R3 detects the failure of L1, R3 switches the traffic to the 147 backup LSP to backup egress La, which delivers the traffic to CE1. 148 The time for switching the traffic is within tens of milliseconds. 150 The failure of a primary egress (e.g., L1 in the figure) MAY be 151 detected by its upstream node (e.g., R3 in the figure) through a BFD 152 between the upstream node and the egress in MPLS networks. Exactly 153 how the failure is detected is out of scope for this document. 155 1.2. Egress Local Protection with FRR 157 Using the egress local protection and the FRR, we can locally protect 158 the egresses, the links and the transit nodes of an LSP. The traffic 159 switchover time is within tens of milliseconds whenever an egress, 160 any of the links and the transit nodes of the LSP fails. 162 The egress nodes of the LSP can be locally protected via the egress 163 local protection. All the links and the transit nodes of the LSP can 164 be locally protected through using the FRR. 166 2. Conventions Used in This Document 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119. 172 3. Terminology 174 This document uses terminologies defined in RFC 2205, RFC 3031, RFC 175 3209, RFC 3473, RFC 4090, RFC 4461, and RFC 4875. 177 4. Protocol Extensions 179 A new object EGRESS_BACKUP is defined for egress local protection. 180 It contains a backup egress for a primary egress. 182 4.1. EGRESS_BACKUP Object 184 The class of the EGRESS_BACKUP object is TBD-1 to be assigned by 185 IANA. The C-Type of the EGRESS_BACKUP IPv4/IPv6 object is TBD-2/ 186 TBD-3 to be assigned by IANA. 188 EGRESS_BACKUP Class Num = TBD-1, IPv4/IPv6 C-Type = TBD-2/TBD-3 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 ~ Backup Egress IPv4/IPv6 address ~ 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 ~ Primary Egress IPv4/IPv6 address ~ 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 ~ (Subobjects) ~ 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 o Backup Egress IPv4/IPv6 address: 201 IPv4/IPv6 address of the backup egress node 202 o Primary Egress IPv4/IPv6 address: 203 IPv4/IPv6 address of the primary egress node 205 The Subobjects are TLVs and optional. One of them is P2P LSP ID 206 IPv4/IPv6 subobject, whose body has the following format and Type is 207 TBD-4/TBD-5. It may be used to identify a backup LSP. 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 ~ P2P LSP Tunnel Egress IPv4/IPv6 Address (4/16 bytes) ~ 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Reserved | Tunnel ID | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 ~ Extended Tunnel ID (4/16 bytes) ~ 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 o P2P LSP Tunnel Egress IPv4/IPv6 Address: 220 IPv4/IPv6 address of the egress of the tunnel 221 o Tunnel ID: 222 A 16-bit identifier that is constant over the life of the tunnel 223 o Extended Tunnel ID: 224 A 4/16-byte identifier being constant over the life of the tunnel 226 Another one is Label subobject, whose body has the format below and 227 Type is TBD-6 to be assigned by IANA. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Label | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 ~ (sub-TLVs ) ~ 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 The sub-TLVs are optional. 239 4.2. Flags in FAST_REROUTE 241 Two new bits of the flags in the FAST_REROUTE object may be defined. 242 One bit (called "S2L Sub LSP Backup Desired" flag) indicates whether 243 S2L Sub LSP is desired for protecting an egress of a P2MP LSP. When 244 a S2L Sub LSP is desired for protecting an egress of a P2MP LSP, we 245 should set this flag to one. 247 The other bit (called "Other Sending UA Label" flag) indicates if 248 another protocol is desired for sending a label as a UA label from a 249 primary egress to a backup egress. When we want other protocol such 250 as BGP to send a label as UA label, this flag should be set to one. 252 4.3. Path Message 254 A Path message is enhanced to carry the information about a backup 255 egress for a primary egress of an LSP by including an egress backup 256 descriptor list. The format of the message is illustrated below. 258 ::= [ ] 259 [ [ | ] ...] 260 [ ] 261 [ ] 262 [ ] [ ...] 263 [ ] [ ] 264 [ ] [ ... ] 265 [] 266 [] 268 The egress backup descriptor list in the message is defined below. 269 It is a sequence of EGRESS_BACKUP objects, each of which describes a 270 pair of a primary egress and a backup egress. 272 ::= 273 274 [ ] 276 ::= 278 5. Egress Protection Behaviors 279 5.1. Ingress Behavior 281 To protect a primary egress of an LSP, the ingress MUST set the 282 "label recording desired" flag and the "node protection desired" flag 283 in the SESSION_ATTRIBUTE object. 285 If one-to-one backup or facility backup method is desired to protect 286 a primary egress of an LSP, the ingress SHOULD include a FAST_REROUTE 287 object and set the "One-to-One Backup Desired" or "Facility Backup 288 Desired" flag. 290 If S2L Sub LSP backup method is desired to protect a primary egress 291 of a P2MP LSP, the ingress SHOULD include a FAST_REROUTE object and 292 set the "S2L Sub LSP Backup Desired" flag. 294 If another protocol is desired for sending a label as a upstream 295 assigned label to a backup egress, the ingress SHOULD set the "Other 296 Sending UA Label" flag. 298 Optionally, a backup egress may be configured on the ingress of an 299 LSP to protect a primary egress of the LSP. 301 The ingress sends a Path message for the LSP with the objects above 302 and an optional egress backup descriptor list. For each primary 303 egress of the LSP to be protected, the ingress adds an EGRESS_BACKUP 304 object into the list if the backup egress is given. The object 305 contains the primary egress and the backup egress for protecting the 306 primary egress. 308 5.2. Transit Node and PLR Behavior 310 If a transit node of an LSP receives the Path message with an egress 311 backup descriptor list and it is not an upstream node of any primary 312 egress of the LSP, it forwards the list unchanged. 314 If the transit node is the upstream node of a primary egress to be 315 protected, it determines the backup egress, obtains a path for the 316 backup LSP and sets up the backup LSP along the path. 318 The PLR (upstream node of the primary egress) extracts the backup 319 egress from the respective EGRESS_BACKUP object in the egress backup 320 descriptor list. If no matching EGRESS_BACKUP object is found or the 321 list is empty, the PLR may apply a local policy to determine the 322 backup egress and add an EGRESS_BACKUP object with the backup egress 323 and primary egress into a Path message to the primary egress. 325 After obtaining the backup egress, the PLR tries to compute a backup 326 path from itself to the backup egress. It excludes the primary 327 egress to be protected when computing the path. Thus the PLR will 328 not select any path via the primary egress. 330 The PLR then sets up the backup LSP along the path obtained. It 331 provides one-to-one backup protection for the primary egress if the 332 "One-to-One Backup Desired" flag is set in the message; otherwise, it 333 provides facility backup protection if the "Facility Backup Desired 334 flag" is set. 336 The PLR sets the protection flags in the RRO Sub-object for the 337 primary egress in the Resv message according to the status of the 338 primary egress and the backup LSP protecting the primary egress. For 339 example, it will set the "local protection available" and the "node 340 protection" flag indicating that the primary egress is protected when 341 the backup LSP is up and ready for protecting the primary egress. 343 5.2.1. Signaling for One-to-One Protection 345 The behavior of the upstream node of a primary egress of an LSP as a 346 PLR is the same as that of a PLR for one-to-one backup method 347 described in RFC 4090 except for that the upstream node creates a 348 backup LSP from itself to a backup egress. 350 If the LSP is a P2MP LSP and a primary egress of the LSP is also a 351 transit node (i.e., bud node), the upstream node of the primary 352 egress as a PLR also creates a backup LSP from itself to each of the 353 next hops of the primary egress. 355 When the PLR detects the failure of the primary egress, it MUST 356 switch the packets from the primary LSP to the backup LSP to the 357 backup egress. For the failure of the bud node of a P2MP LSP, the 358 PLR MUST also switch the packets to the backup LSPs to the bud node's 359 next hops, where the packets are merged into the primary LSP. 361 5.2.2. Signaling for Facility Protection 363 Except for backup LSP and downstream label, the behavior of the 364 upstream node of the primary egress of a primary LSP as a PLR follows 365 the PLR behavior for facility backup method described in RFC 4090. 367 For a number of primary P2P LSPs going through the same PLR to the 368 same primary egress, the primary egress of these LSPs may be 369 protected by one backup LSP from the PLR to the backup egress 370 designated for protecting the primary egress. 372 The PLR selects or creates a backup LSP from itself to the backup 373 egress. If there is a backup LSP that satisfies the constraints 374 given in the Path message, then this one is selected; otherwise, a 375 new backup LSP to the backup egress will be created. 377 After getting the backup LSP, the PLR associates the backup LSP with 378 a primary LSP for protecting its primary egress. The PLR records 379 that the backup LSP is used to protect the primary LSP against its 380 primary egress failure and includes an EGRESS_BACKUP object in the 381 Path message to the primary egress. The object contains the backup 382 egress and the backup LSP ID. It indicates that the primary egress 383 SHOULD send the backup egress the service label as UA label if there 384 is a service carried by the LSP and the primary LSP label as UA label 385 if the label is not implicit null. 387 A UA label can be sent via RSVP or another protocol (e.g., BGP). If 388 "Other Sending UA Label" flag is one, the primary egress SHOULD send 389 the UA labels to the backup egress through another protocol; 390 otherwise, UA labels are sent via RSVP. 392 After receiving the Path message with the EGRESS_BACKUP, the primary 393 egress includes the information about the UA labels in the Resv 394 message with an EGRESS_BACKUP object. When the PLR receives the Resv 395 message with the information about the UA labels, it includes the 396 information in the Path message for the backup LSP to the backup 397 egress. Thus the UA labels are sent to the backup egress from the 398 primary egress via RSVP. 400 When the PLR detects the failure of the primary egress, it redirects 401 the packets from the primary LSP into the backup LSP to backup egress 402 and keeps the primary LSP label from the primary egress in the label 403 stack if the label is not implicit null. The backup egress delivers 404 the packets to the same destinations as the primary egress using the 405 backup LSP label as context label and the labels under as UA labels. 407 5.2.3. Signaling for S2L Sub LSP Protection 409 The S2L Sub LSP Protection is used to protect a primary egress of a 410 P2MP LSP. Its major advantage is that the application traffic 411 carried by the LSP is easily protected against the egress failure. 413 The PLR determines to protect a primary egress of a P2MP LSP via S2L 414 sub LSP protection when it receives a Path message with flag "S2L Sub 415 LSP Backup Desired" set. 417 The PLR sets up the backup S2L sub LSP to the backup egress, creates 418 and maintains its state in the same way as of setting up a source to 419 leaf (S2L) sub LSP defined in RFC 4875 from the signaling's point of 420 view. It computes a path for the backup LSP from itself to the 421 backup egress, constructs and sends a Path message along the path, 422 receives and processes a Resv message responding to the Path message. 424 After receiving the Resv message for the backup LSP, the PLR creates 425 a forwarding entry with an inactive state or flag called inactive 426 forwarding entry. This inactive forwarding entry is not used to 427 forward any data traffic during normal operations. 429 When the PLR detects the failure of the primary egress, it changes 430 the forwarding entry for the backup LSP to active. Thus, the PLR 431 forwards the traffic to the backup egress through the backup LSP, 432 which sends the traffic to its destination. 434 5.2.4. PLR Procedures during Local Repair 436 When the upstream node of a primary egress of an LSP as a PLR detects 437 the failure of the primary egress, it follows the procedures defined 438 in section 6.5 of RFC 4090. It SHOULD notify the ingress about the 439 failure of the primary egress in the same way as a PLR notifies the 440 ingress about the failure of a transit node. 442 Moreover, the PLR lets the upstream part of the primary LSP stay 443 after the primary egress fails. It continues to send Resv message to 444 its upstream node along the primary LSP. The downstream part of the 445 primary LSP from the PLR to the primary egress SHOULD be removed. 447 In the local revertive mode, the PLR re-signals each of the primary 448 LSPs that were routed over the restored resource once it detects that 449 the resource is restored. Every primary LSP successfully re-signaled 450 along the restored resource is switched back. 452 6. Considering Application Traffic 454 This section focuses on the application traffic carried by P2P LSPs. 455 When a primary egress of a P2MP LSP fails, the application traffic 456 carried by the P2MP LSP is delivered to the same destination by the 457 backup egress since the inner label if any for the traffic is a 458 upstream assigned label for every egress of the P2MP LSP. 460 6.1. A Typical Application 462 L3VPN is a typical application. An existing solution (refer to 463 Figure 2) for protecting L3VPN traffic against egress failure 464 includes: 1) A multi-hop BFD session between ingress R1 and egress L1 465 of primary LSP; 2) A backup LSP from ingress R1 to backup egress La; 466 3) La sends R1 VPN backup label and related information via BGP; 4) 467 R1 has a VRF with two sets of routes: one uses primary LSP and L1 as 468 next hop; the other uses backup LSP and La as next hop. 470 CE1,CE2 in [R2]*****[R3]*****[L1] **** Primary LSP 471 one VPN * : $ ---- Backup LSP 472 * .................: $ .... BFD Session 473 [R1] ..: [CE2] $ Link 474 $ \ $ $ 475 $ \ $ 476 [CE1] [R4]-----[R5]-----[La](BGP sends R1 VPN backup label) 478 Figure 2: Protect Egress for L3VPN Traffic 480 In normal operations, R1 sends the traffic from CE1 through primary 481 LSP with VPN label received from L1 as inner label to L1, which 482 delivers the traffic to CE2 using VPN label. 484 When R1 detects the failure of L1, R1 sends the traffic from CE1 via 485 backup LSP with VPN backup label received from La as inner label to 486 La, which delivers the traffic to CE2 using VPN backup label. 488 A new solution (refer to Figure 3) with egress local protection for 489 protecting L3VPN traffic includes: 1) A BFD session between R3 and 490 egress L1 of primary LSP; 2) A backup LSP from R3 to backup egress 491 La; 3) L1 sends La VPN label as UA label and related information; 4) 492 L1 and La is virtualized as one. This can be achieved by configuring 493 a same local address on L1 and La, using the address as a destination 494 of the LSP and BGP next hop for VPN traffic. 496 CE1,CE2 in [R2]*****[R3]*****[L1] **** Primary LSP 497 one VPN * \ :.....: $ ---- Backup LSP 498 * \ $ .... BFD Session 499 [R1] \ [CE2] $ Link 500 $ \ $ $ 501 $ \ $ 502 [CE1] [La](VPN label from L1 as UA label) 504 Figure 3: Locally Protect Egress for L3VPN Traffic 506 When R3 detects L1's failure, R3 sends the traffic from primary LSP 507 via backup LSP to La, which delivers the traffic to CE2 using VPN 508 label as UA label under the backup LSP label as a context label. 510 6.2. PLR Procedure for Applications 512 When the PLR gets a backup LSP from itself to a backup egress for 513 protecting a primary egress of a primary LSP, it includes an 514 EGRESS_BACKUP object in the Path message for the primary LSP. The 515 object contains the ID information of the backup LSP and indicates 516 that the primary egress SHOULD send the backup egress the application 517 traffic label (e.g., VPN label) as UA label when needed. 519 6.3. Egress Procedures for Applications 521 When a primary egress of an LSP sends the ingress of the LSP a label 522 for an application such as a VPN, it SHOULD send the backup egress 523 for protecting the primary egress the label as a UA label. Exactly 524 how the label is sent is out of scope for this document. 526 When the backup egress receives a UA label from the primary egress, 527 it adds a forwarding entry with the label into the LFIB for the 528 primary egress. When the backup egress receives a packet from the 529 backup LSP, it uses the top label as a context label to find the LFIB 530 for the primary egress and the inner label to deliver the packet to 531 the same destination as the primary egress according to the LFIB. 533 7. Security Considerations 535 In principle this document does not introduce new security issues. 536 The security considerations pertaining to RFC 4090, RFC 4875 and 537 other RSVP protocols remain relevant. 539 8. IANA Considerations 541 8.1. New RSVP C-Num and C-Types 543 This document defines a new C-Num, which should be assigned by IANA. 545 o EGRESS_BACKUP object. The C-Num should be of the form 11bbbbbb so 546 that LSRs that do not recognize it will ignore it but forward it. 548 Two C-Types defined for this object should be assigned by IANA. 550 - EGRESS_BACKUP_IPv4. Recommended C-Type value 1. 551 - EGRESS_BACKUP_IPv6. Recommended C-Type value 2. 553 8.2. New TLVs 555 The new object referenced above contains TLVs. This document defines 556 three TLV types as follows: 558 Type Name Allowed on 559 1 P2P_LSP_ID_IPv4 TLV EGRESS_BACKUP_IPv4 560 2 P2P_LSP_ID_IPv6 TLV EGRESS_BACKUP_IPv6 561 3 Label TLV EGRESS_BACKUP_IPv4/IPv6 563 8.3. Flags in FAST_REROUTE 565 Two flags defined in FAST_REROUTE object should be assigned by IANA. 567 0x04 S2L Sub LSP Backup Desired 568 0x08 Other Sending UA Label 570 9. Contributors 572 Boris Zhang 573 Telus Communications 574 200 Consilium Pl Floor 15 575 Toronto, ON M1H 3J3 576 Canada 577 Email: Boris.Zhang@telus.com 579 Nan Meng 580 Huawei Technologies 581 Huawei Bld., No.156 Beiqing Rd. 582 Beijing 100095 583 China 584 Email: mengnan@huawei.com 586 Vic Liu 587 China Mobile 588 No.32 Xuanwumen West Street, Xicheng District 589 Beijing, 100053 590 China 591 Email: liuzhiheng@chinamobile.com 593 10. Acknowledgement 595 The authors would like to thank Richard Li, Nobo Akiya, Jeffrey 596 Zhang, Lizhong Jin, Ravi Torvi, Eric Gray, Olufemi Komolafe, Michael 597 Yue, Daniel King, Rob Rennison, Neil Harrison, Kannan Sampath, Yimin 598 Shen, Ronhazli Adam and Quintin Zhao for their valuable comments and 599 suggestions on this draft. 601 11. References 603 11.1. Normative References 605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 606 Requirement Levels", BCP 14, RFC 2119, March 1997. 608 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 609 Considered Useful", BCP 82, RFC 3692, January 2004. 611 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 612 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 613 Functional Specification", RFC 2205, September 1997. 615 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 616 Label Switching Architecture", RFC 3031, January 2001. 618 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 619 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 620 Tunnels", RFC 3209, December 2001. 622 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 623 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 624 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 626 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 627 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 628 May 2005. 630 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 631 "Extensions to Resource Reservation Protocol - Traffic 632 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 633 Switched Paths (LSPs)", RFC 4875, May 2007. 635 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 636 Label Assignment and Context-Specific Label Space", 637 RFC 5331, August 2008. 639 [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's 640 Local Addresses in OSPF Traffic Engineering (TE) 641 Extensions", RFC 5786, March 2010. 643 [P2MP FRR] 644 Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux, 645 "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", 646 draft-leroux-mpls-p2mp-te-bypass , March 1997. 648 11.2. Informative References 650 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 651 Multipoint Traffic-Engineered MPLS Label Switched Paths 652 (LSPs)", RFC 4461, April 2006. 654 Authors' Addresses 656 Huaimo Chen 657 Huawei Technologies 658 Boston, MA 659 USA 661 Email: huaimo.chen@huawei.com 663 Zhenbin Li 664 Huawei Technologies 665 Huawei Bld., No.156 Beiqing Rd. 666 Beijing 100095, 667 China 669 Email: lizhenbin@huawei.com 671 Ning So 672 Tata Communications 673 2613 Fairbourne Cir. 674 Plano, TX 75082 675 USA 677 Email: ningso01@gmail.com 679 Autumn Liu 680 Ericsson 681 CA 682 USA 684 Email: autumn.liu@ericsson.com 686 Tarek Saad 687 Cisco Systems 689 Email: tsaad@cisco.com 690 Fengman Xu 691 Verizon 692 2400 N. Glenville Dr 693 Richardson, TX 75082 694 USA 696 Email: fengman.xu@verizon.com 698 Mehmet Toy 699 Comcast 700 1800 Bishops Gate Blvd. 701 Mount Laurel, NJ 08054 702 USA 704 Email: mehmet_toy@cable.comcast.com 706 Lu Huang 707 China Mobile 708 No.32 Xuanwumen West Street, Xicheng District 709 Beijing, 100053 710 China 712 Email: huanglu@chinamobile.com 714 Lei Liu 715 UC Davis 716 USA 718 Email: liulei.kddi@gmail.com