idnits 2.17.1 draft-ietf-teas-rsvp-egress-protection-08.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 (August 3, 2017) is 2458 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 663, but not defined == Missing Reference: 'S' is mentioned on line 135, but not defined == Missing Reference: 'CE2' is mentioned on line 660, but not defined == Missing Reference: 'R1' is mentioned on line 660, but not defined == Missing Reference: 'R4' is mentioned on line 637, but not defined == Missing Reference: 'R5' is mentioned on line 637, but not defined == Missing Reference: 'La' is mentioned on line 663, but not defined == Unused Reference: 'RFC3209' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 787, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 792, but no explicit reference was found in the text == Unused Reference: 'RFC4873' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 810, but no explicit reference was found in the text == Unused Reference: 'RFC5331' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'RFC4872' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 826, but no explicit reference was found in the text == Unused Reference: 'FRAMEWK' is defined on line 832, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 18 warnings (==), 1 comment (--). 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 A. Liu 5 Expires: February 4, 2018 Ciena 6 T. Saad 7 Cisco Systems 8 F. Xu 9 Verizon 10 L. Huang 11 China Mobile 12 N. So 13 Tata Communications 14 August 3, 2017 16 Extensions to RSVP-TE for LSP Egress Local Protection 17 draft-ietf-teas-rsvp-egress-protection-08.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) Label Switched Path (LSP), which is a 24 Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 4, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. An Example of Egress Local Protection . . . . . . . . . . 3 62 1.2. Egress Local Protection with FRR . . . . . . . . . . . . . 4 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Extensions to SERO . . . . . . . . . . . . . . . . . . . . 4 67 4.1.1. Primary Egress Subobject . . . . . . . . . . . . . . . 6 68 4.1.2. P2P LSP ID Subobject . . . . . . . . . . . . . . . . . 7 69 4.1.3. Opaque Data Subobject . . . . . . . . . . . . . . . . 8 70 5. Egress Protection Behaviors . . . . . . . . . . . . . . . . . 8 71 5.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 9 72 5.2. Primary Egress Behavior . . . . . . . . . . . . . . . . . 9 73 5.3. Backup Egress Behavior . . . . . . . . . . . . . . . . . . 10 74 5.4. Transit Node and PLR Behavior . . . . . . . . . . . . . . 10 75 5.4.1. Signaling for One-to-One Protection . . . . . . . . . 11 76 5.4.2. Signaling for Facility Protection . . . . . . . . . . 12 77 5.4.3. Signaling for S2L Sub LSP Protection . . . . . . . . . 13 78 5.4.4. PLR Procedures during Local Repair . . . . . . . . . . 13 79 6. Considering Application Traffic . . . . . . . . . . . . . . . 14 80 6.1. A Typical Application . . . . . . . . . . . . . . . . . . 14 81 6.2. PLR Procedure for Applications . . . . . . . . . . . . . . 15 82 6.3. Egress Procedures for Applications . . . . . . . . . . . . 15 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 8.1. Definition of PROTECTION Object Reserved Bits . . . . . . 16 86 8.2. New Subobjects . . . . . . . . . . . . . . . . . . . . . . 16 87 9. Co-authors and Contributors . . . . . . . . . . . . . . . . . 16 88 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 RFC 4090 describes two methods for protecting the transit nodes of a 97 P2P LSP: one-to-one and facility protection. RFC 4875 specifies how 98 to use them to protect the transit nodes of a P2MP LSP. However, 99 they do not mention any local protection for an egress of an LSP. 101 To protect the egresses of an LSP (P2P or P2MP), an existing approach 102 sets up a backup LSP from a backup ingress (or the ingress of the 103 LSP) to the backup egresses, where each egress is paired with a 104 backup egress and protected by the backup egress. 106 This approach uses more resources and provides slow fault recovery. 107 This document specifies extensions to RSVP-TE for local protection of 108 an egress of an LSP, which overcomes these disadvantages. 110 1.1. An Example of Egress Local Protection 112 Figure 1 shows an example of using backup LSPs to locally protect 113 egresses of a primary P2MP LSP from ingress R1 to two egresses: L1 114 and L2. The primary LSP is represented by star(*) lines and backup 115 LSPs by hyphen(-) lines. 117 La and Lb are the designated backup egresses for egresses L1 and L2 118 respectively. To distinguish an egress (e.g., L1) from a backup 119 egress (e.g., La), an egress is called a primary egress if needed. 121 The backup LSP for protecting L1 is from its upstream node R3 to 122 backup egress La. The one for protecting L2 is from R5 to Lb. 124 [R2]*****[R3]*****[L1] 125 * \ :.....: $ **** Primary LSP 126 * \ $ ---- Backup LSP 127 * \ [CE1] .... BFD Session 128 * \ $ $ Link 129 * \ $ $ 130 * ---[La] $ 131 * 132 [R1]******[R4]*******[R5]*****[L2] 133 $ \ :.....: $ 134 $ \ $ 135 [S] \ [CE2] 136 \ $ 137 \ $ 138 ---[Lb] 140 Figure 1: Backup LSP for Locally Protecting Egress 142 During normal operations, the traffic carried by the P2MP LSP is sent 143 through R3 to L1, which delivers the traffic to its destination CE1. 144 When R3 detects the failure of L1, R3 switches the traffic to the 145 backup LSP to backup egress La, which delivers the traffic to CE1. 146 The time for switching the traffic is within tens of milliseconds. 148 The failure of a primary egress (e.g., L1 in the figure) may be 149 detected by its upstream node (e.g., R3 in the figure) through a BFD 150 between the upstream node and the egress in MPLS networks. Exactly 151 how the failure is detected is out of scope for this document. 153 1.2. Egress Local Protection with FRR 155 Using the egress local protection and the FRR, we can locally protect 156 the egresses, the links and the transit nodes of an LSP. The traffic 157 switchover time is within tens of milliseconds whenever an egress, 158 any of the links and the transit nodes of the LSP fails. 160 The egress nodes of the LSP can be locally protected via the egress 161 local protection. All the links and the transit nodes of the LSP can 162 be locally protected through using the FRR. 164 2. Conventions Used in This Document 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119. 170 3. Terminology 172 This document uses terminologies defined in RFC 2205, RFC 3209, RFC 173 4090, RFC 4873 and RFC 4875. 175 4. Protocol Extensions 177 4.1. Extensions to SERO 179 The Secondary Explicit Route object (SERO) is defined in RFC 4873. 180 The format of the SERO is re-used. 182 The SERO used for protecting a primary egress node of a primary LSP 183 may be added into the Path messages for the LSP and sent from the 184 ingress node of the LSP to the upstream node of the egress node. It 185 contains three subobjects. 187 The first subobject indicates the branch node that is to originate 188 the backup LSP (to a backup egress node). The branch node is the 189 direct upstream node of the primary egress node of the primary LSP if 190 it can provide fast local protection for the primary egress node. 191 The branch node can be a (upstream) node on the primary LSP, but not 192 the direct upstream node if the direct upstream node does not provide 193 any fast local protection against the failure of the primary egress 194 node. In this case, the backup LSP from the branch node to the 195 backup egress node protects against failures on the segment of the 196 primary LSP from the branch node to the primary egress node, 197 including the primary egress node. 199 The final (third) subobject in the SERO contains the egress node of 200 the backup LSP, i.e., the address of the backup egress node. 202 The second subobject is a protection subobject defined in RFC 4873, 203 but with some extensions, which include a few of flags for egress 204 local protection and some optional subobjects. These new flags use a 205 few of bits in the existing reserved field. The optional subobjects 206 follow the flags field. The contents of the PROTECTION object is 207 extended in the same way. 209 The format of the extended protection subobject is defined as 210 follows: 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 |L| Type | Length | Reserved | C-Type | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 |S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags| 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 |I|R| Reserved | Seg.Flags | Reserved |E-Flags| 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Optional subobjects | 222 ~ ~ 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 E-Flags are defined for egress local protection. 227 x01 (Egress local protection bit): It is set (1) to indicate an 228 egress local protection. 230 x02 (Other sending UA label bit): It is set (1) to indicate another 231 protocol is desired for sending a label as a UA label from a 232 primary egress to a backup egress. 234 x04 (S2L sub LSP backup desired bit): It is set (1) to indicate S2L 235 Sub LSP (ref to RFC 4875) is desired for protecting an egress of a 236 P2MP LSP. 238 The other flags are not valid and reset to zero when the egress local 239 protection bit is set. 241 Five optional subobjects are defined. They are IPv4 and IPv6 primary 242 egress, IPv4 and IPv6 P2P LSP ID, and Opaque Data subobjects. They 243 have the following format: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length |Reserved (zero)| 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Contents/Body of subobject | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 where Type is the type of a subobject, Length is the total size of 254 the subobject in bytes, including Type, Length and Contents fields. 255 The Reserved field MUST be set to zero. 257 After the upstream node of the primary egress node as the branch node 258 receives the SERO and determines a backup egress node for the primary 259 egress, it computes a path from itself to the backup egress node and 260 sets up a backup LSP along the path for protecting the primary egress 261 node according to the information in the FAST_REROUTE object in the 262 Path message. For example, if facility protection is desired, 263 facility protection is provided for the primary egress node. 265 The upstream node constructs a PROTECTION object based on the 266 protection subobject in the SERO and adds the object into the Path 267 message for the backup LSP. The object contains a subobject called a 268 primary egress subobject, which indicates the address of the primary 269 egress node. 271 The upstream node updates the SERO in the Path message for the 272 primary LSP. The protection subobject in the SERO contains a 273 subobject called a P2P LSP ID subobject, which contains the 274 information for identifying the backup LSP. The final subobject in 275 the SERO indicates the address of the backup egress node. 277 4.1.1. Primary Egress Subobject 279 There are two primary egress subobjects. One is IPv4 primary egress 280 subobject and the other is IPv6 primary egress subobject. 282 The Type of an IPv4 primary egress subobject is 1, and the body of 283 the subobject is given below: 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | IPv4 address (4 bytes) | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 o IPv4 address: IPv4 address of the primary egress node 293 The Type of an IPv6 primary egress subobject is 2, and the body of 294 the subobject is shown below: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | IPv6 address (16 bytes) | 300 ~ ~ 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 o IPv6 address: The IPv6 address of the primary egress node 305 4.1.2. P2P LSP ID Subobject 307 A P2P LSP ID subobject contains the information for identifying a 308 backup point-to-point (P2P) LSP tunnel. 310 4.1.2.1. IPv4 P2P LSP ID Subobject 312 The Type of an IPv4 P2P LSP ID subobject is 3, and the body of the 313 subobject is shown below: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | P2P LSP Tunnel Egress IPv4 Address | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Reserved (MUST be zero) | Tunnel ID | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Extended Tunnel ID | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 o P2P LSP Tunnel Egress IPv4 Address: 326 IPv4 address of the egress of the tunnel 327 o Tunnel ID: 328 A 16-bit identifier being constant over the life of the tunnel 329 o Extended Tunnel ID: 331 A 4-byte identifier being constant over the life of the tunnel 333 4.1.2.2. IPv6 P2P LSP ID Subobject 335 The Type of an IPv6 P2P LSP ID subobject is 4, and the body of the 336 subobject is illustrated below: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 ~ P2P LSP Tunnel Egress IPv6 Address (16 bytes) ~ 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Reserved (MUST be zero) | Tunnel ID | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 ~ Extended Tunnel ID (16 bytes) ~ 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 o P2P LSP Tunnel Egress IPv6 Address: 349 IPv6 address of the egress of the tunnel 350 o Tunnel ID: 351 A 16-bit identifier being constant over the life of the tunnel 352 o Extended Tunnel ID: 353 A 16-byte identifier being constant over the life of the tunnel 355 4.1.3. Opaque Data Subobject 357 A opaque data subobject contains a piece of opaque data. The Type of 358 an opaque data subobject is 5, and the body of the subobject is shown 359 below: 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Opaque Data | 365 ~ ~ 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 This subobject may be used by a primary egress node (e.g., L1) to 369 send its corresponding backup egress node (e.g., La) the information 370 about forwarding the traffic to a receiver (e.g., CE1) through its 371 upstream node (e.g., R3). It may contain a label as a UA label and a 372 receiver such as CE1. The exact format and meanings of the opaque 373 data are out of scope for this document. 375 5. Egress Protection Behaviors 376 5.1. Ingress Behavior 378 To protect a primary egress of an LSP, the ingress MUST set the 379 "label recording desired" flag and the "node protection desired" flag 380 in the SESSION_ATTRIBUTE object. 382 If one-to-one backup or facility backup is desired to protect a 383 primary egress of an LSP, the ingress MUST include a FAST_REROUTE 384 object and set the "One-to-One Backup Desired" or "Facility Backup 385 Desired" flag respectively. 387 If S2L Sub LSP backup is desired to protect a primary egress of a 388 P2MP LSP, the ingress MUST set the "S2L Sub LSP Backup Desired" flag 389 in an SERO object. 391 If another protocol is desired for sending a label as a upstream 392 assigned label to a backup egress, the ingress MUST set the "Other 393 Sending UA Label" flag. 395 A backup egress MUST be configured on the ingress of an LSP to 396 protect a primary egress of the LSP if and only if the backup egress 397 is not indicated in another place. 399 The ingress MUST send a Path message for the LSP with the objects 400 above and the SEROs for protecting egresses of the LSP. For each 401 primary egress of the LSP to be protected, the ingress MUST add an 402 SERO object into the Path message if the backup egress or some 403 options are given. If the backup egress is given, then the final 404 subobject in the SERO containts it; otherwise the address in the 405 final subobject is zero. 407 5.2. Primary Egress Behavior 409 To protect a primary egress of an LSP, a backup egress MUST be 410 configured on the primary egress of the LSP to protect the primary 411 egress if and only if the backup egress is not indicated in another 412 place. 414 If the backup egress is configured on the primary egress of the LSP, 415 the primary egress MUST send its upstream node a Resv message for the 416 LSP with an SERO for protecting the primary egress. It sets the 417 flags in the SERO in the same way as an ingress. 419 If the LSP carries the service traffic with a service label, the 420 primary egress sends its corresponding backup egress the information 421 about the service label as a UA label and the related forwarding. 423 5.3. Backup Egress Behavior 425 When a backup egress node receives a Path message for an LSP, it 426 determines whether the LSP is used for egress local protection 427 through checking the PROTECTION object in the message. If there is a 428 PROTECTION object in the Path message for the LSP and the Egress 429 local protection flag in the object is set to one, the LSP is the 430 backup LSP for egress local protection. The primary egress to be 431 protected is in the primary egress subobject in the PROTECTION 432 object. 434 When the backup egress receives the information about a UA label and 435 its related forwarding from the primary egress, it uses the backup 436 LSP label as a context label and creates a forwarding entry using the 437 information about the UA label and the related forwarding. This 438 forwarding entry is in a forwarding table for the primary egress 439 node. 441 When the primary egress node fails, its upstream node switches the 442 traffic from the primary LSP to the backup LSP to the backup egress 443 node, which delivers the traffic to its receiver such as CE using the 444 backup LSP label as a context label to get the forwarding table for 445 the primary egress node and the service label as UA label to find the 446 forwarding entry in the table to forward the traffic to the receiver. 448 5.4. Transit Node and PLR Behavior 450 If a transit node of an LSP receives the Path message with the SEROs 451 and it is not an upstream node of any primary egress of the LSP as a 452 branch node, it MUST forward them unchanged. 454 If the transit node is the upstream node of a primary egress to be 455 protected as a branch node, it determines the backup egress, obtains 456 a path for the backup LSP and sets up the backup LSP along the path. 457 If the upstream node receives the Resv message with an SERO object, 458 it MUST sends its upstream node the Resv message without the object. 460 The PLR (upstream node of the primary egress as the branch node) MUST 461 extract the backup egress from the respective SERO object in either a 462 Path or a Resv message. If no matching SERO object is found, the PLR 463 tries to find the backup egress, which is not the primary egress but 464 has the same IP address as the destination IP address of the LSP. 466 Note that if a backup egress is not configured explicitly for 467 protecting a primary egress, the primary egress and the backup egress 468 SHOULD have a same local address configured, and the cost to the 469 local address on the backup egress SHOULD be much bigger than the 470 cost to the local address on the primary egress. Thus primary egress 471 and backup egress is considered as a virtual node. Note that the 472 backup egress is different from this local address (e.g., from the 473 primary egress' view). In other words, it is identified by an 474 address different from this local address. 476 After obtaining the backup egress, the PLR computes a backup path 477 from itself to the backup egress and sets up a backup LSP along the 478 path. It excludes the segment including the primary egress to be 479 protected when computing the path. The PLR sends the primary egress 480 a Path message with an SERO for the primary LSP, which indicates the 481 backup egress by the final subobject in the SERO. The PLR puts a 482 PROTECTION object into the Path messages for the backup LSP. The 483 object indicates the primary egress. 485 The PLR MUST provide one-to-one backup protection for the primary 486 egress if the "One-to-One Backup Desired" flag is set in the message; 487 otherwise, it MUST provide facility backup protection if the 488 "Facility Backup Desired flag" is set. 490 The PLR MUST set the protection flags in the RRO Sub-object for the 491 primary egress in the Resv message according to the status of the 492 primary egress and the backup LSP protecting the primary egress. For 493 example, it sets the "local protection available" and the "node 494 protection" flag indicating that the primary egress is protected when 495 the backup LSP is up and ready for protecting the primary egress. 497 5.4.1. Signaling for One-to-One Protection 499 The behavior of the upstream node of a primary egress of an LSP as a 500 PLR is the same as that of a PLR for one-to-one backup described in 501 RFC 4090 except for that the upstream node as a PLR creates a backup 502 LSP from itself to a backup egress in a session different from the 503 primary LSP. 505 If the LSP is a P2MP LSP and a primary egress of the LSP is also a 506 transit node (i.e., bud node), the upstream node of the primary 507 egress as a PLR creates a backup LSP from itself to each of the next 508 hops of the primary egress. 510 When the PLR detects the failure of the primary egress, it switches 511 the packets from the primary LSP to the backup LSP to the backup 512 egress. For the failure of the bud node of a P2MP LSP, the PLR also 513 switches the packets to the backup LSPs to the bud node's next hops, 514 where the packets are merged into the primary LSP. 516 5.4.2. Signaling for Facility Protection 518 Except for backup LSP and downstream label, the behavior of the 519 upstream node of the primary egress of a primary LSP as a PLR follows 520 the PLR behavior for facility backup described in RFC 4090. 522 For a number of primary P2P LSPs going through the same PLR to the 523 same primary egress, the primary egress of these LSPs MAY be 524 protected by one backup LSP from the PLR to the backup egress 525 designated for protecting the primary egress. 527 The PLR selects or creates a backup LSP from itself to the backup 528 egress. If there is a backup LSP that satisfies the constraints 529 given in the Path message, then this one is selected; otherwise, a 530 new backup LSP to the backup egress is created. 532 After getting the backup LSP, the PLR associates the backup LSP with 533 a primary LSP for protecting its primary egress. The PLR records 534 that the backup LSP is used to protect the primary LSP against its 535 primary egress failure and MUST include an SERO object in the Path 536 message for the primary LSP. The object MUST contain the backup LSP 537 ID. It indicates that the primary egress MUST send the backup egress 538 the service label as UA label and the information about forwarding 539 the traffic to its destination using the label if there is a service 540 carried by the LSP and the primary LSP label as UA label if the label 541 is not implicit null. 543 A UA label MAY be sent via another protocol (e.g., BGP). If "Other 544 Sending UA Label" flag is one, the primary egress MUST send the 545 backup egress the UA labels and the information about forwarding the 546 traffic to its destination using the labels through another protocol. 548 After receiving the Path message with the protection subobject in an 549 SERO, the primary egress MUST include the information about the UA 550 labels in the Resv message with an SERO having a protection subobject 551 containing an opaque data subobject if "Other Sending UA Label" flag 552 is zero. When the PLR receives the Resv message with the information 553 about the UA labels, it MUST include the information in the Path 554 message with a PROTECTION object containing the opaque data subobject 555 for the backup LSP to the backup egress. Thus the UA labels are sent 556 to the backup egress from the primary egress via RSVP. 558 When the PLR detects the failure of the primary egress, it redirects 559 the packets from the primary LSP into the backup LSP to backup egress 560 and keeps the primary LSP label from the primary egress in the label 561 stack if the label is not implicit null. The backup egress delivers 562 the packets to the same destinations as the primary egress using the 563 backup LSP label as context label and the labels under as UA labels. 565 5.4.3. Signaling for S2L Sub LSP Protection 567 The S2L Sub LSP Protection uses a S2L Sub LSP (ref to RFC 4875) as a 568 backup LSP to protect a primary egress of a P2MP LSP. The PLR MUST 569 determine to protect a primary egress of a P2MP LSP via S2L sub LSP 570 protection when it receives a Path message with flag "S2L Sub LSP 571 Backup Desired" set. 573 The PLR MUST set up the backup S2L sub LSP to the backup egress, 574 create and maintain its state in the same way as of setting up a 575 source to leaf (S2L) sub LSP defined in RFC 4875 from the signaling's 576 point of view. It computes a path for the backup LSP from itself to 577 the backup egress, constructs and sends a Path message along the 578 path, receives and processes a Resv message responding to the Path 579 message. 581 After receiving the Resv message for the backup LSP, the PLR creates 582 a forwarding entry with an inactive state or flag called inactive 583 forwarding entry. This inactive forwarding entry is not used to 584 forward any data traffic during normal operations. 586 When the PLR detects the failure of the primary egress, it changes 587 the forwarding entry for the backup LSP to active. Thus, the PLR 588 forwards the traffic to the backup egress through the backup LSP, 589 which sends the traffic to its destination. 591 5.4.4. PLR Procedures during Local Repair 593 When the upstream node of a primary egress of an LSP as a PLR detects 594 the failure of the primary egress, it follows the procedures defined 595 in section 6.5 of RFC 4090. It SHOULD notify the ingress about the 596 failure of the primary egress in the same way as a PLR notifies the 597 ingress about the failure of a transit node. 599 Moreover, the PLR MUST let the upstream part of the primary LSP stay 600 after the primary egress fails through sending Resv message to its 601 upstream node along the primary LSP. The downstream part of the 602 primary LSP from the PLR to the primary egress SHOULD be removed. 603 When a bypass LSP from the PLR to a backup egress protects the 604 primary egress, the PLR MUST NOT send any Path message for the 605 primary LSP through the bypass LSP to the backup egress. 607 In the local revertive mode, the PLR will re-signal each of the 608 primary LSPs that were routed over the restored resource once it 609 detects that the resource is restored. Every primary LSP 610 successfully re-signaled along the restored resource will be switched 611 back. 613 6. Considering Application Traffic 615 This section focuses on the application traffic carried by P2P LSPs. 616 When a primary egress of a P2MP LSP fails, the application traffic 617 carried by the P2MP LSP is delivered to the same destination by the 618 backup egress since the inner label if any for the traffic is a 619 upstream assigned label for every egress of the P2MP LSP. 621 6.1. A Typical Application 623 L3VPN is a typical application. An existing solution (refer to 624 Figure 2) for protecting L3VPN traffic against egress failure 625 includes: 1) A multi-hop BFD session between ingress R1 and egress L1 626 of primary LSP; 2) A backup LSP from ingress R1 to backup egress La; 627 3) La sends R1 VPN backup label and related information via BGP; 4) 628 R1 has a VRF with two sets of routes: one uses primary LSP and L1 as 629 next hop; the other uses backup LSP and La as next hop. 631 CE1,CE2 in [R2]*****[R3]*****[L1] **** Primary LSP 632 one VPN * : $ ---- Backup LSP 633 * .................: $ .... BFD Session 634 [R1] ..: [CE2] $ Link 635 $ \ $ $ 636 $ \ $ 637 [CE1] [R4]-----[R5]-----[La](BGP sends R1 VPN backup label) 639 Figure 2: Protect Egress for L3VPN Traffic 641 In normal operations, R1 sends the traffic from CE1 through primary 642 LSP with VPN label received from L1 as inner label to L1, which 643 delivers the traffic to CE2 using VPN label. 645 When R1 detects the failure of L1, R1 sends the traffic from CE1 via 646 backup LSP with VPN backup label received from La as inner label to 647 La, which delivers the traffic to CE2 using VPN backup label. 649 A new solution (refer to Figure 3) with egress local protection for 650 protecting L3VPN traffic includes: 1) A BFD session between R3 and 651 egress L1 of primary LSP; 2) A backup LSP from R3 to backup egress 652 La; 3) L1 sends La VPN label as UA label and related information; 4) 653 L1 and La is virtualized as one. This can be achieved by configuring 654 a same local address on L1 and La, using the address as a destination 655 of the LSP and BGP next hop for VPN traffic. 657 CE1,CE2 in [R2]*****[R3]*****[L1] **** Primary LSP 658 one VPN * \ :.....: $ ---- Backup LSP 659 * \ $ .... BFD Session 660 [R1] \ [CE2] $ Link 661 $ \ $ $ 662 $ \ $ 663 [CE1] [La](VPN label from L1 as UA label) 665 Figure 3: Locally Protect Egress for L3VPN Traffic 667 When R3 detects L1's failure, R3 sends the traffic from primary LSP 668 via backup LSP to La, which delivers the traffic to CE2 using VPN 669 label as UA label under the backup LSP label as a context label. 671 6.2. PLR Procedure for Applications 673 When the PLR gets a backup LSP from itself to a backup egress for 674 protecting a primary egress of a primary LSP, it includes an SERO 675 object in the Path message for the primary LSP. The object contains 676 the ID information of the backup LSP and indicates that the primary 677 egress sends the backup egress the application traffic label (e.g., 678 VPN label) as UA label when needed. 680 6.3. Egress Procedures for Applications 682 When a primary egress of an LSP sends the ingress of the LSP a label 683 for an application such as a VPN, it sends the backup egress for 684 protecting the primary egress the label as a UA label. Exactly how 685 the label is sent is out of scope for this document. 687 When the backup egress receives a UA label from the primary egress, 688 it adds a forwarding entry with the label into the LFIB for the 689 primary egress. When the backup egress receives a packet from the 690 backup LSP, it uses the top label as a context label to find the LFIB 691 for the primary egress and the inner label to deliver the packet to 692 the same destination as the primary egress according to the LFIB. 694 7. Security Considerations 696 In principle this document does not introduce new security issues. 697 The security considerations pertaining to RFC 4090, RFC 4875 and 698 other RSVP protocols remain relevant. 700 Note that protecting a primary egress of a P2P LSP carrying service 701 traffic through a backup egress requires that the backup egress trust 702 the primary egress for the information received for a service label 703 as UA label. 705 8. IANA Considerations 707 IANA is requested to administer the assignment of the new subobject 708 types defined under the PROTECTION object in this document and 709 summarized in this section. 711 8.1. Definition of PROTECTION Object Reserved Bits 713 This document defines bits carried in the Reserved field of the 714 PROTECTION object defined in RFC 4873. As no IANA registry for these 715 bits is requested in RFC 4873, no IANA action is required related to 716 this definition. 718 8.2. New Subobjects 720 IANA maintains a registry called "Class Names, Class Numbers, and 721 Class Types" under "Resource Reservation Protocol-Traffic Engineering 722 (RSVP-TE) Parameters". IANA is to create and maintain a new registry 723 under PROTECTION object class, Class Number 37, C-Type 2: 725 o Sub-object type - 37 PROTECTION, C-Type 2 727 Initial values for the registry are given below. The future 728 assignments are to be made through IETF Review. 730 Value Name Definition 731 1 IPv4_PRIMARY_EGRESS Section 4.1.1 732 2 IPv6_PRIMARY_EGRESS Section 4.1.1 733 3 IPv4_P2P_LSP_ID Section 4.1.2 734 4 IPv6_P2P_LSP_ID Section 4.1.2 735 5 OPAQUE_DATA Section 4.1.3 737 9. Co-authors and Contributors 739 1. Co-authors 741 Mehmet Toy 742 Verizon 743 E-mail: mehmet.toy@verizon.com 744 Lei Liu 745 Fujitsu 746 E-mail: lliu@us.fujitsu.com 748 Zhenbin Li 749 Huawei Technologies 750 Email: lizhenbin@huawei.com 752 2. Contributors 754 Boris Zhang 755 Telus Communications 756 Email: Boris.Zhang@telus.com 758 Nan Meng 759 Huawei Technologies 760 Email: mengnan@huawei.com 762 Prejeeth Kaladharan 763 Huawei Technologies 764 Email: prejeeth@gmail.com 766 Vic Liu 767 China Mobile 768 Email: liu.cmri@gmail.com 770 10. Acknowledgement 772 The authors would like to thank Richard Li, Nobo Akiya, Lou Berger, 773 Jeffrey Zhang, Lizhong Jin, Ravi Torvi, Eric Gray, Olufemi Komolafe, 774 Michael Yue, Daniel King, Rob Rennison, Neil Harrison, Kannan 775 Sampath, Yimin Shen, Ronhazli Adam and Quintin Zhao for their 776 valuable comments and suggestions on this draft. 778 11. References 780 11.1. Normative References 782 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 783 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 784 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 785 . 787 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 788 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 789 DOI 10.17487/RFC4090, May 2005, 790 . 792 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 793 Yasukawa, Ed., "Extensions to Resource Reservation 794 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 795 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 796 DOI 10.17487/RFC4875, May 2007, 797 . 799 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 800 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 801 May 2007, . 803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 804 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 805 RFC2119, March 1997, 806 . 808 11.2. Informative References 810 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 811 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 812 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 813 September 1997, . 815 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 816 Label Assignment and Context-Specific Label Space", 817 RFC 5331, DOI 10.17487/RFC5331, August 2008, 818 . 820 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 821 Ed., "RSVP-TE Extensions in Support of End-to-End 822 Generalized Multi-Protocol Label Switching (GMPLS) 823 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 824 . 826 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 827 Switching (GMPLS) Signaling Resource ReserVation Protocol- 828 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 829 DOI 10.17487/RFC3473, January 2003, 830 . 832 [FRAMEWK] Shen, Y., Jeyananth, M., Decraene, B., and H. Gredler, 833 "MPLS Egress Protection Framework", 834 draft-shen-mpls-egress-protection-framework , 835 October 2016. 837 Authors' Addresses 839 Huaimo Chen 840 Huawei Technologies 841 Boston, MA 842 USA 844 Email: huaimo.chen@huawei.com 846 Autumn Liu 847 Ciena 848 USA 850 Email: hliu@ciena.com 852 Tarek Saad 853 Cisco Systems 855 Email: tsaad@cisco.com 857 Fengman Xu 858 Verizon 859 2400 N. Glenville Dr 860 Richardson, TX 75082 861 USA 863 Email: fengman.xu@verizon.com 865 Lu Huang 866 China Mobile 867 No.32 Xuanwumen West Street, Xicheng District 868 Beijing, 100053 869 China 871 Email: huanglu@chinamobile.com 872 Ning So 873 Tata Communications 874 2613 Fairbourne Cir. 875 Plano, TX 75082 876 USA 878 Email: ningso01@gmail.com