idnits 2.17.1 draft-shen-pwe3-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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: At any given time, each CE sends traffic via only one AC and receives traffic via only one AC. The two ACs MAY or MAY NOT be the same. The AC used to send traffic is determined by the CE, and MAY rely on an end-to-end OAM mechanism between the CEs. The AC used for the CE to receive traffic is determined by the state of the network and the protection mechanism in use, as described later in this document. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In this model, the protector is a dedicated P router or PE router that protects PWs for multiple primary PEs. In egress AC protection and egress PE node protection, the protector MAY or MAY NOT be a backup PE with a direct connection to the target CE. In S-PE node protection, the protector MAY or MAY NOT be a backup S-PE of the backup PW. -- The document date (February 8, 2013) is 4066 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) == Unused Reference: 'RFC3985' is defined on line 1114, but no explicit reference was found in the text == Unused Reference: 'RFC5659' is defined on line 1117, but no explicit reference was found in the text == Unused Reference: 'RFC4447' is defined on line 1121, but no explicit reference was found in the text == Unused Reference: 'RFC5331' is defined on line 1125, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 1129, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 1132, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1136, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 1140, but no explicit reference was found in the text == Unused Reference: 'RFC5286' is defined on line 1144, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 1147, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 1150, but no explicit reference was found in the text == Unused Reference: 'RFC3472' is defined on line 1154, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 1159, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 1162, but no explicit reference was found in the text == Unused Reference: 'RFC5880' is defined on line 1164, but no explicit reference was found in the text == Unused Reference: 'RFC6389' is defined on line 1167, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 1184, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3985 ** Downref: Normative reference to an Informational RFC: RFC 5659 ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Downref: Normative reference to an Informational RFC: RFC 5714 Summary: 4 errors (**), 0 flaws (~~), 20 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Y. Shen, Ed. 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track R. Aggarwal 5 Expires: August 12, 2013 Arktan, Inc 6 W. Henderickx 7 Alcatel-Lucent 8 February 8, 2013 10 PW Endpoint Fast Failure Protection 11 draft-shen-pwe3-endpoint-fast-protection-03 13 Abstract 15 This document specifies a fast mechanism for protecting pseudowires 16 (PWs) against egress endpoint failures, including egress attachment 17 circuit failure, egress PE failure, multi-segment PW terminating PE 18 failure, and multi-segment PW switching PE failure. Designed on the 19 basis of multi-homed CE, PW redundancy, upstream label assignment and 20 context specific label switching, the mechanism enables local repair 21 to be performed by a router upstream adjacent to a failure. In 22 particular, the router can restore PW traffic in the order of tens of 23 milliseconds, by transmitting the traffic to a protector through a 24 pre-established bypass tunnel. Therefore, the mechanism can be used 25 to reduce traffic loss before a global repair mechanism reacts to the 26 failure or the network converges on the topology changes due to the 27 failure. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 12, 2013. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 65 3. Reference Models and Failure Cases . . . . . . . . . . . . . . 4 66 3.1. Single-Segment PW . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Multi-Segment PW . . . . . . . . . . . . . . . . . . . . . 7 68 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. Local Repair and Protector . . . . . . . . . . . . . . . . 8 70 4.2. Context Identifier . . . . . . . . . . . . . . . . . . . . 11 71 4.2.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 11 72 4.2.2. Advertisement and Path Computation . . . . . . . . . . 12 73 4.3. Protection Models . . . . . . . . . . . . . . . . . . . . 12 74 4.3.1. Co-located Protector . . . . . . . . . . . . . . . . . 12 75 4.3.2. Centralized Protector . . . . . . . . . . . . . . . . 14 76 4.4. Transport Tunnel . . . . . . . . . . . . . . . . . . . . . 15 77 4.5. Bypass Tunnel . . . . . . . . . . . . . . . . . . . . . . 16 78 4.6. Forwarding State on Protector . . . . . . . . . . . . . . 16 79 4.6.1. Co-located Protector . . . . . . . . . . . . . . . . . 17 80 4.6.2. Centralized Protector . . . . . . . . . . . . . . . . 18 81 4.7. PW Label Distribution from Primary PE to Protector . . . . 20 82 4.7.1. Protection FEC Element Encoding for PWid . . . . . . . 22 83 4.7.2. Protection FEC Element Encoding for Generalized 84 PWid . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 4.8. PW Label Distribution from Backup PE to Protector . . . . 24 86 4.9. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 25 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 8.1. Normative References . . . . . . . . . . . . . . . . . . . 26 92 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 95 1. Introduction 97 Per RFC 3985, RFC 4447 and RFC 5659, a pseudowire (PW) or PW segment 98 can be thought of as a connection between a pair of forwarders hosted 99 by two PEs, carrying an emulated layer-2 service over a packet 100 switched network (PSN). In the single-segment PW (SS-PW) case, a 101 forwarder binds a PW to an attachment circuit (AC). In the multi- 102 segment PW (MS-PW) case, a forwarder on a terminating PE (T-PE) binds 103 a PW segment to an AC, while a forwarder on a switching PE (S-PE) 104 binds one PW segment to another PW segment. In each direction 105 between the PEs, PW packets are transported by a PSN tunnel, which is 106 called a transport tunnel. 108 In order to protect a layer-2 service against network failures, it is 109 necessary to protect every link and node along the entire data path. 110 From the perspective of the traffic in a given direction, this 111 include ingress AC, ingress (T-)PE, intermediate routers of transport 112 tunnel, S-PEs, egress (T-)PE, and egress AC. To minimize service 113 disruption, it is also desirable that each of these components is 114 protected by a fast protection mechanism based on local repair. Such 115 a mechanism generally involves a bypass path that is pre-computed and 116 pre-installed on a router upstream adjacent to a failure. The bypass 117 path has the property that it can guide traffic around the failure, 118 while remaining unaffected by the topology changes resulting from the 119 failure. When the failure happens, the router can invoke the bypass 120 path to achieve fast restoration for the service. 122 Today, fast protection against ingress AC failure and ingress (T-)PE 123 failure is achievable by using a multi-homed CE and redundant PWs. 124 Fast protection against failure of intermediate router is achievable 125 through RSVP fast-reroute (RFC 4090) and IP/LDP fast-reroute (RFC 126 5714 and RFC 5286). However, there is a lack of such protection 127 against egress AC failure, egress (T-)PE failure, and S-PE failure. 128 In these cases, service restoration has to rely on global repair or 129 control plane repair. Global repair is normally driven by ingress CE 130 or ingress (T-)PE, and dependent on status notification or end-to-end 131 OAM. Control plane repair is dependent on protocol convergence. 132 Therefore, both mechanisms are relatively slow in reacting to 133 failures and restoring traffic. 135 This document intends to serve the exact need for the above. It 136 specifies a fast protection mechanism based on local repair technique 137 to protect PWs against the following egress endpoint failures. 139 a. Egress AC failure. 141 b. Egress PE failure: Node failure of an egress PE of a SS-PW; Node 142 failure of a T-PE of an MS-PW. 144 c. Switching PE failure: Node failure of an S-PE of an MS-PW. 146 The mechanism is applicable to LDP signaled PWs. It is relevant to 147 networks with redundant PWs and multi-homed CEs. It is designed on 148 the basis of MPLS upstream label assignment and context specific 149 label switching (RFC 5331). Fast protection refers to the ability to 150 restore traffic upon a failure in the order of tens of milliseconds. 151 This is achieved by establishing local protection at the router 152 upstream adjacent to the failure. Compared with the existing global 153 repair and control plane repair mechanisms, this mechanism can 154 provide faster restoration. However, it is intended to complement 155 those mechanisms, rather than replacing them in any way. 157 2. Specification of Requirements 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119. 163 3. Reference Models and Failure Cases 165 This document refers to the following topologies to describe failure 166 scenarios and protection procedures. These topologies involve multi- 167 homed CEs and redundant PWs which are commonly seen in networks with 168 a global repair mechanism. In this document, the fast protection 169 mechanism will also take advantage of them for local repair purposes. 170 This SHALL enable local repair and global repair to work in tandem to 171 achieve broader scope and better performance for protection. 173 3.1. Single-Segment PW 175 |<-------------- PW1 --------------->| 177 - PE1 -------------- P1 ---------------- PE2 - 178 / \ 179 / \ 180 CE1 CE2 181 \ / 182 \ / 183 - PE3 -------------- P2 ---------------- PE4 - 185 |<-------------- PW2 --------------->| 187 Figure 1 189 In Figure 1, the IP/MPLS network consists of PE-routers and 190 P-routers. It provides an emulation of a layer-2 service between CE1 191 and CE2. 193 Each CE is multi-homed to two PEs. Hence, there are two divergent 194 paths between the CEs. The first path uses PW1 established between 195 PE1 and PE2, connecting the AC CE1-PE1 and the AC CE2-PE2. The 196 second path uses PW2 established between PE3 and PE4, connecting the 197 AC CE1-PE3 and the AC CE2-PE4. The operational states of all the PWs 198 and ACs are up. The transport tunnels of the PWs are not shown in 199 this figure for clarity. 201 At any given time, each CE sends traffic via only one AC and receives 202 traffic via only one AC. The two ACs MAY or MAY NOT be the same. 203 The AC used to send traffic is determined by the CE, and MAY rely on 204 an end-to-end OAM mechanism between the CEs. The AC used for the CE 205 to receive traffic is determined by the state of the network and the 206 protection mechanism in use, as described later in this document. 208 From the perspective of traffic towards a given CE, the set of PWs, 209 PEs and ACs involved can be viewed to serve primary and backup (or 210 active and standby) roles. When the network is in a steady state, 211 the PW that is intended to carry the traffic is referred to as a 212 primary PW. The PE at the egress of the primary PW is a primary PE. 213 The AC connecting the CE and the primary PE is a primary AC. The 214 other PW that may be used to carry the traffic upon a network failure 215 are referred to as a backup PW. The PE at the egress of the backup 216 PW is a backup PE. The AC connecting the CE and the backup PE is a 217 backup AC. 219 In this document, the following primary and backup roles are assigned 220 for the traffic going from CE1 to CE2: 222 Primary PW: PW1 224 Primary PE: PE2 226 Primary AC: CE2-PE2 228 Backup PW: PW2 230 Backup PE: PE4 232 Backup AC: CE2-PE4 234 In this case, an egress AC failure refers to the failure of the AC 235 CE2-PE2. An egress node failure refers to the failure of PE2. 237 The backup PE, backup PW and backup AC may be used to carry the 238 traffic when CE1 and CE2 switches traffic to PW2 during global 239 repair, or when a local repair takes effect, as described later in 240 this document. 242 |<-------------- PW1 --------------->| 244 ------------- P1 ---------------- PE2 - 245 / \ 246 / \ 247 CE1 -- PE1 CE2 248 \ / 249 \ / 250 ------------- P2 ---------------- PE4 - 252 |<-------------- PW2 --------------->| 254 Figure 2 256 Figure 2 shows another possible scenario, where CE1 is single-homed 257 to PE1, while CE2 remains multi-homed to PE2 and PE4. From the 258 perspective of egress protection for the traffic from CE1 to CE2, 259 this topology is not different than Figure 1. However, for the 260 traffic in the direction from CE2 to CE1, PE1 must anticipate traffic 261 on both PW1 and PW2, and sends it to CE1 over the AC CE1-PE1. 263 3.2. Multi-Segment PW 265 |<--------------- PW1 --------------->| 266 |<----- SEG1 ----->|<----- SEG2 ----->| 268 - TPE1 -------------- SPE1 --------------- TPE2 - 269 / \ 270 / \ 271 CE1 CE2 272 \ / 273 \ / 274 - TPE3 -------------- SPE2 --------------- TPE4 - 276 |<----- SEG3 ----->|<----- SEG4 ----->| 277 |<--------------- PW2 --------------->| 279 Figure 3 281 Figure 3 shows a topology that is similar to Figure 1 but in an MS-PW 282 environment. PW1 and PW2 are both MS-PWs. PW1 is established 283 between TPE1 and TPE2, and switched between segments SEG1 and SEG2 at 284 SPE1. PW2 is established between TPE3 and TPE4, and switched between 285 segments SEG3 and SEG4 at SPE2. CE1 is multi-homed to TPE1 and TPE3. 286 CE2 is multi-homed to TPE2 and TPE4. The transport tunnels of the PW 287 segments are not shown in this figure for clarity. 289 In this document, the following primary and backup roles are assigned 290 for the traffic going from CE1 to CE2: 292 Primary PW: PW1 294 Primary T-PE: TPE2 296 Primary S-PE: SPE1 298 Primary AC: CE2-TPE2 300 Backup PW: PW2 302 Backup T-PE: TPE4 304 Backup S-PE: SPE2 306 Backup AC: CE2-TPE4 308 In this case, an egress AC failure refers to the failure of the AC 309 CE2-TPE2. An egress node failure refers to the failure of TPE2. An 310 switching node failure refers to the failure of SPE1. 312 The backup T-PE, backup PW and backup AC are used for protecting the 313 primary PW against egress AC failure and egress node failure. The 314 backup S-PE and the backup PW are used for protecting the primary PW 315 against switching node failure, as described later in this document. 317 For consistency with the SS-PW scenario, primary T-PEs and a primary 318 S-PEs may simply be referred to as primary PEs in this document, 319 where specifics is not required. Similarly, backup T-PEs and backup 320 S-PEs may be referred to as backup PEs. 322 4. Theory of Operation 324 The fast protection mechanism in this document provides three types 325 of protection for PWs, corresponding to the three types of failures 326 described in Section 1. 328 a. Egress AC protection 330 b. Egress (T-)PE node protection 332 c. S-PE node protection 334 The mechanism assumes that the target CE is multi-homed to a primary 335 PE and a backup PE, and there is a backup PW in the network. In S-PE 336 node protection, it also assumes that there is a backup S-PE on the 337 backup PW. 339 4.1. Local Repair and Protector 341 The mechanism relies on local repair to be performed by routers 342 upstream adjacent to failures. Each of these routers is referred to 343 as a "point of local repair" (PLR). A PLR MUST be able to detect a 344 failure by using a rapid mechanism, such as physical layer failure 345 detection, Bidirectional Failure Detection (BFD) (RFC 5880), etc. In 346 anticipation of the failure, the PLR MUST also pre-establish a bypass 347 PSN tunnel to a "protector", and pre-install a bypass route in the 348 FIB (forwarding information base). The bypass tunnel has the 349 property that it is not affected by the topology changes caused by 350 the failure. Upon detecting the failure, the PLR MUST invoke the 351 bypass route and forward PW traffic to the protector through the 352 bypass tunnel. The protector MUST in turn send the traffic to the 353 target CE, which may or may not be directly attached to the 354 protector. This procedure is referred to as local repair. 356 Different routers may serve as PLR and protector in different 357 scenarios. 359 o In egress AC protection, the PLR is the primary PE that hosts the 360 primary AC, and the protector is the backup PE (Figure 4). 362 |<-------------- PW1 --------------->| 364 - PE1 -------------- P1 ---------------- PE2 - 365 / PLR \ 366 / | \ 367 CE1 bypass| CE2 368 \ | / 369 \ | / 370 - PE3 -------------- P2 ---------------- PE4 - 371 protector 373 |<-------------- PW2 --------------->| 375 Figure 4 377 o In egress PE node protection, the PLR is the penultimate hop 378 router of the transport tunnel of the primary PW, and the 379 protector is the backup PE (Figure 5). 381 |<-------------- PW1 --------------->| 383 - PE1 -------------- P1 ------- P3 ----- PE2 - 384 / PLR \ \ 385 / \ \ 386 CE1 bypass\ CE2 387 \ \ / 388 \ \ / 389 - PE3 -------------- P2 ---------------- PE4 - 390 protector 392 |<-------------- PW2 --------------->| 394 Figure 5 396 o In S-PE node protection, the PLR is the penultimate hop router of 397 the transport tunnel of the primary PW segment, and the protector 398 is the backup S-PE (Figure 6). 400 |<--------------- PW1 --------------->| 401 |<----- SEG1 ----->|<----- SEG2 ----->| 403 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 404 / PLR \ \ 405 / \ \ 406 CE1 bypass\ CE2 407 \ \ / 408 \ \ / 409 - TPE3 --------------- SPE2 -------------- TPE4 - 410 protector 412 |<----- SEG3 ----->|<----- SEG4 ----->| 413 |<--------------- PW2 --------------->| 415 Figure 6 417 In all scenarios, when a PLR forwards traffic through a bypass tunnel 418 to a protector, it keeps the label of the primary PW intact. This 419 obviates the need for the PLR to maintain forwarding state on a 420 per-PW basis, and allows the bypass tunnel to protect multiple 421 primary PWs. 423 This also means that the protector MUST forward the traffic based on 424 a PW label that is assigned by the primary PE, and ensure that the 425 traffic eventually reach the target CE. From the protector's 426 perspective, the PW label is an upstream assigned label (RFC 5331). 427 This is accomplished by learning the PW label from the primary PE, 428 installing proper forwarding state for the PW label in the label 429 space of the primary PE, and performing PW label lookup in this label 430 space. 432 In the above examples, the protectors are backup (S-)PEs. A 433 protector may also be a dedicated router that assumes such a role. 434 In this case, the protector may not be the backup (S-)PE of a given 435 primary PW. During local repair, a PLR still sends traffic to the 436 protector through a bypass tunnel. The protector then sends the 437 traffic to the backup (S-)PE, which finally sends the traffic to the 438 target CE via a backup AC or a backup PW segment. More detail will 439 be described in Section 4.3. 441 A protector MAY protect PWs for one or multiple primary PEs. The 442 protector MUST maintain a separate label space for each primary PE. 443 Likewise, the PWs of a primary PE MAY be protected by multiple 444 protectors, each for a subset of the PWs. In any case, a given 445 primary PW is associated with one and only one pair of {primary PE, 446 protector}. 448 4.2. Context Identifier 450 An IPv4/v6 address is assigned to each ordered pair of {primary PE, 451 protector} to facilitate protection establishment. This address is 452 referred to as a "context identifier". It MUST be globally unique, 453 or unique in the address space of the network where the primary PE 454 and the protector reside. 456 4.2.1. Semantics 458 The semantics of a context identifier is twofold. 460 o It identifies a primary PE and an associated protector. In other 461 words, it identifies a primary PE on a per protector basis. A 462 given primary PE may be protected by multiple protectors, each for 463 a subset of the primary PWs hosted by the primary PE. A distinct 464 context identifier MUST be assigned to the primary PE and each 465 protector. 467 For a primary PW, its ingress PE MUST set up a transport tunnel 468 with destination as the context identifier of the {primary PE, 469 protector}, rather than an IP address of the primary PE. This 470 enables the transport tunnel to follow a path to the primary PE, 471 and also indicates the protector to the PLR(s) along the path. 473 o It indicates the primary PE's label space to a protector. The 474 protector may protect primary PWs for multiple primary PEs. It 475 MUST maintain a separate label space for each primary PE, and 476 associate the PW labels assigned by the primary PE with the label 477 space via the context identifier of the {primary PE, protector}. 478 The association is accomplished as below. 480 When the primary PE advertises the label of a primary PW to the 481 protector, it MUST attach the context identifier to it 482 (Section 4.7). Upon receiving the advertisement, the protector 483 MUST install the PW label in the label space corresponding to the 484 context identifier. 486 A bypass tunnel's destination MUST be set to the context 487 identifier as well, rather than an IP address of the protector. 488 Therefore, the bypass tunnel (either MPLS tunnel label or IP 489 tunnel destination address) can indicate the label space to the 490 protector. All PW packets received on the bypass tunnel MUST be 491 forwarded based on a label lookup in that label space. 493 4.2.2. Advertisement and Path Computation 495 Using a context identifier as destination for both a transport tunnel 496 and a bypass tunnels demands that the context identifier be 497 advertised by IGP (OSPF or ISIS) in the routing domain and/or the TE 498 domain, as an address reachable via both the primary PE and the 499 protector. This imposes the following requirements on path 500 computation for these tunnels. 502 o For the transport tunnel, the ingress PE MUST choose the primary 503 PE as the actual endpoint. 505 o For the bypass tunnel, the PLR MUST choose the protector as the 506 actual endpoint. The path MUST avoid the primary PE, with the 507 exception of an egress AC protection bypass tunnel, where the PLR 508 itself is the primary PE. 510 The detail of how IGP may advertise a context identifier is 511 independent of the protection mechanism, and therefore out of the 512 scope of this document. Some possible approaches are described by 513 [LSP-EGRESS-PROTEC]. The ultimate goal is to allow CSPF (constrained 514 shortest path first), LFA (loop free alternate; RFC 5286) and MRT 515 (maximally redundant trees; [IP-LDP-FRR-MRT]) to compute the expected 516 paths for the transport and bypass tunnels. 518 4.3. Protection Models 520 There are two protection models based on the location and role of a 521 protector. A network MAY use either protection model, or a 522 combination of both. 524 4.3.1. Co-located Protector 526 In this model, the protector is a backup PE that is directly 527 connected to the target CE via a backup AC, or it is a backup S-PE on 528 a backup PW. That is, the protector is co-located with the backup 529 (S-)PE. Examples of this model have been introduced in Figure 4, 530 Figure 5 and Figure 6 in Section 4.1. 532 In egress AC protection and egress PE node protection, when a 533 protector receives traffic from the PLR, it forwards the traffic to 534 the CE via the backup AC. This is shown in Figure 7, where PE2 is 535 the PLR for egress AC failure, P3 is the PLR for PE2 failure, and PE4 536 (the backup PE) is the protector. 538 |<-------------- PW1 --------------->| 540 - PE1 -------------- P1 ------- P3 ----- PE2 ---- 541 / PLR \ PLR \ 542 / \ | \ 543 CE1 bypass\ |bypass CE2 544 \ \ | / 545 \ \ | / 546 - PE3 -------------- P2 ---------------- PE4 ---- 547 protector 549 |<-------------- PW2 --------------->| 551 Figure 7 553 In S-PE node protection, when a protector receives traffic from the 554 PLR, it MUST forward the traffic via the next segment of the backup 555 PW. The T-PE of the backup PW MUST forward the traffic to the CE via 556 a backup AC. This is shown in Figure 8, where P4 is the PLR for SPE1 557 failure, and SPE2 (the backup S-PE) is the protector for SPE1 (the 558 primary S-PE). 560 |<--------------- PW1 --------------->| 561 |<----- SEG1 ----->|<----- SEG2 ----->| 563 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 564 / PLR \ \ 565 / \ \ 566 CE1 bypass\ CE2 567 \ \ / 568 \ \ / 569 - TPE3 --------------- SPE2 -------------- TPE4 - 570 protector 572 |<----- SEG3 ----->|<----- SEG4 ----->| 573 |<--------------- PW2 --------------->| 575 Figure 8 577 In the co-located protector model, the number of context identifiers 578 needed by a network is the number of distinct {primary PE, backup PE} 579 pairs. Therefore, the model is suitable for networks where the 580 number of backup PEs for any given primary PE is relatively small. 582 4.3.2. Centralized Protector 584 In this model, the protector is a dedicated P router or PE router 585 that protects PWs for multiple primary PEs. In egress AC protection 586 and egress PE node protection, the protector MAY or MAY NOT be a 587 backup PE with a direct connection to the target CE. In S-PE node 588 protection, the protector MAY or MAY NOT be a backup S-PE of the 589 backup PW. 591 In egress AC protection and egress PE node protection, when the 592 protector receives traffic from the PLR, if the protector has a 593 direct connection (i.e. backup AC) to the CE, it MUST forward the 594 traffic to the CE via the backup AC, which is similar to Figure 7. 595 Otherwise, it MUST forward the traffic to a backup PE, which MUST 596 then forward the traffic to the CE via a backup AC. This is shown in 597 Figure 9, where the protector receives traffic from P3 or PE2 (the 598 PLRs) and forwards the traffic to PE4 (the backup PE). The protector 599 may be protecting other PWs as well, which is not shown in this 600 figure. 602 |<------------- PW1 --------------->| 604 - PE1 ------------- P1 ------- P3 ----- PE2 -- 605 / PLR \ PLR \ 606 / \ / \ 607 / bypass\ /bypass \ 608 / \ / \ 609 CE1 protector CE2 610 \ \ / 611 \ \ / 612 \ \ / 613 \ \ / 614 - PE3 ------------- P2 -----------------PE4 -- 616 |<------------- PW2 --------------->| 618 Figure 9 620 In S-PE node protection, when the protector receives traffic from the 621 PLR, if the protector is a backup S-PE of the backup PW, it MUST 622 forward the traffic via the next segment of the backup PW, and the 623 T-PE of the backup PW MUST forward the traffic to the CE via a backup 624 AC, which is similar to Figure 8. Otherwise, the protector MUST 625 first forward the traffic to the backup S-PE, which MUST then forward 626 the traffic via the next segment of the backup PW. Finally, the T-PE 627 of the backup PW MUST forward the traffic to the CE via a backup AC. 628 This is shown in Figure 10, where the protector forwards traffic to 629 SPE2 (the backup S-PE). The protector may be protecting other PW 630 segments as well, which is not shown in this figure. 632 |<--------------- PW1 --------------->| 633 |<----- SEG1 ----->|<----- SEG2 ----->| 635 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 636 / PLR \ \ 637 / \ \ 638 / bypass\ \ 639 / \ \ 640 CE1 protector CE2 641 \ \ / 642 \ \ / 643 \ \ / 644 \ \ / 645 - TPE3 --------------- SPE2 -------------- TPE4 - 647 |<----- SEG3 ----->|<----- SEG4 ----->| 648 |<--------------- PW2 --------------->| 650 Figure 10 652 In the centralized protector model, each primary PE MAY only need one 653 protector to protect all of its PWs. Therefore, the number of 654 context identifiers required by a network can be as low as the number 655 of primary PEs. 657 4.4. Transport Tunnel 659 The ingress PE of a primary PW (or PW segment) associates the PW with 660 the primary egress PE through LDP signaling. The ingress PE MUST 661 also associate the transport tunnel with the context identifier of 662 the {primary PE, protector}, by establishing the transport tunnel 663 with the context identifier as destination (Section 4.2.1). This not 664 only ensures that PW traffic be transported by the tunnel to the 665 primary PE, but also facilitates bypass tunnel establishment at 666 PLR(s), as the context identifier implies both the primary PE and the 667 protector. 669 The association between the transport tunnel and the context 670 identifier at the ingress PE MAY be achieved by configuration or an 671 auto-discovery mechanism. In the later case, the ingress PE MAY 672 learn the context identifier from the primary PE, if the primary PE 673 advertises the context identifier as "third party next hop" in an 674 IPv4/v6 Interface_ID TLV (RFC 3471, RFC 3472) in the LDP Label 675 Mapping message of the primary PW. 677 4.5. Bypass Tunnel 679 A PLR may protect multiple PWs associated with one or multiple pairs 680 of {primary PE, protector}. The PLR MUST establish a bypass tunnel 681 to each protector for each distinct context identifier associated 682 with the protector. The destination of the bypass tunnel MUST be the 683 context identifier (Section 4.2.1). The PLR may learn the context 684 identifier from the destination address from the transport tunnel 685 that traverses it. 687 For examples, in Figure 7 and Figure 9, a bypass tunnel is 688 established from PE2 (PLR for egress AC failure) to the protector, 689 and another bypass tunnel is established from P3 (PLR for egress node 690 failure) to the protector. In Figure 8 and Figure 10, a bypass 691 tunnel is established from P4 (PLR for switching node failure) to the 692 protector. 694 During local repair, the PLR forwards traffic to the protector 695 through the bypass tunnel with PW label intact. This normally 696 involves pushing a label to the label stack, if the bypass tunnel is 697 an MPLS tunnel, or pushing an IP header to the packets, if the bypass 698 tunnel is an IP tunnel. The protector MUST in turn forward the 699 traffic based on the PW label, i.e. an upstream assigned label. To 700 perform such forwarding, the protector MUST rely on the bypass tunnel 701 as a context to determine the primary PE's label space. If the 702 bypass tunnel is an MPLS tunnel, the protector MUST assign a non- 703 reserved label for the bypass tunnel, and use this label as the 704 context. If the bypass tunnel is an IP tunnel, the protector can 705 decide the context based on the context identifier carried as 706 destination address in the IP header. 708 A bypass tunnel MUST have the property that it is not affected by the 709 topology change caused by the failure that it protects against. 710 Therefore, it can be used to transmit traffic during the convergence 711 of control plane protocols and the delay of global repair. It will 712 remain effective, until the traffic is moved to another fully 713 functional egress AC, PW or transport tunnel. 715 4.6. Forwarding State on Protector 717 A protector MUST learn PW labels from all the primary PEs that it 718 protects (Section 4.7), and maintain the PW labels in a separate 719 label space for each primary PE. In the control plane, a primary 720 PE's label space is identified by the context identifier of the 721 {primary PE, protector}. In the forwarding plane, the label space is 722 indicated by bypass tunnels that are destined for the context 723 identifier. 725 4.6.1. Co-located Protector 727 In Figure 11, PE4 is a co-located protector that protects PW1 against 728 egress AC failure and egress node failure. It maintains a label 729 space for PE2, which is identified by the context identifier of {PE2, 730 PE4}. It learns PW1's label from PE2, and installs an forwarding 731 entry for the label in that label space. The nexthop of the 732 forwarding entry indicates a label pop with outgoing interface 733 pointing to the backup AC CE2-PE4. 735 |<-------------- PW1 --------------->| 737 - PE1 -------------- P1 ------- P3 ----- PE2 ---- 738 / PLR \ PLR \ 739 / \ | \ 740 CE1 bypass\ |bypass CE2 741 \ \ | / 742 \ \ | / 743 - PE3 -------------- P2 ---------------- PE4 ---- 744 protector 746 |<-------------- PW2 --------------->| 748 Figure 11 750 In Figure 12, SPE2 is a co-located protector that protects PW1 751 against switching node failure. It maintains a label space for SPE1, 752 which is identified by the context identifier of {SPE1, SPE2}. It 753 learns SEG1's label from SPE1, and installs a forwarding entry in the 754 label space. The nexthop of the forwarding entry indicates a label 755 swap to SEG4's label. 757 |<--------------- PW1 --------------->| 758 |<----- SEG1 ----->|<----- SEG2 ----->| 760 - TPE1 ----- P4 ----- SPE1 --------------- TPE2 - 761 / PLR \ \ 762 / \ \ 763 CE1 bypass\ CE2 764 \ \ / 765 \ \ / 766 - TPE3 --------------- SPE2 --------------- TPE4 - 767 protector 769 |<----- SEG3 ----->|<----- SEG4 ----->| 770 |<--------------- PW2 --------------->| 772 Figure 12 774 4.6.2. Centralized Protector 776 In the centralized protector model, for each primary PW of which the 777 protector is not a backup (S-)PE, the protector MUST also learn the 778 label of the backup PW from the backup (S-)PE (Section 4.8). This is 779 the backup (S-)PE that the protector will forward traffic to. The 780 protector MUST install a forwarding entry with label swap from the 781 primary PW's label to the backup PW's label. 783 In Figure 13, the protector is a centralized protector that protects 784 PW1 against egress AC failure and egress node failure. It maintains 785 a label space for PE2, which is identified by the context identifier 786 of {PE2, protector}. It learns PW1's label from PE2, and PW2's label 787 from PE4. It installs a forwarding entry for PW1's label in the 788 label space. The nexthop of the forwarding entry indicates a label 789 swap to PW2's label. 791 |<------------- PW1 --------------->| 793 - PE1 ------------- P1 ------- P3 ----- PE2 -- 794 / PLR \ PLR \ 795 / \ / \ 796 / bypass\ /bypass \ 797 / \ / \ 798 CE1 protector CE2 799 \ \ / 800 \ \ / 801 \ \ / 802 \ \ / 803 - PE3 ------------- P2 -----------------PE4 -- 805 |<------------- PW2 --------------->| 807 Figure 13 809 In Figure 14, the protector is a centralized protector that protects 810 the PW segment SEG1 of PW1 against switching node failure of SPE1. 811 It maintains a label space for SPE1, which is identified by the 812 context identifier of {SPE1, protector}. It learns SEG1's label from 813 SPE1, and learns SEG3's label from SPE2. It installs a forwarding 814 entry for SEG1's label in the label space. The nexthop of the 815 forwarding entry indicates a label swap to SEG3's label. 817 |<--------------- PW1 --------------->| 818 |<----- SEG1 ----->|<----- SEG2 ----->| 820 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 821 / PLR \ \ 822 / \ \ 823 / bypass\ \ 824 / \ \ 825 CE1 protector CE2 826 \ \ / 827 \ \ / 828 \ \ / 829 \ \ / 830 - TPE3 --------------- SPE2 -------------- TPE4 - 832 |<----- SEG3 ----->|<----- SEG4 ----->| 833 |<--------------- PW2 --------------->| 835 Figure 14 837 4.7. PW Label Distribution from Primary PE to Protector 839 A primary PE SHOULD distribute the label of each primary PW to the 840 protector that protects the PW. To achieve this, the primary PE MUST 841 establish a targeted LDP session with the protector. For each 842 primary PW, the primary PE SHOULD advertise over that session a 843 Protection FEC Element via Label Mapping message. The Protection FEC 844 Element is a new LDP FEC, and its encoding is described below. The 845 PW's label is encoded in the Upstream-Assigned Label TLV defined in 846 (RFC 6389). The combination of the Protection FEC Element and the PW 847 label represent the primary PE's forwarding state for the PW. The 848 Label Mapping message SHOULD also carry an IPv4/v6 Interface_ID TLV 849 (RFC 6389, RFC 3471) encoded with the context identifier of the 850 {primary PE, protector}. 852 The protector that receives this Label Mapping message SHOULD install 853 a forwarding entry for the PW label in the label space identified by 854 the context identifier. The nexthop of the forwarding entry SHOULD 855 allow packets to be sent towards the target CE via a backup AC or a 856 backup (S-)PE, depending on the protection model and SS-PW or MS-PW 857 scenario, as described in previous sections. 859 The Protection FEC Element has type 0x83. It is defined as below: 861 0 1 2 3 862 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Type(0x83) | Reserved | Encoding Type | Length | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | | 867 | | 868 ~ PW Information ~ 869 | | 870 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 Figure 15 876 - Encoding Type 878 Type of format that PW Information field is encoded. 880 - Length 882 Length of PW Information field in octets. 884 - PW Information 886 Field of variable length that specifies a PW 888 For Encoding Type, 1 is defined for the PWid FEC Element format, and 889 2 is defined for the Generalized PWid FEC Element format (RFC 4447). 891 4.7.1. Protection FEC Element Encoding for PWid 893 0 1 2 3 894 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 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Type(0x83) | Reserved | Enc Type(1) | Length(16) | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Ingress PE Address | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Egress PE Address | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Group ID | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | PW ID | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 |C| PW Type | Reserved | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 Figure 16 911 - Ingress PE Address 913 IP address of the ingress PE of PW. 915 - Egress PE Address 917 IP address of the egress PE of PW. 919 - Group ID 921 An arbitrary 32-bit value that represents a group of PWs and that 922 is used to create groups in the PW space. 924 - PW ID 926 A non-zero 32-bit connection ID that, together with the PW Type 927 field, identifies a particular PW. 929 - Control word bit (C) 931 A bit that flags the presence of a control word on this PW. If C 932 = 1, control word is present; If C = 0, control word is not 933 present. 935 - PW Type 936 A 15-bit quantity that represents the type of PW. 938 4.7.2. Protection FEC Element Encoding for Generalized PWid 940 0 1 2 3 941 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 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Type(0x83) | Reserved | Enc Type(2) | Length | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Ingress PE Address | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Egress PE Address | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 |C| PW Type | Reserved | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | AGI Type | Length | Value | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 ~ AGI Value (contd.) ~ 954 | | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | AII Type | Length | Value | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 ~ SAII Value (contd.) ~ 959 | | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | AII Type | Length | Value | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 ~ TAII Value (contd.) ~ 964 | | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 Figure 17 969 - Ingress PE Address 971 IP address of the ingress PE of PW. 973 - Egress PE Address 975 IP address of the egress PE of PW. 977 - Control word bit (C) 979 A bit that flags the presence of a control word on this PW. If C 980 = 1, control word is present; If C = 0, control word is not 981 present. 983 - PW Type 985 A 15-bit quantity that represents the type of PW. 987 - AGI Type, Length, Value, AGI Value 989 Attachment Group Identifier of PW. 991 - SAII Type, Length, Value, SAII Value 993 Source Attachment Individual Identifier of PW. 995 - TAII Type, Length, Value, TAII Value 997 Target Attachment Individual Identifier of PW. 999 4.8. PW Label Distribution from Backup PE to Protector 1001 In the centralized protector model, a protector may not be a backup 1002 (S-)PE for some primary PWs. For these PWs, in addition to learning 1003 PW labels from the primary PEs, the protector SHOULD also learn the 1004 labels of backup PWs and backup PW segments from backup (S-)PEs. 1006 To achieve this, each backup (S-)PE MUST establish a targeted LDP 1007 session with the protector. The backup PE SHOULD advertise over that 1008 session a Protection FEC Element for the backup PW via Label Mapping 1009 message. The content of this Protection FEC Element MUST match the 1010 Protection FEC Element that the primary PE advertises to the 1011 protector (section 4.8). The Label Mapping message SHOULD also 1012 include a Generic Label TLV encoded with the backup PW's label. The 1013 context identifier SHOULD NOT be encoded in Interface_ID TLV in this 1014 message. The combination of the Protection FEC Element and the 1015 backup PW's label combined represent the backup PE's forwarding state 1016 for the backup PW. 1018 The protector that receives this Label Mapping message SHOULD 1019 associate the backup PW with the primary PW, based on the common 1020 Protection FEC Element. It SHOULD distinguish between the message 1021 from the primary PE and the message from the backup PE based on the 1022 presence and absence of context identifier in Interface_ID TLV. It 1023 SHOULD install a forwarding entry for the primary PW's label in the 1024 label space identified by the context identifier. The nexthop of the 1025 forwarding entry SHOULD indicate a label swap to the backup PW's 1026 label. 1028 4.9. Revertive Behavior 1030 After local repair takes effect at a PLR, there are three strategies 1031 for restoring traffic to a fully working PW. 1033 o Global revertive mode 1035 If the ingress CE is multi-homed (Figure 1), it MAY switch the 1036 traffic to a backup AC which is bound to a backup PW. Or, if the 1037 ingress PE hosts a backup PW (Figure 2), it MAY switch the traffic 1038 to the backup PW. These procedures are referred to as global 1039 repairs. Possible triggers of a global repair include PW status, 1040 OAM, and BFD. 1042 o Control plane revertive mode 1044 In egress PE node protection and S-PE node protection, it is 1045 possible that the failure is limited to the link between the PLR 1046 and the primary (S-)PE, while the primary (S-)PE is still up. In 1047 this case, if the PLR or an upstream router along the transport 1048 tunnel can reach the primary (S-)PE via an alternative path, the 1049 transport tunnel MAY be rerouted around the failed link, so that 1050 it can continue to carry the PW traffic to the primary (S-)PE. 1051 This procedure is driven by control plane convergence, and is 1052 referred to as control plane repair. 1054 o Local revertive mode 1056 The PLR MAY move traffic back to the primary PW, after the failure 1057 is resolved. In egress AC protection, upon detecting that the 1058 primary AC is restored, the PLR MAY start forwarding traffic via 1059 the AC again. Likewise, in egress PE node protection and S-PE 1060 node protection, upon detecting that the primary PE is restored, 1061 the PLR MAY re-establish the primary transport tunnel through the 1062 primary PE, and move the traffic back to the tunnel. These 1063 procedures are referred to as local reversion. 1065 The fast protection mechanism in this document SHOULD always be used 1066 in tandem with the globally revertive mode. Particularly in the case 1067 of egress (S-)PE failure, if the ingress PE or the protector loses 1068 communication with the (S-)PE for an extensive period of time, the 1069 LDP session between them may go down. Consequently, the ingress PE 1070 may bring down the primary PW, or the protector may delete the 1071 forwarding entry of the primary PW label from the label space. In 1072 either case, the service will be disrupted. In other words, although 1073 the fast protection can temporarily repair traffic, control plane 1074 states may eventually time out if the failure persists. Therefore, 1075 it is recommended that the global revertive mode SHOULD always be 1076 established in advance, so that traffic can be moved to a fully 1077 working backup PW shortly after the local repair. 1079 The control plane revertive mode may happen as part of the 1080 convergence of control plane protocols. However, it is only 1081 applicable to some specific topologies. 1083 The local revertive mode is optional. In the circumstances where the 1084 failure is caused by resource flapping, local reversion MAY be 1085 dampened to limit potential disruptions. Local revertive mode MAY be 1086 disabled completely by configuration. 1088 5. IANA Considerations 1090 IANA maintains a registry of LDP FECs at the registry "Label 1091 Distribution Protocol" in the sub-registry called "Forwarding 1092 Equivalence Class (FEC) Type Name Space". 1094 This document defines a new LDP Protection FEC Element in 1095 Section 4.7. IANA has assigned the type value 0x83 to it. 1097 6. Security Considerations 1099 The security considerations discussed in RFC 5036, RFC 5331, RFC 1100 3209, and RFC 4090 apply to this document. 1102 7. Acknowledgements 1104 This document leverages work done by Hannes Gredler, Yakov Rekhter, 1105 Minto Jeyananth and several others on MPLS edge protection. Thanks 1106 to Nischal Sheth, Bhupesh Kothari, and Kevin Wang for their 1107 contribution. Thanks to Yakov Rekhter and John E Drake for reviewing 1108 the document. 1110 8. References 1112 8.1. Normative References 1114 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1115 Edge (PWE3) Architecture", RFC 3985, March 2005. 1117 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 1118 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 1119 October 2009. 1121 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1122 Heron, "Pseudowire Setup and Maintenance Using the Label 1123 Distribution Protocol (LDP)", RFC 4447, April 2006. 1125 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1126 Label Assignment and Context-Specific Label Space", 1127 RFC 5331, August 2008. 1129 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1130 Specification", RFC 5036, October 2007. 1132 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1133 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1134 Functional Specification", RFC 2205, September 1997. 1136 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1137 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1138 Tunnels", RFC 3209, December 2001. 1140 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 1141 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1142 May 2005. 1144 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 1145 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 1147 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1148 RFC 5714, January 2010. 1150 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1151 (GMPLS) Signaling Functional Description", RFC 3471, 1152 January 2003. 1154 [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- 1155 Protocol Label Switching (GMPLS) Signaling Constraint- 1156 based Routed Label Distribution Protocol (CR-LDP) 1157 Extensions", RFC 3472, January 2003. 1159 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1160 Label Switching Architecture", RFC 3031, January 2001. 1162 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1164 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1165 (BFD)", RFC 5880, June 2010. 1167 [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label 1168 Assignment for LDP", RFC 6389, November 2011. 1170 [LSP-EGRESS-PROTEC] 1171 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1172 Egress Fast Protection", 1173 draft-minto-rsvp-lsp-egress-fast-protection (work in 1174 progress), 2012. 1176 [IP-LDP-FRR-MRT] 1177 Atlas, A. and R. Kebler, "An Architecture for IP/LDP Fast- 1178 Reroute Using Maximally Redundant Trees", 1179 draft-ietf-rtgwg-mrt-frr-architecture (work in progress), 1180 2011. 1182 8.2. Informative References 1184 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 1185 Networks", RFC 5920, July 2010. 1187 Authors' Addresses 1189 Yimin Shen (editor) 1190 Juniper Networks 1191 10 Technology Park Drive 1192 Westford, MA 01886 1193 USA 1195 Phone: +1 9785890722 1196 Email: yshen@juniper.net 1198 Rahul Aggarwal 1199 Arktan, Inc 1201 Email: raggarwa_1@yahoo.com 1203 Wim Henderickx 1204 Alcatel-Lucent 1205 Copernicuslaan 50 1206 2018 Antwerp 1207 Belgium 1209 Email: wim.henderickx@alcatel-lucent.be