idnits 2.17.1 draft-ietf-pals-endpoint-fast-protection-03.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 (June 28, 2016) is 2859 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) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Yimin Shen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track Rahul Aggarwal 5 Expires: December 30, 2016 Arktan, Inc 6 Wim Henderickx 7 Alcatel-Lucent 8 Yuanlong Jiang 9 Huawei Technologies 10 June 28, 2016 12 PW Endpoint Fast Failure Protection 13 draft-ietf-pals-endpoint-fast-protection-03 15 Abstract 17 This document specifies a fast mechanism for protecting pseudowires 18 against egress endpoint failures, including egress attachment circuit 19 failure, egress PE failure, multi-segment PW terminating PE failure, 20 and multi-segment PW switching PE failure. Operating on the basis of 21 multi-homed CE, redundant PWs, upstream label assignment and context 22 specific label switching, the mechanism enables local repair to be 23 performed by the router upstream adjacent to a failure. The router 24 can restore a PW in the order of tens of milliseconds, by rerouting 25 traffic around the failure to a protector through a pre-established 26 bypass tunnel. Therefore, the mechanism can be used to reduce 27 traffic loss before global repair reacts to the failure and the 28 network converges on the topology changes due to the failure. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 30, 2016. 47 Copyright Notice 49 Copyright (c) 2016 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 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 66 3. Reference Models for Egress Endpoint Failures . . . . . . . . 4 67 3.1. Single-Segment PW . . . . . . . . . . . . . . . . . . . . 4 68 3.2. Multi-Segment PW . . . . . . . . . . . . . . . . . . . . 7 69 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 9 71 4.2. Local Repair and Protector . . . . . . . . . . . . . . . 9 72 4.3. Context Identifier . . . . . . . . . . . . . . . . . . . 12 73 4.3.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 12 74 4.3.2. IGP Advertisement and Path Computation . . . . . . . 13 75 4.4. Protection Models . . . . . . . . . . . . . . . . . . . . 14 76 4.4.1. Co-located Protector . . . . . . . . . . . . . . . . 15 77 4.4.2. Centralized Protector . . . . . . . . . . . . . . . . 16 78 4.5. Transport Tunnel . . . . . . . . . . . . . . . . . . . . 18 79 4.6. Bypass Tunnel . . . . . . . . . . . . . . . . . . . . . . 19 80 4.7. Examples of Forwarding State . . . . . . . . . . . . . . 20 81 4.7.1. Co-located Protector Model . . . . . . . . . . . . . 20 82 4.7.2. Centralized Protector Model . . . . . . . . . . . . . 23 83 5. Revertive Behavior . . . . . . . . . . . . . . . . . . . . . 26 84 6. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 27 85 6.1. Egress Protection Capability TLV . . . . . . . . . . . . 28 86 6.2. PW Label Distribution from Primary PE to Protector . . . 29 87 6.3. PW Label Distribution from Backup PE to Protector . . . . 30 88 6.4. Protection FEC Element TLV . . . . . . . . . . . . . . . 30 89 6.4.1. Encoding Format for PWid . . . . . . . . . . . . . . 31 90 6.4.2. Encoding Format for Generalized PWid . . . . . . . . 32 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 96 10.2. Informative References . . . . . . . . . . . . . . . . . 35 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 99 1. Introduction 101 Per [RFC3985, RFC4447, RFC5659], a pseudowire (PW) or PW segment can 102 be thought of as a connection between a pair of forwarders hosted by 103 two PEs, carrying an emulated layer-2 service over a packet switched 104 network (PSN). In the single-segment PW (SS-PW) case, a forwarder 105 binds a PW to an attachment circuit (AC). In the multi-segment PW 106 (MS-PW) case, a forwarder on a terminating PE (T-PE) binds a PW 107 segment to an AC, while a forwarder on a switching PE (S-PE) binds 108 one PW segment to another PW segment. In each direction between the 109 PEs, PW packets are transported by a PSN tunnel, which is also called 110 a transport tunnel. 112 In order to protect the PW service against network failures, it is 113 necessary to protect every link and node along the entire data path. 114 For the traffic in a given direction, this include ingress AC, 115 ingress (T-)PE, intermediate routers of transport tunnel, S-PEs, 116 egress (T-)PE, and egress AC. To minimize service disruption upon a 117 failure, it is also desirable that each of these components is 118 protected by a fast protection mechanism based on local repair. Such 119 mechanism generally involves a bypass path that is pre-computed and 120 pre-installed in the data plane on the router upstream adjacent to an 121 anticipated failure. This router is referred to as a "point of local 122 repair" (PLR). The bypass path has the property that it can guide 123 traffic around the failure, while remaining unaffected by the 124 topology changes resulting from the failure. When the failure 125 occurs, the PLR can invoke the bypass path to achieve fast 126 restoration for the service. 128 Today, fast protection against ingress AC failure and ingress (T-)PE 129 failure can be achieved by using a multi-homed CE and redundant ACs, 130 such as multi-chassis link aggregation group (MC-LAG). Fast 131 protection against the failure of an intermediate router of transport 132 tunnel can be achieved through RSVP fast-reroute [RFC4090] or IP/LDP 133 fast-reroute [RFC5714, RFC5286]. However, there is no equivalent 134 mechanism that can be used against an egress AC failure, an egress 135 (T-)PE failure, or an S-PE failure. For these failures, service 136 restoration has to rely on global repair or control plane repair. 137 Global repair normally involves the ingress CE or the ingress (T-)PE 138 switching traffic to an alternative path, based on remote failure 139 detection via PW status notification, end-to-end OAM, etc. Control 140 plane repair relies on control protocols to converge on the topology 141 changes due to a failure. Compared to local repair, these mechanisms 142 are relatively slow in reacting to a failure and restoring traffic. 144 This document is intended to serve the above need. It specifies a 145 fast protection mechanism based on local repair to protect PWs 146 against the following endpoint failures. 148 a. Egress AC failure. 150 b. Egress PE failure: Link or node failure of an egress PE of an SS- 151 PW, or a T-PE of an MS-PW. 153 c. Switching PE (S-PE) failure: Link or node failure of an S-PE of 154 an MS-PW. 156 The mechanism is applicable to LDP signaled PWs. It is relevant to 157 networks with redundant PWs and multi-homed CEs. It is designed on 158 the basis of MPLS upstream label assignment and context-specific 159 label switching [RFC5331]. Fast protection refers to its ability to 160 restore traffic in the order of tens of milliseconds. Compared with 161 global repair and control plane repair, this mechanism can provide 162 faster service restoration. However, it is intended to complement 163 those mechanisms, rather than replacing them. 165 2. Specification of Requirements 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC2119. 171 3. Reference Models for Egress Endpoint Failures 173 This document refers to the following topologies to describe egress 174 endpoint failures and protection procedures. 176 3.1. Single-Segment PW 178 |<-------------- PW1 --------------->| 180 - PE1 -------------- P1 ---------------- PE2 - 181 / \ 182 / \ 183 CE1 CE2 184 \ / 185 \ / 186 - PE3 -------------- P2 ---------------- PE4 - 188 |<-------------- PW2 --------------->| 190 Figure 1 192 In Figure 1, the IP/MPLS network consists of PE and P routers. It 193 provides a PW service between CE1 and CE2. Each CE is multi-homed 194 via two ACs to two PEs. This forms two divergent paths between the 195 CEs. The first path uses PW1 between PE1 and PE2, and the second 196 path uses PW2 between PE3 and PE4. The transport tunnels of the PWs 197 and other links between the routers are not shown in this figure for 198 clarity. 200 In general, a CE may operate the ACs in two modes when sending 201 traffic to the remote CE, i.e. active-standby mode and active-active 202 mode. 204 o In the active-standby mode, the CE chooses one AC as active AC and 205 the corresponding path as active path, and uses the other AC as 206 standby AC and the corresponding path as standby path. The CE 207 only sends traffic on the active AC as long as the active path is 208 operational. The CE will only send traffic on the standby AC 209 after it detects a failure of the active path. Note that the CE 210 may receive traffic on the active or standby AC, depending on 211 whether the remote CE chooses the same active path for the traffic 212 of the reverse direction. In this document, even if both CEs 213 choose the same active path, each CE should still anticipate 214 receiving traffic on a standby AC, because the traffic may be 215 redirected to the standby path by the fast protection mechanism. 217 o In the active-active mode, the CE treats both ACs and their 218 corresponding paths as active, and sends traffic on both ACs in a 219 load balance fashion. In the reverse direction, the CE may 220 receive traffic on both ACs. 222 For either mode, when considering the traffic flowing in a given 223 direction over an active path, this document views the ACs, PEs and 224 PWs to serve primary or backup roles. In particular, the ACs, PEs 225 and PW along this active path are primary, while those along the 226 other path are backup. Note that in the active-active mode, the 227 backup path is an active path by itself, carrying its own share of 228 traffic while protecting the other active path. 230 For Figure 1, the following roles are assumed for the traffic going 231 from CE1 to CE2 via PW1. 233 Primary ingress AC: CE1-PE1 235 Primary ingress PE: PE1 237 Primary PW: PW1 239 Primary egress PE: PE2 240 Primary egress AC: PE2-CE2 242 Backup ingress AC: CE1-PE3 244 Backup ingress PE: PE3 246 Backup PW: PW2 248 Backup egress PE: PE4 250 Backup egress AC: PE4-CE2 252 Based on this schema, this document describes egress endpoint 253 failures and the fast protection mechanism on the per-active-path and 254 per-direction basis. In this case, an egress AC failure refers to 255 the failure of the AC PE2-CE2, and an egress node failure refers to 256 the failure of PE2. The ultimate goal is that when a failure occurs, 257 the traffic should be locally repaired, so that it can eventually 258 reach CE2 via the backup egress PE (PE4) and the backup egress AC 259 (PE4-CE2). 261 Subsequent to the local repair, either the current active path should 262 heal after control plane converges on the new topology, or the 263 ingress CE should switch traffic from the primary path to the backup 264 path, depending on the failure scenario. In the latter case, the 265 ingress CE may perform the path switchover triggered by end-to-end 266 OAM (in-band or out-band), PW status notification, CE-PE control 267 protocols (e.g. LACP), etc. In the active-standby mode, this will 268 promote the standby path to new active path. In the active-active 269 mode, it will make the other active path carry all the traffic 270 between the two CEs. In any case, this phase of restoration falls 271 into the control plane repair and global repair category, and hence 272 is out of the scope of this document. The purpose of the fast 273 protection mechanism in this document is to reduce traffic loss 274 before this phase of restoration takes place. 276 Note that in Figure 1, if the traffic in the reverse direction (i.e. 277 from CE2 to CE1) traverses the AC CE2-PE2 and PE2 as active path, the 278 failure of PE2 and the failure of the AC PE2-CE2 will be considered 279 as ingress failures of the traffic. If CE2 can detect the failures, 280 it may protect the traffic by switching it to the backup path via the 281 AC CE2-PE4 and PE4. However, this is categorized as ingress endpoint 282 failure protection, and hence is not handled by the mechanism 283 described in this document. 285 Figure 2 shows another possible scenario, where CE1 is single-homed 286 to PE1, while CE2 remains multi-homed to PE2 and PE4. From the 287 perspective of egress endpoint protection for the traffic going from 288 CE1 to CE2 over PW1, this scenario is the same as the scenario shown 289 in Figure 1. 291 |<-------------- PW1 --------------->| 293 ------------- P1 ---------------- PE2 - 294 / \ 295 / \ 296 CE1 -- PE1 CE2 297 \ / 298 \ / 299 ------------- P2 ---------------- PE4 - 301 |<-------------- PW2 --------------->| 303 Figure 2 305 For clarity, primary egress AC, primary egress PE, backup egress AC, 306 and backup egress PE may simply be referred to as primary AC, primary 307 PE, backup AC, and backup PE, respectively, when the context of a 308 discussion is egress endpoint. 310 3.2. Multi-Segment PW 312 |<--------------- PW1 --------------->| 313 |<----- SEG1 ----->|<----- SEG2 ----->| 315 - TPE1 -------------- SPE1 --------------- TPE2 - 316 / \ 317 / \ 318 CE1 CE2 319 \ / 320 \ / 321 - TPE3 -------------- SPE2 --------------- TPE4 - 323 |<----- SEG3 ----->|<----- SEG4 ----->| 324 |<--------------- PW2 --------------->| 326 Figure 3 328 Figure 3 shows a topology that is similar to Figure 1 but in an MS-PW 329 environment. PW1 and PW2 are both MS-PWs. PW1 is established 330 between TPE1 and TPE2, and switched between segments SEG1 and SEG2 at 331 SPE1. PW2 is established between TPE3 and TPE4, and switched between 332 segments SEG3 and SEG4 at SPE2. CE1 is multi-homed to TPE1 and TPE3. 333 CE2 is multi-homed to TPE2 and TPE4. The transport tunnels of the PW 334 segments are not shown in this figure for clarity. 336 In this document, the following primary and backup roles are assigned 337 for the traffic going from CE1 to CE2: 339 Primary ingress AC: CE1-TPE1 341 Primary ingress T-PE: TPE1 343 Primary PW: PW1 345 Primary S-PE: SPE1 347 Primary egress T-PE: TPE2 349 Primary egress AC: TPE2-CE2 351 Backup ingress AC: CE1-TPE3 353 Backup ingress T-PE: TPE3 355 Backup PW: PW2 357 Backup S-PE: SPE2 359 Backup egress T-PE: TPE4 361 Backup egress AC: TPE4-CE2 363 In this case, an egress AC failure refers to the failure of the AC 364 TPE2-CE2. An egress node failure refers to the failure of TPE2. An 365 S-PE failure refers to the failure of SPE1. 367 For consistency with the SS-PW scenario, primary T-PEs and a primary 368 S-PEs may simply be referred to as primary PEs in this document, 369 where specifics are not required. Similarly, backup T-PEs and backup 370 S-PEs may be referred to as backup PEs. 372 4. Theory of Operation 374 The fast protection mechanism in this document provides three types 375 of protection for PWs, corresponding to the three types of failures 376 described in Section 1. 378 a. Egress AC protection 380 b. Egress (T-)PE node protection 382 c. S-PE node protection 384 4.1. Applicability 386 The mechanism is applicable to LDP signaled PWs in an environment 387 where an egress CE is multi-homed to a primary PE and a backup PE and 388 there exists a backup PW, as described in Section 3. The procedure 389 for S-PE node protection is applicable when there exists a backup 390 S-PE on the backup PW. 392 The mechanism assumes IP/MPLS transport tunnels. In a network where 393 transport tunnels may provide ECMP to primary PEs, care should be 394 taken to prevent misordered packet delivery during local repair. 395 Imagine a scenario where the transport tunnel of a PW traverses a 396 router with ECMP to a primary PE, and the ECMP include a direct link 397 to the primary PE. Normally the router will attempt to forward PW 398 packets in a load balance fashion over the ECMP, including this link. 399 In this document, when the link fails, the router will treat the 400 event as an egress PE failure, and reroute the portion of traffic on 401 the link towards a backup PE. Meanwhile, the rest of the traffic 402 will remain on the other ECMP branches to the primary PE. This will 403 create a situation where the egress CE receives traffic from both the 404 primary PE and the backup PE, which is undesirable if the PW or the 405 flows within the PW are sensitive to packet misordering. Therefore, 406 it is RECOMMENDED that Control Word (CW) SHOULD be used for PWs and 407 flow labels [RFC6391] SHOULD be used for flows within a PW, whenever 408 applicable. The goal is to ensure that the PW or a given flow SHOULD 409 be forwarded entirely over the link in steady state, and hence be 410 rerouted via the same path during local repair. 412 It is also RECOMMENDED that the mechanism SHOULD be used in 413 conjunction with global repair and control plane repair, in such a 414 manner that the mechanism temporarily repairs a failed path by using 415 a bypass tunnel, and global repair and control plane repair 416 eventually move traffic to a fully functional alternative path. 418 4.2. Local Repair and Protector 420 The fast protection ability of the mechanism comes from local repair 421 performed by routers upstream adjacent to failures. Each of these 422 routers is referred to as a "point of local repair" (PLR). A PLR 423 MUST be able to detect a failure by using a rapid mechanism, such as 424 physical layer failure detection, Bidirectional Failure Detection 425 (BFD) [RFC5880], etc. In anticipation of the failure, the PLR MUST 426 also pre-establish a bypass tunnel to a "protector", and pre-install 427 a bypass route in the data plane. The bypass tunnel MUST have the 428 property that it will not be affected by the topology changes due to 429 the failure. Specifically, it MUST NOT traverse the primary PE or 430 the penultimate link of the protected transport tunnel, or share any 431 SRLG (shared risk link groups) with the penultimate link. Upon 432 detecting the failure, the PLR invokes the bypass route in the data 433 plane, and reroutes PW traffic to the protector through the bypass 434 tunnel. The protector in turn sends the traffic to the target CE. 435 This procedure is referred to as local repair. 437 Different routers may serve as PLR and protector in different 438 scenarios. 440 o In egress AC protection, the PLR is the primary PE, and the 441 protector is the backup PE (Figure 4). 443 |<-------------- PW1 --------------->| 445 - PE1 -------------- P1 ---------------- PE2 - 446 / PLR \ 447 / | \ 448 CE1 bypass| CE2 449 \ | / 450 \ | / 451 - PE3 -------------- P2 ---------------- PE4 - 452 protector 454 |<-------------- PW2 --------------->| 456 Figure 4 458 o In egress PE node protection, the PLR is the penultimate hop 459 router of the transport tunnel of the primary PW, and the 460 protector is the backup PE (Figure 5). 462 |<-------------- PW1 --------------->| 464 - PE1 -------------- P1 ------- P3 ----- PE2 - 465 / PLR \ \ 466 / \ \ 467 CE1 bypass\ CE2 468 \ \ / 469 \ \ / 470 - PE3 -------------- P2 ---------------- PE4 - 471 protector 473 |<-------------- PW2 --------------->| 475 Figure 5 477 o In S-PE node protection, the PLR is the penultimate hop router of 478 the transport tunnel of the primary PW segment, and the protector 479 is the backup S-PE (Figure 6). 481 |<--------------- PW1 --------------->| 482 |<----- SEG1 ----->|<----- SEG2 ----->| 484 - TPE1 ----- P1 ----- SPE1 -------------- TPE2 - 485 / PLR \ \ 486 / \ \ 487 CE1 bypass\ CE2 488 \ \ / 489 \ \ / 490 - TPE3 --------------- SPE2 -------------- TPE4 - 491 protector 493 |<----- SEG3 ----->|<----- SEG4 ----->| 494 |<--------------- PW2 --------------->| 496 Figure 6 498 In egress AC protection, a PLR realizes its role based on 499 configuration of a "context identifier" introduced in this document 500 (Section 4.3). The PLR establishes a bypass tunnel to the protector 501 in the same fashion as a normal PSN tunnel. 503 In egress PE and S-PE node protection, a PLR is a transit router on 504 the transport tunnel, and it normally does not have knowledge of the 505 PW(s) carried by the transport tunnel. In this document, the PLR 506 simply computes and establishes a node protection bypass tunnel in 507 the same fashion as the normal IP/MPLS node protection, except that 508 with the notion of context identifier, the bypass tunnel will be 509 established from the PLR to the protector (Section 4.6). Conversely, 510 when the router is no longer a PLR for egress PE or S-PE node 511 protection due to a change in network topology or the transport 512 tunnel's path, the router should revert to the role of regular 513 transit router, including PLR for normal IP/MPLS link or node 514 protection. 516 In local repair, a PLR simply switches all the traffic received on 517 the transport tunnel to the bypass tunnel. This requires that the 518 protector given by the bypass tunnel MUST be intended for all the PWs 519 carried by the transport tunnel. This is achieved by the ingress PE 520 using a context identifier to associate a PW with the specific pair 521 of {primary PE, protector} and map the PW to a transport tunnel 522 destined for the same {primary PE, protector}. The ingress PE MAY map 523 multiple PWs to the transport tunnel, if they share the {primary PE, 524 protector} in common. 526 In local repair, the PLR keeps PW label intact in packets. This 527 obviates the need for the PLR to maintain bypass routes on a per-PW 528 basis, and allows bypass tunnel sharing between PWs. On the other 529 hand, this imposes a requirement on the protector that it MUST be 530 able to forward the packets based on a PW label that is assigned by 531 the primary PE, and ensure that the traffic MUST eventually reach the 532 target CE. From the protector's perspective, this PW label is an 533 upstream assigned label [RFC5331]. To achieve this, the protector 534 MUST learn the PW label from the primary PE prior to the failure, and 535 install proper forwarding state for the PW label in a dedicated label 536 space associated with the primary PE. During local repair, the 537 protector MUST perform PW label lookup in this label space. 539 The previous examples have shown the scenarios where the protectors 540 are backup (T/S-)PEs. It is also possible that a protector is a 541 dedicated router to serve such role, separate from the backup (T/ 542 S-)PE. During local repair, the PLR still reroutes traffic to the 543 protector through a bypass tunnel. The protector then forwards the 544 traffic to the backup (T/S-)PE, which further forwards the traffic to 545 the target CE via a backup AC or a backup PW segment. More detail 546 will be described in Section 4.4. 548 4.3. Context Identifier 550 A protector may protect multiple primary PEs. The protector MUST 551 maintain a separate label space for each primary PE. Likewise, the 552 PWs terminated on a primary PE may be protected by multiple 553 protectors, each for a subset of the PWs. In any case, a given PW 554 MUST be associated with one and only one pair of {primary PE, 555 protector}. 557 This document introduces the notion of "context identifier" to 558 facilitate protection establishment. A context identifier is an 559 IPv4/v6 address assigned to each ordered pair of {primary PE, 560 protector}. The address MUST be globally unique, or unique in the 561 address space of the network where the primary PE and the protector 562 reside. 564 4.3.1. Semantics 566 The semantics of a context identifier is twofold. 568 o A context identifier identifies a primary PE and an associated 569 protector. It represents the primary PE as PW destination on a 570 per protector basis. A given primary PE may be protected by 571 multiple protectors, each for a subset of the PWs terminated on 572 the primary PE. A distinct context identifier MUST be assigned to 573 the primary PE and each protector. 575 The ingress PE of a PW learns the context identifier of the PW's 576 {primary PE, protector} from the primary PE via Interface_ID TLV 578 [RFC3471, RFC3472] in the LDP Label Mapping message of the PW. 579 The ingress PE then sets up or resolves a transport tunnel with 580 the context identifier, rather than a private IP address of the 581 primary PE, as destination. This destination not only makes the 582 transport tunnel reach the primary PE, but also conveys the 583 identity of the protector to the PLR, which MUST use the context 584 identifier as destination for the bypass tunnel to the protector. 585 The ingress PE MUST map only the PWs terminated by the exact 586 primary PE and protected by the exact protector to the transport 587 tunnel. 589 o A context identifier indicates the primary PE's label space on the 590 protector. The protector may protect PWs for multiple primary 591 PEs. For each primary PE, it MUST maintain a separate label space 592 to store the PW labels assigned by that primary PE. It associates 593 a PW label with a label space via the context identifier of the 594 {primary PE, protector}, as below. 596 In addition to the normal LDP PW signaling, the primary PE MUST 597 have a targeted LDP session with the protector, and advertise PW 598 labels to the protector via LDP Label Mapping messages 599 (Section 6). The primary PE MUST attach the context identifier to 600 each message. Upon receiving the message, the protector MUST 601 install the advertised PW label in the label space identified by 602 the context identifier. 604 When a PLR sets up or resolves a bypass tunnel to the protector, 605 it MUST use the context identifier rather than a private IP 606 address of the protector as destination. The protector MUST use 607 the bypass tunnel, either the MPLS tunnel label or IP tunnel 608 destination address, as the pointer to the corresponding label 609 space. The protector MUST forward PW packets received on the 610 bypass tunnel based on label lookup in that label space. 612 4.3.2. IGP Advertisement and Path Computation 614 Using a context identifier as destination for both transport tunnel 615 and bypass tunnel requires coordination between the primary PE and 616 the protector in IGP advertisement of the context identifier in 617 routing domain and TE domain. The context identifier should be 618 advertised in such a way that all the routers on the tunnels MUST be 619 able to independently reach the following common view of paths. 621 o The transport tunnel MUST have the primary PE as path endpoint. 623 o The bypass tunnel MUST have the protector as path endpoint. In 624 egress PE and S-PE node protection, the path MUST avoid the 625 primary PE. 627 There are generally two categories of approaches to achieve the 628 above. 630 o The first category does not require an ingress PE or a PLR to have 631 knowledge of the PW egress endpoint protection schema. It does 632 not require any IGP extension for context identifier 633 advertisement. A context identifier is advertised by the primary 634 PE and the protector as an address reachable via both routers. 635 The ingress PE and the PLR can compute paths by using a normal 636 method, such as Dijkstra, CSPF (constrained shortest path first), 637 LFA [RFC5286] and MRT [RFC7812]. One example is to advertise a 638 context identifier as a virtual proxy node connected to the 639 primary PE and the protector, with the link between the proxy node 640 and the primary PE having a more preferable IGP and TE metric than 641 the link between the proxy node and the protector. The transport 642 tunnel will follow the shortest path or a TE path to the primary 643 PE, and be terminated by the primary PE. The PLR will no longer 644 view itself as a penultimate hop of the transport tunnel, but 645 rather two hops away from the proxy node, via the primary PE. 646 Hence, a node protection bypass tunnel will be available via the 647 protector to the proxy node, but actually be terminated by the 648 protector. 650 o The second category requires a PLR to have knowledge of the PW 651 egress endpoint protection schema. The primary PE advertises the 652 context identifier as a regular IP address, while the protector 653 advertises it by using an explicit "context identifier" object, 654 which MUST be understood by the PLR. The "context identifier" 655 object requires an IGP extension. In both the routing domain and 656 the TE domain, the context identifier is only reachable via the 657 primary PE. This ensures that the transport tunnel is terminated 658 by the primary PE. The PLR views itself as the penultimate hop of 659 the transport tunnel, and based on the IGP "context identifier" 660 object, it establishes or resolves a bypass tunnel to the 661 advertiser (i.e. the protector), while avoiding the primary PE. 663 The mechanism in this document intends to be flexible on the approach 664 used by a network, as long as it satisfies the above requirements for 665 transport tunnel path and bypass tunnel path. For any approach, the 666 coordination between a primary PE and a protector can be achieved by 667 configuration. 669 4.4. Protection Models 671 There are two protection models based on the location of a protector. 672 A network MAY use either model or both. 674 4.4.1. Co-located Protector 676 In this model, the protector is a backup PE that is directly 677 connected to the target CE via a backup AC, or it is a backup S-PE on 678 a backup PW. That is, the protector is co-located with the backup 679 (S-)PE. Examples of this model have been shown in Figure 4, Figure 5 680 and Figure 6 in Section 4.2. 682 In egress AC protection and egress PE node protection, when a 683 protector receives traffic from the PLR, it forwards the traffic to 684 the CE via the backup AC. This is shown in Figure 7, where PE2 is 685 the PLR for egress AC failure, P3 is the PLR for PE2 failure, and PE4 686 (backup PE) is the protector. 688 |<-------------- PW1 --------------->| 690 - PE1 -------------- P1 ------- P3 ----- PE2 ---- 691 / PLR \ PLR \ 692 / \ | \ 693 CE1 bypass\ |bypass CE2 694 \ \ | / 695 \ \ | / 696 - PE3 -------------- P2 ---------------- PE4 ---- 697 protector 699 |<-------------- PW2 --------------->| 701 Figure 7 703 In S-PE node protection, when a protector receives traffic from the 704 PLR, it forwards the traffic over the next segment of the backup PW. 705 The T-PE of the backup PW in turn forwards the traffic to the CE via 706 a backup AC. This is shown in Figure 8, where P1 is the PLR for SPE1 707 failure, and SPE2 (backup S-PE) is the protector for SPE1. SPE2 708 receives traffic from P1, swaps SEG1's label to SEG4's label, and 709 forwards the traffic over a transport tunnel to TPE4. 711 |<--------------- PW1 --------------->| 712 |<----- SEG1 ----->|<----- SEG2 ----->| 714 - TPE1 ----- P1 ----- SPE1 -------------- TPE2 - 715 / PLR \ \ 716 / \ \ 717 CE1 bypass\ CE2 718 \ \ / 719 \ \ / 720 - TPE3 --------------- SPE2 -------------- TPE4 - 721 protector 723 |<----- SEG3 ----->|<----- SEG4 ----->| 724 |<--------------- PW2 --------------->| 726 Figure 8 728 In the co-located protector model, the number of context identifiers 729 needed by a network is the number of distinct {primary PE, backup PE} 730 pairs. From the perspective of scalability, the model is suitable 731 for networks where the number of primary PEs and the average number 732 of backup PEs per primary PE are both relatively low. 734 4.4.2. Centralized Protector 736 In this model, the protector is a dedicated P router or PE router 737 that serves the role. In egress AC protection and egress PE node 738 protection, the protector may or may not be a backup PE directly 739 connected to the target CE. In S-PE node protection, the protector 740 may or may not be a backup S-PE on the backup PW. 742 In egress AC protection and egress PE node protection, if the 743 protector is not directly connected to the CE, it forwards the 744 traffic to a backup PE, which in turn forwards the traffic to the CE 745 via a backup AC. This is shown in Figure 9, where the protector 746 receives traffic from P3 (PLR for egress PE failure) or PE2 (PLR for 747 egress AC failure), swaps PW1's label to PW2's label, and forwards 748 the traffic via a transport tunnel to PE4 (backup PE). The protector 749 may be protecting other PWs and other primary PEs as well, which is 750 not shown in this figure for clarity. 752 |<------------- PW1 --------------->| 754 - PE1 ------------- P1 ------- P3 ----- PE2 -- 755 / PLR \ PLR \ 756 / \ / \ 757 / bypass\ /bypass \ 758 / \ / \ 759 CE1 protector CE2 760 \ \ / 761 \ transport\ / 762 \ tunnel \ / 763 \ \ / 764 - PE3 ------------- P2 -----------------PE4 -- 766 |<------------- PW2 --------------->| 768 Figure 9 770 In S-PE node protection, if the protector is not a backup S-PE, it 771 forwards the traffic to the backup S-PE, which in turn forwards the 772 traffic over the next segment of the backup PW. Finally, the T-PE of 773 the backup PW forwards the traffic to the CE via the backup AC. This 774 is shown in Figure 10, where the protector receives traffic from P1 775 (PLR), swaps SEG1's label to SEG3's label, and forwards the traffic 776 via a transport tunnel to SPE2 (backup S-PE). SPE2 in turn performs 777 MS-PW switching from SEG3's label to SEG4's label, and forwards the 778 traffic over a transport tunnel to TPE4 (backup T-PE). The protector 779 may be protecting other PW segments and other primary S-PEs as well, 780 which is not shown in this figure for clarity. 782 |<--------------- PW1 --------------->| 783 |<----- SEG1 ----->|<----- SEG2 ----->| 785 - TPE1 ----- P1 ----- SPE1 -------------- TPE2 - 786 / PLR \ \ 787 / \ \ 788 / bypass\ \ 789 / \ \ 790 CE1 protector CE2 791 \ \ / 792 \ transport\ / 793 \ tunnel \ / 794 \ \ / 795 - TPE3 --------------- SPE2 -------------- TPE4 - 797 |<----- SEG3 ----->|<----- SEG4 ----->| 798 |<--------------- PW2 --------------->| 800 Figure 10 802 The centralized protector model allows multiple primary PEs to share 803 one protector. Each primary PE may need only one protector. 804 Therefore, the number of context identifiers needed by a network may 805 be bound to the number of primary PEs. 807 4.5. Transport Tunnel 809 A PW is associated with a pair of {primary PE, protector}, which is 810 represented by a unique context identifier. The ingress PE of the PW 811 sets up or resolves a transport tunnel by using the context 812 identifier rather than a private IP address of the primary PE as 813 destination. This not only ensures that the PW is transported to the 814 primary PE, but also facilitates bypass tunnel establishment at PLR, 815 because the context identifier contains the identity of the protector 816 as well. This is also the case for a multi-segment PW, where the 817 ingress PE and egress PE are T/S-PEs. 819 An ingress PE learns the association between a PW and a context 820 identifier from the primary PE, which MUST advertise the context 821 identifier as a "third party next hop" via the IPv4/v6 Interface_ID 822 TLV [RFC3471, RFC3472] in the LDP Label Mapping message of the PW. 824 In an ECMP scenario, a transport tunnel may have multiple penultimate 825 hop routers. Each of them SHOULD act as a PLR independently. Also 826 in an ECMP scenario, a penultimate hop router of a transport tunnel 827 may have ECMP to the primary PE. At least one of the ECMP must be a 828 direct link to the primary PE, qualifying the router as penultimate 829 hop. The other branches of the ECMP may be direct links or indirect 830 paths to the primary PE. In egress PE node protection and S-PE node 831 protection, the penultimate hop router SHOULD act as PLR for all the 832 PWs traversing the entire ECMP. 834 4.6. Bypass Tunnel 836 A PLR may protect multiple PWs associated with one or multiple pairs 837 of {primary PE, protector}. The PLR MUST establish a bypass tunnel to 838 each protector for each context identifier associated with that 839 protector. The destination of the bypass tunnel MUST be the context 840 identifier (Section 4.3.1). Since the PLR is a transit router of the 841 transport tunnel, it SHOULD derive the context identifier from the 842 destination of the transport tunnel. 844 For examples, in Figure 7 and Figure 9, a bypass tunnel is 845 established from PE2 (PLR for egress AC failure) to the protector, 846 and another bypass tunnel is established from P3 (PLR for egress node 847 failure) to the protector. In Figure 8 and Figure 10, a bypass 848 tunnel is established from P1 (PLR for S-PE failure) to the 849 protector. 851 In local repair, a PLR reroutes traffic to the protector through a 852 bypass tunnel, with PW label intact in the packets. This normally 853 involves pushing a label to the label stack, if the bypass tunnel is 854 an MPLS tunnel, or pushing an IP header to the packets, if the bypass 855 tunnel is an IP tunnel. Upon receipt of the packets, the protector 856 forwards them based on the PW label. Specifically, the protector 857 uses the bypass tunnel as a context to determine the primary PE's 858 label space. If the bypass tunnel is an MPLS tunnel, the protector 859 should have assigned a non-reserved label to the bypass tunnel, and 860 hence this label can serve as the context. This label is also called 861 a "context label", as it is actually bound to the context identifier. 862 If the bypass tunnel is an IP tunnel, the context identifier should 863 be the destination address of IP header. 865 To be useful for local repair, a bypass tunnel MUST have the property 866 that it is not affected by any topology changes caused by the 867 failure. It MUST NOT traverse the primary PE or the penultimate link 868 of the transport tunnel, or share any SRLG with the penultimate link. 869 It should remain effective during local repair, until the traffic is 870 moved to an alternative path, i.e. either the same PW over a fully 871 functional transport tunnel, or another fully functional PW. 873 A bypass tunnel SHOULD NOT need to be further protected against a 874 transit link failure, transit node failure, or egress node failure. 876 4.7. Examples of Forwarding State 878 This section provides some detailed examples of forwarding state on 879 PLR, protector, and other relevant routers. 881 A protector learns PW labels from all the primary PEs that it 882 protects (Section 6.2), and maintains the PW labels in separate label 883 spaces on a per primary PE basis. In the control plane, each label 884 space is identified by the context identifier of the corresponding 885 {primary PE, protector}. In the forwarding plane, it is indicated by 886 the bypass tunnel(s) destined for the context identifier. 888 4.7.1. Co-located Protector Model 890 In Figure 11, PE4 is a co-located protector that protects PW1 against 891 egress AC failure and egress node failure. It maintains a label 892 space for PE2, which is identified by the context identifier of {PE2, 893 PE4}. It learns PW1's label from PE2, and installs an forwarding 894 entry for the label in that label space. The nexthop of the 895 forwarding entry indicates a label pop with outgoing interface 896 pointing to the backup AC PE4-CE2. 898 |<-------------- PW1 --------------->| 900 - PE1 -------------- P1 ------- P3 ----- PE2 ------ 901 / PLR \ PLR \ 902 / \ | \ 903 / \ | \ 904 CE1 bypass P4 P5 bypass CE2 905 \ \ | / 906 \ \ | / 907 \ \ | / 908 - PE3 -------------- P2 ---------------- PE4 ------ 909 protector 911 |<-------------- PW2 --------------->| 913 PW1's label assigned by PE2: 100 914 PW2's label assigned by PE4: 200 915 On P3: 916 Incoming label of transport tunnel to PE2: 1000 917 Outgoing label of transport tunnel to PE2: implicit null 918 Outgoing label of bypass tunnel to PE4: 2000 919 On PE2: 920 Outgoing label of bypass tunnel to PE4: 3000 921 On PE4: 922 Context label (incoming label of bypass tunnels): 999 924 Forwarding state on P3: 925 label 1000 -- primary nexthop: pop, to PE2 926 backup nexthop: swap 2000, to P4 928 Forwarding state on PE2: 929 label 100 -- primary nexthop: pop, to CE2 930 backup nexthop: push 3000, to P5 932 Forwarding state on PE4: 933 label 200 -- nexthop: pop, to CE2 934 label 999 -- nexthop: label table of PE2's label space 936 Label table of PE2's label space on PE4: 937 label 100 -- nexthop: pop, to CE2 939 Figure 11 941 In Figure 12, SPE2 is a co-located protector that protects PW1 942 against S-PE failure. It maintains a label space for SPE1, which is 943 identified by the context identifier of {SPE1, SPE2}. It learns 944 SEG1's label from SPE1, and installs a forwarding entry in the label 945 space. The nexthop of the forwarding entry indicates a label swap to 946 SEG4's label and a label push with the label of a transport tunnel to 947 TPE4. 949 |<--------------- PW1 --------------->| 950 |<----- SEG1 ----->|<----- SEG2 ----->| 952 - TPE1 ----- P1 ----- SPE1 --- P3 ------- TPE2 - 953 / PLR \ \ 954 / \ \ 955 CE1 bypass P2 CE2 956 \ \ / 957 \ \ / 958 - TPE3 --------------- SPE2 --- P4 ------- TPE4 - 959 protector 961 |<----- SEG3 ----->|<----- SEG4 ----->| 962 |<--------------- PW2 --------------->| 964 SEG1's label assigned by SPE1: 100 965 SEG2's label assigned by TPE2: 200 966 SEG3's label assigned by SPE2: 300 967 SEG4's label assigned by TPE4: 400 968 On P1: 969 Incoming label of transport tunnel to SPE1: 1000 970 Outgoing label of transport tunnel to SPE1: implicit null 971 Outgoing label of bypass tunnel to SPE2: 2000 972 On SPE1: 973 Outgoing label of transport tunnel to TPE2: 3000 974 On SPE2: 975 Outgoing label of transport tunnel to TPE4: 4000 976 Context label (incoming label of bypass tunnel): 999 978 Forwarding state on P1: 979 label 1000 -- primary nexthop: pop, to SPE1 980 backup nexthop: swap 2000, to P2 982 Forwarding state on SPE1: 983 label 100 -- nexthop: swap 200, push 3000, to P3 985 Forwarding state on SPE2: 986 label 300 -- nexthop: swap 400, push 4000, to P4 987 label 999 -- nexthop: label table of SPE1's label space 989 Label table of SPE1's label space on SPE2: 990 label 100 -- nexthop: swap 400, push 4000, to P4 992 Figure 12 994 4.7.2. Centralized Protector Model 996 In the centralized protector model, for each primary PW of which the 997 protector is not a backup (S-)PE, the protector MUST also learn the 998 label of the backup PW from the backup (S-)PE (Section 6.3). This is 999 the backup (S-)PE that the protector will forward traffic to. The 1000 protector MUST install a forwarding entry with a label swap from the 1001 primary PW's label to the backup PW's label and a label push with the 1002 label of a transport tunnel to the backup (S-)PE. 1004 In Figure 13, the protector is a centralized protector that protects 1005 PW1 against egress AC failure and egress node failure. It maintains 1006 a label space for PE2, which is identified by the context identifier 1007 of {PE2, protector}. It learns PW1's label from PE2, and PW2's label 1008 from PE4. It installs a forwarding entry for PW1's label in the 1009 label space. The nexthop of the forwarding entry indicates a label 1010 swap to PW2's label and a label push with the label of a transport 1011 tunnel to PE4. 1013 |<-------------- PW1 --------------->| 1015 - PE1 ------------- P1 ------- P3 ------ PE2 ---- 1016 / PLR \ PLR \ 1017 / \ / \ 1018 / bypass P5 P6 bypass \ 1019 / \ / \ 1020 / \/ \ 1021 CE1 protector CE2 1022 \ \ / 1023 \ transport \ / 1024 \ tunnel P7 / 1025 \ \ / 1026 \ \ / 1027 - PE3 ------------- P2 ----------------- PE4 ---- 1029 |<-------------- PW2 --------------->| 1031 PW1's label assigned by PE2: 100 1032 PW2's label assigned by PE4: 200 1033 On P3: 1034 Incoming label of transport tunnel to PE2: 1000 1035 Outgoing label of transport tunnel to PE2: implicit null 1036 Outgoing label of bypass tunnel to protector: 2000 1037 On PE2: 1038 Outgoing label of bypass tunnel to protector: 3000 1039 On protector: 1040 Context label (incoming label of bypass tunnels): 999 1041 Outgoing label of transport tunnel to PE4: 4000 1043 Forwarding state on P3: 1044 label 1000 -- primary nexthop: pop, to PE2 1045 backup nexthop: swap 2000, to P5 1047 Forwarding state on PE2: 1048 label 100 -- primary nexthop: pop, to CE2 1049 backup nexthop: push 3000, to P6 1051 Forwarding state on PE4: 1052 label 200 -- nexthop: pop, to CE2 1054 Forwarding state on protector: 1055 label 999 -- nexthop: label table of PE2's label space 1057 Label table of PE2's label space on protector: 1058 label 100 -- nexthop: swap 200, push 4000, to P7 1060 Figure 13 1062 In Figure 14, the protector is a centralized protector that protects 1063 the PW segment SEG1 of PW1 against the node failure of SPE1. It 1064 maintains a label space for SPE1, which is identified by the context 1065 identifier of {SPE1, protector}. It learns SEG1's label from SPE1, 1066 and learns SEG3's label from SPE2. It installs a forwarding entry 1067 for SEG1's label in the label space. The nexthop of the forwarding 1068 entry indicates a label swap to SEG3's label and a label push with 1069 the label of a transport tunnel to TPE4. 1071 |<--------------- PW1 --------------->| 1072 |<----- SEG1 ----->|<----- SEG2 ----->| 1074 - TPE1 ----- P1 ----- SPE1 --- P2 -------- TPE2 - 1075 / PLR \ \ 1076 / \ \ 1077 / bypass P4 \ 1078 / \ \ 1079 / \ \ 1080 CE1 protector CE2 1081 \ \ / 1082 \ \ / 1083 \ transport P5 / 1084 \ tunnel \ / 1085 \ \ / 1086 - TPE3 -------------- SPE2 --- P3 -------- TPE4 - 1088 |<----- SEG3 ----->|<----- SEG4 ----->| 1089 |<--------------- PW2 --------------->| 1091 SEG1's label assigned by SPE1: 100 1092 SEG2's label assigned by TPE2: 200 1093 SEG3's label assigned by SPE2: 300 1094 SEG4's label assigned by TPE4: 400 1095 On P1: 1096 Incoming label of transport tunnel to SPE1: 1000 1097 Outgoing label of transport tunnel to SPE1: implicit null 1098 Outgoing label of bypass tunnel to protector: 2000 1099 On SPE1: 1100 Outgoing label of transport tunnel to TPE2: 3000 1101 On SPE2: 1102 Outgoing label of transport tunnel to TPE4: 4000 1103 On protector: 1104 Context label (incoming label of bypass tunnel): 999 1105 Outgoing label of transport tunnel to SPE2: 5000 1107 Forwarding state on P1: 1108 label 1000 -- primary nexthop: pop, to SPE1 1109 backup nexthop: swap 2000, to P4 1111 Forwarding state on SPE1: 1112 label 100 -- nexthop: swap 200, push 3000, to P2 1114 Forwarding state on SPE2: 1115 label 300 -- nexthop: swap 400, push 4000, to P3 1117 Forwarding state on protector: 1118 label 999 -- nexthop: label table of SPE1's label space 1120 Label table of SPE1's label space on protector: 1121 label 100 -- nexthop: swap 300, push 5000, to P5 1123 Figure 14 1125 5. Revertive Behavior 1127 Subsequent to local repair, there are three strategies for a network 1128 to restore traffic to a fully functional alternative path. 1130 o Global revertive mode 1132 If the ingress CE is multi-homed (Figure 1), it MAY switch the 1133 traffic to the backup AC which is bound to the backup PW. 1134 Alternatively, if the ingress PE hosts a backup PW (Figure 2), the 1135 ingress PE MAY switch the traffic to the backup PW. These 1136 procedures are referred to as global repair. Possible triggers of 1137 global repair include PW status notification, VCCV, BFD, end-to- 1138 end OAM between CEs, etc. 1140 o Control plane revertive mode 1142 In egress PE node protection and S-PE node protection, it is 1143 possible that the failure is limited to the link between the PLR 1144 and the primary PE, whereas the primary PE is still operational. 1145 In this case, the PLR or an upstream router on the transport 1146 tunnel MAY reroute the tunnel around the link via an alternative 1147 path to the primary PE. Thus, the transport tunnel can heal and 1148 continue to carry the PW to the primary PE. This procedure is 1149 driven by control plane convergence on the new topology, and is 1150 referred to as control plane repair. 1152 o Local revertive mode 1154 The PLR MAY move traffic back to the primary PW, after the failure 1155 is resolved. In egress AC protection, upon detecting that the 1156 primary AC is restored, the PLR MAY start forwarding traffic over 1157 the AC again. Likewise, in egress PE node protection and S-PE 1158 node protection, upon detecting that the primary PE is restored, 1159 the PLR MAY re-establish the transport tunnel to the primary PE, 1160 and move the traffic from the bypass tunnel back to the transport 1161 tunnel. These procedures are referred to as local reversion. 1163 It is RECOMMENDED that the fast protection mechanism SHOULD be used 1164 in conjunction with the global revertive mode. Particularly in the 1165 case of egress PE and S-PE node failures, if the ingress PE or the 1166 protector loses communication with the (S-)PE for an extensive period 1167 of time, LDP session may go down. Consequently, the ingress PE may 1168 bring down the primary PW completely, or the protector may remove the 1169 forwarding entry of the primary PW label. In either case, the 1170 service will be disrupted. In other words, although the mechanism 1171 can temporarily repair traffic, control plane state may eventually 1172 expire if the failure persists. Therefore, the global revertive mode 1173 SHOULD take place in a timely manner to move traffic to a fully 1174 functional alternative path. 1176 The control plane revertive mode may automatically happen as part of 1177 the convergence of control plane protocols. However, it is only 1178 applicable to the specific link failure scenario described above. 1180 The local revertive mode is optional. In the circumstances where the 1181 failure is caused by resource flapping, local reversion MAY be 1182 dampened to limit potential disruption. Local revertive mode MAY be 1183 disabled completely by configuration. 1185 6. LDP Extensions 1187 As described in previous sections, a targeted LDP session MUST be 1188 established between each pair of primary PE and protector. The 1189 primary PE sends Label Mapping message over this session to advertise 1190 primary PW labels to the protector. In the centralized protector 1191 model, a targeted LDP session MUST also be established between a 1192 backup (S-)PE and the protector. The backup PE sends Label Mapping 1193 message over this session to advertise backup PW labels to the 1194 protector. 1196 To facilitate the procedures, this document defines a new "Protection 1197 FEC Element" TLV. The Label Mapping messages of both the LDP 1198 sessions above MUST carry this TLV to identify a primary PW. 1199 Specifically, in the centralized protector model, the Protection FEC 1200 Element TLV advertised by a backup (S-)PE MUST match the one 1201 advertised by the primary PE, so that the protector can associate the 1202 primary PW's label with the backup PW's label, and perform a label 1203 swap. The backup (S-)PE builds such a Protection FEC Element TLV 1204 based on local configuration. 1206 This document also defines the encoding of Capability Parameter TLV 1207 [RFC5561] for a new "Egress Protection Capability", to allow a 1208 protector to announce its capability of processing the above 1209 Protection FEC Element TLV and performing context specific label 1210 switching for PW labels. 1212 The procedures in this section are only applicable, if the protector 1213 advertises the Egress Protection Capability, the primary PE supports 1214 the advertisement of the Protection FEC Element TLV, and in the 1215 centralized protector model, the backup PE also supports the 1216 advertisement of the Protection FEC Element TLV. 1218 6.1. Egress Protection Capability TLV 1220 A protector MUST advertise the Egress Protection Capability TLV in 1221 its Initialization message and Capability message, over the LDP 1222 session with a primary PE. In the centralized protector model, the 1223 protector MUST also advertise the TLV over the LDP session with a 1224 backup PE. The TLV carries one or multiple context identifiers. To 1225 the primary PE, the TLV MUST carry the context identifier of the 1226 {primary PE, protector}. In the centralized protector model, the TLV 1227 MUST carry to the backup PE multiple context identifiers, one for 1228 each {primary PE, protector} where the backup PE serves as a backup 1229 for the primary PE. This TLV MUST NOT be advertised by the primary 1230 PE or the backup PE to the protector. 1232 The processing of the Egress Protection Capability TLV by a receiving 1233 router MUST follow the procedures defined in [RFC5561]. In 1234 particular, the router MUST advertise PW information to the protector 1235 by using the Protection FEC Element TLV, only after it has received 1236 the Egress Protection Capability TLV from the protector. It MUST 1237 validate each context identifier included in the TLV, and advertise 1238 the information of only the PWs that are associated with the context 1239 identifier. It MUST withdraw previously advertised Protection FEC 1240 TLVs, when the protector has withdrawn a previously advertised 1241 context identifier or the entire Egress Protection Capability TLV via 1242 Capability message. 1244 The encoding of the Egress Protection Capability TLV is defined as 1245 below. It conforms to the format of Capability Parameter TLV 1246 specified in [RFC5561]. 1248 0 1 2 3 1249 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 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 |U|F| Egress Protection (TBD) | Length | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 |S| Reserved | | 1254 +-+-+-+-+-+-+-+-+ | 1255 | | 1256 ~ Capability Data = context identifier(s) ~ 1257 | | 1258 | +-+-+-+-+-+-+-+-+ 1259 | | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 Figure 15 1264 The U-bit MUST be set to 1 so that a receiver MUST silently ignore 1265 this TLV if unknown to it, and continue processing the rest of the 1266 message. 1268 The F-bit MUST be set to 0 since this TLV is sent only in 1269 Initialization and Capability messages, which are not forwarded. 1271 The TLV Code Point is TBD. It needs to be assigned by IANA. 1273 The S-bit indicates whether the sender is advertising (S=1) or 1274 withdrawing (S=0) the capability. 1276 The "Capability Data" is encoded with the context identifier of the 1277 {primary PE, protector}. 1279 6.2. PW Label Distribution from Primary PE to Protector 1281 A primary PE MUST advertise a primary PW's label to a protector by 1282 sending a Label Mapping message. The message includes a Protection 1283 FEC Element TLV (see Section 6.4 for encoding), and an Upstream- 1284 Assigned Label TLV [RFC6389] encoded with the PW's label. The 1285 combination of the Protection FEC Element TLV and the PW label 1286 represents the primary PE's forwarding state for the PW. The Label 1287 Mapping message MUST also carry an IPv4/v6 Interface_ID TLV [RFC6389, 1288 RFC3471] encoded with the context identifier of the {primary PE, 1289 protector}. 1291 The protector that receives this Label Mapping message MUST install a 1292 forwarding entry for the PW label in the label space identified by 1293 the context identifier. The nexthop of the forwarding entry MUST 1294 ensure packets to be sent towards the target CE via a backup AC or a 1295 backup (S-)PE, depending on the protection scenario. The protector 1296 MUST silently discard a Label Mapping message if the included context 1297 identifier is unknown to it. 1299 6.3. PW Label Distribution from Backup PE to Protector 1301 In the centralized protector model, a backup PE MUST advertise a 1302 backup PW's label to the protector by sending a Label Mapping 1303 message. The message includes a Protection FEC Element TLV and a 1304 Generic Label TLV encoded with the backup PW's label. This 1305 Protection FEC Element MUST be identical to the Protection FEC 1306 Element TLV that the primary PE advertises to the protector 1307 (Section 6.2). This is achieved through configuration on the backup 1308 PE. The context identifier MUST NOT be encoded in Interface_ID TLV 1309 in this message. 1311 The protector that receives this Label Mapping message MUST associate 1312 the backup PW with the primary PW, based on the common Protection FEC 1313 Element TLV. It MUST distinguish between the Label Mapping message 1314 from the primary PE and the Label Mapping message from the backup PE 1315 based on the respective presence and absence of context identifier in 1316 Interface_ID TLV. It MUST install a forwarding entry for the primary 1317 PW's label in the label space identified by the context identifier. 1318 The nexthop of the forwarding entry MUST indicate a label swap to the 1319 backup PW's label, followed by a label push or IP header push for a 1320 transport tunnel to the backup PE. 1322 6.4. Protection FEC Element TLV 1324 The Protection FEC Element TLV has type 0x83. Its format is defined 1325 as below: 1327 0 1 2 3 1328 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 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | Type(0x83) | Reserved | Encoding Type | Length | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | | 1333 | | 1334 ~ PW Information ~ 1335 | | 1336 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 Figure 16 1342 - Encoding Type 1343 Type of format that PW Information field is encoded. 1345 - Length 1347 Length of PW Information field in octets. 1349 - PW Information 1351 Field of variable length that specifies a PW 1353 For Encoding Type, 1 is defined for the PWid FEC Element format, and 1354 2 is defined for the Generalized PWid FEC Element format [RFC4447]. 1356 6.4.1. Encoding Format for PWid 1358 0 1 2 3 1359 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 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | Type(0x83) | Reserved | Enc Type(1) | Length(16) | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | Ingress PE Address | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Egress PE Address | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Group ID | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | PW ID | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 |C| PW Type | Reserved | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 Figure 17 1376 - Ingress PE Address 1378 IP address of the ingress PE of PW. 1380 - Egress PE Address 1382 IP address of the egress PE of PW. 1384 - Group ID 1386 An arbitrary 32-bit value that represents a group of PWs and that 1387 is used to create groups in the PW space. 1389 - PW ID 1390 A non-zero 32-bit connection ID that, together with the PW Type 1391 field, identifies a particular PW. 1393 - Control word bit (C) 1395 A bit that flags the presence of a control word on this PW. If C 1396 = 1, control word is present; If C = 0, control word is not 1397 present. 1399 - PW Type 1401 A 15-bit quantity that represents the type of PW. 1403 6.4.2. Encoding Format for Generalized PWid 1405 0 1 2 3 1406 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 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | Type(0x83) | Reserved | Enc Type(2) | Length | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | Ingress PE Address | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | Egress PE Address | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 |C| PW Type | Reserved | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | AGI Type | Length | Value | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 ~ AGI Value (contd.) ~ 1419 | | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | AII Type | Length | Value | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 ~ SAII Value (contd.) ~ 1424 | | 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 | AII Type | Length | Value | 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 ~ TAII Value (contd.) ~ 1429 | | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 Figure 18 1434 - Ingress PE Address 1436 IP address of the ingress PE of PW. 1438 - Egress PE Address 1440 IP address of the egress PE of PW. 1442 - Control word bit (C) 1444 A bit that flags the presence of a control word on this PW. If C 1445 = 1, control word is present; If C = 0, control word is not 1446 present. 1448 - PW Type 1450 A 15-bit quantity that represents the type of PW. 1452 - AGI Type, Length, Value, AGI Value 1454 Attachment Group Identifier of PW. 1456 - SAII Type, Length, Value, SAII Value 1458 Source Attachment Individual Identifier of PW. 1460 - TAII Type, Length, Value, TAII Value 1462 Target Attachment Individual Identifier of PW. 1464 7. IANA Considerations 1466 This document defines the encoding of the Capability Parameter TLV 1467 for the new "Egress Protection Capability" in Section 6. This would 1468 require IANA to assign a TLV Code Point to it. 1470 This document defines a new LDP Protection FEC Element TLV in 1471 Section 6. IANA has assigned the type value 0x83 to it. 1473 Value Hex Name Label Advertisement Discipline 1474 ------------------------------------------------------------------- 1475 131 0x83 Protection FEC Element DU 1477 8. Security Considerations 1479 The security considerations discussed in [RFC5036, RFC5331, RFC3209, 1480 RFC4090] apply to this document. There is no additional 1481 consideration. 1483 9. Acknowledgements 1485 This document leverages work done by Hannes Gredler, Yakov Rekhter, 1486 Minto Jeyananth, Kevin Wang and several on MPLS edge protection. 1487 Thanks to Nischal Sheth and Bhupesh Kothari for their contribution. 1488 Thanks to John E Drake, Andrew G Malis, Alexander Vainshtein, Stewart 1489 Bryant, and Mach Chen for valuable comments that helped shape this 1490 document and improve its clarity. 1492 10. References 1494 10.1. Normative References 1496 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 1497 G. Heron, "Pseudowire Setup and Maintenance Using the 1498 Label Distribution Protocol (LDP)", RFC 4447, 1499 DOI 10.17487/RFC4447, April 2006, 1500 . 1502 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1503 Label Assignment and Context-Specific Label Space", 1504 RFC 5331, DOI 10.17487/RFC5331, August 2008, 1505 . 1507 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 1508 Le Roux, "LDP Capabilities", RFC 5561, 1509 DOI 10.17487/RFC5561, July 2009, 1510 . 1512 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 1513 Switching (GMPLS) Signaling Functional Description", 1514 RFC 3471, DOI 10.17487/RFC3471, January 2003, 1515 . 1517 [RFC3472] Ashwood-Smith, P., Ed. and L. Berger, Ed., "Generalized 1518 Multi-Protocol Label Switching (GMPLS) Signaling 1519 Constraint-based Routed Label Distribution Protocol (CR- 1520 LDP) Extensions", RFC 3472, DOI 10.17487/RFC3472, January 1521 2003, . 1523 [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label 1524 Assignment for LDP", RFC 6389, DOI 10.17487/RFC6389, 1525 November 2011, . 1527 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1528 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1529 DOI 10.17487/RFC4090, May 2005, 1530 . 1532 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 1533 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 1534 DOI 10.17487/RFC5286, September 2008, 1535 . 1537 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 1538 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 1539 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 1540 . 1542 10.2. Informative References 1544 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 1545 Edge-to-Edge (PWE3) Architecture", RFC 3985, 1546 DOI 10.17487/RFC3985, March 2005, 1547 . 1549 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 1550 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 1551 DOI 10.17487/RFC5659, October 2009, 1552 . 1554 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1555 RFC 5714, DOI 10.17487/RFC5714, January 2010, 1556 . 1558 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1559 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1560 . 1562 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 1563 Regan, J., and S. Amante, "Flow-Aware Transport of 1564 Pseudowires over an MPLS Packet Switched Network", 1565 RFC 6391, DOI 10.17487/RFC6391, November 2011, 1566 . 1568 Authors' Addresses 1570 Yimin Shen 1571 Juniper Networks 1572 10 Technology Park Drive 1573 Westford, MA 01886 1574 USA 1576 Phone: +1 9785890722 1577 Email: yshen@juniper.net 1578 Rahul Aggarwal 1579 Arktan, Inc 1581 Email: raggarwa_1@yahoo.com 1583 Wim Henderickx 1584 Alcatel-Lucent 1585 Copernicuslaan 50 1586 2018 Antwerp 1587 Belgium 1589 Email: wim.henderickx@alcatel-lucent.be 1591 Yuanlong Jiang 1592 Huawei Technologies 1594 Email: jiangyuanlong@huawei.com