idnits 2.17.1 draft-ietf-pals-endpoint-fast-protection-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 27, 2016) is 3012 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 1280, but no explicit reference was found in the text == Unused Reference: 'RFC5659' is defined on line 1285, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 1301, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 1310, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1315, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 1345, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 1350, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 1375, 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 (~~), 9 warnings (==), 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: July 30, 2016 Arktan, Inc 6 Wim Henderickx 7 Alcatel-Lucent 8 Yuanlong Jiang 9 Huawei Technologies 10 January 27, 2016 12 PW Endpoint Fast Failure Protection 13 draft-ietf-pals-endpoint-fast-protection-02 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 July 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 . . . . . . . . . . . . . . . . . . . . . . 18 80 4.7. Forwarding State on Protector . . . . . . . . . . . . . . 19 81 4.7.1. Examples of Co-located Protector . . . . . . . . . . 19 82 4.7.2. Examples of Centralized Protector . . . . . . . . . . 20 83 5. Revertive Behavior . . . . . . . . . . . . . . . . . . . . . 20 84 6. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 22 85 6.1. Egress Protection Capability TLV . . . . . . . . . . . . 22 86 6.2. PW Label Distribution from Primary PE to Protector . . . 24 87 6.3. PW Label Distribution from Backup PE to Protector . . . . 24 88 6.4. Protection FEC Element TLV . . . . . . . . . . . . . . . 24 89 6.4.1. Encoding Format for PWid . . . . . . . . . . . . . . 25 90 6.4.2. Encoding Format for Generalized PWid . . . . . . . . 27 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 28 96 10.2. Informative References . . . . . . . . . . . . . . . . . 30 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 99 1. Introduction 101 Per RFC3985, RFC4447 and 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 layer-2 service against network failures, it 113 is necessary to protect every link and node along the entire data 114 path. 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. The bypass path has the property that it can 122 guide traffic around the failure, while remaining unaffected by the 123 topology changes resulting from the failure. When the failure 124 occurs, the router can invoke the bypass path to achieve fast 125 restoration for the service. 127 Today, fast protection against ingress AC failure and ingress (T-)PE 128 failure can be achievable by using a multi-homed CE and redundant 129 ACs, such as multi-chassis link aggregation group (MC-LAG). Fast 130 protection against failure of intermediate router of transport tunnel 131 can be achievable through RSVP fast-reroute [RFC4090] or IP/LDP fast- 132 reroute [RFC5714, RFC5286]. However, there is a lack of equivalent 133 mechanism against egress AC failure, egress (T-)PE failure, and S-PE 134 failure. For these failures, service restoration has to rely on 135 global repair or control plane repair. Global repair normally 136 involves ingress CE or ingress (T-)PE switching traffic to another 137 fully functional path, based on remote failure detection via PW 138 status notification, end-to-end OAM, etc. Control plane repair 139 relies on control protocols to converge on the topology changes due 140 to a failure. Compared to local repair, these mechanisms are 141 relatively slow in reacting to a failure and restoring traffic. 143 This document is intended to serve the above need. It specifies a 144 fast protection mechanism based on local repair to protect PWs 145 against the following endpoint failures. 147 a. Egress AC failure. 149 b. Egress PE failure: Link or node failure of an egress PE of an SS- 150 PW, or a T-PE of an MS-PW. 152 c. Switching PE (S-PE) failure: Link or node failure of an S-PE of 153 an MS-PW. 155 The mechanism is applicable to LDP signaled PWs. It is relevant to 156 networks with redundant PWs and multi-homed CEs. It is designed on 157 the basis of MPLS upstream label assignment and context-specific 158 label switching [RFC5331]. Fast protection refers to its ability to 159 restore traffic in the order of tens of milliseconds. Compared with 160 global repair and control plane repair, this mechanism can provide 161 faster service restoration. However, it is intended to complement 162 those mechanisms, rather than replacing them in any fashion. 164 2. Specification of Requirements 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC2119. 170 3. Reference Models for Egress Endpoint Failures 172 This document refers to the following topologies to describe egress 173 endpoint failures and protection procedures. 175 3.1. Single-Segment PW 177 |<-------------- PW1 --------------->| 179 - PE1 -------------- P1 ---------------- PE2 - 180 / \ 181 / \ 182 CE1 CE2 183 \ / 184 \ / 185 - PE3 -------------- P2 ---------------- PE4 - 187 |<-------------- PW2 --------------->| 189 Figure 1 191 In Figure 1, the IP/MPLS network consists of PE and P routers. It 192 provides an emulation of a layer-2 service between CE1 and CE2. Each 193 CE is multi-homed via two ACs to two PEs. This forms two divergent 194 paths between the CEs. The first path uses PW1 between PE1 and PE2, 195 and the second path uses PW2 between PE3 and PE4. The transport 196 tunnels of the PWs and other links between the routers are not shown 197 in this figure for clarity. 199 In general, a CE may operate the ACs in two modes when sending 200 traffic to the remote CE, i.e. active-standby mode and active-active 201 mode. 203 o In the active-standby mode, the CE chooses one AC as active AC and 204 the corresponding path as active path, and uses the other AC as 205 standby AC and the corresponding path as standby path. The CE 206 only sends traffic on the active AC as long as the active path is 207 operational. The CE will only send traffic on the standby AC 208 after it detects a failure of the active path. Note that the CE 209 may receive traffic on the active or standby AC, depending on 210 whether the remote CE chooses the same active path for the traffic 211 of the reverse direction. In this document, even if both CEs 212 choose the same active path, each CE should still anticipate 213 receiving traffic on a standby AC, because the traffic may be 214 redirected to the standby path by the fast protection mechanism. 216 o In the active-active mode, the CE treats both ACs and their 217 corresponding paths as active, and sends traffic on both ACs in a 218 load balance fashion. In the reverse direction, the CE may 219 receive traffic on both ACs. 221 For either mode, when considering the traffic flowing in a given 222 direction over an active path, this document views the ACs, PEs and 223 PWs to serve primary or backup roles. In particular, the ACs, PEs 224 and PW along this active path are primary, while those along the 225 other path are backup. Note that in the active-active mode, the 226 backup path is an active path by itself, carrying its own share of 227 traffic while protecting the other active path. 229 For Figure 1, the following roles are assumed for the traffic going 230 from CE1 to CE2 via PW1. 232 Primary ingress AC: CE1-PE1 234 Primary ingress PE: PE1 236 Primary PW: PW1 238 Primary egress PE: PE2 239 Primary egress AC: PE2-CE2 241 Backup ingress AC: CE1-PE3 243 Backup ingress PE: PE3 245 Backup PW: PW2 247 Backup egress PE: PE4 249 Backup egress AC: PE4-CE2 251 Based on this schema, this document describes egress endpoint 252 failures and the fast protection mechanism on the per-active-path and 253 per-direction basis. In this case, an egress AC failure refers to 254 the failure of the AC PE2-CE2, and an egress node failure refers to 255 the failure of PE2. The ultimate goal is that when a failure occurs, 256 the traffic should be locally repaired, so that it can eventually 257 reach CE2 via the backup egress PE (PE4) and the backup egress AC 258 (PE4-CE2). 260 Subsequent to the local repair, either the current active path should 261 heal after control plane converges on the new topology, or the 262 ingress CE should switch traffic from the primary path to the backup 263 path, depending on the failure scenario. In the latter case, the 264 ingress CE may perform the path switchover triggered by end-to-end 265 OAM (in-band or out-band), PW status notification, CE-PE control 266 protocols (e.g. LACP), etc. In the active-standby mode, this will 267 promote the standby path to new active path. In the active-active 268 mode, it will make the other active path carry all the traffic 269 between the two CEs. In any case, this phase of restoration falls 270 into the control plane repair and global repair category, and hence 271 is out of the scope of this document. The purpose of the fast 272 protection mechanism in this document is to reduce traffic loss 273 before this phase of restoration takes place. 275 Note that an egress endpoint failure of the traffic of a given 276 direction may be detected by the egress CE as an ingress endpoint 277 failure for the traffic of the reverse direction, except when the 278 failure is on a link of the primary egress PE within the PSN, or when 279 the traffic of the reverse direction takes a different active path. 280 If the CE can detect the failure, it may protect the traffic of the 281 reverse direction by switching it to the backup path. However, this 282 is categorized as ingress endpoint failure protection, and hence is 283 not handled by this mechanism. 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 not much different than 289 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 flows 405 within the PW are sensitive to packet misordering. Therefore, the 406 mechanism assumes 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. 410 It is also assumed that the mechanism SHOULD be used in conjunction 411 with global repair and control plane repair, in such a manner that 412 the mechanism temporarily repairs a failed path by using a bypass 413 tunnel, and global repair and control plane repair eventually move 414 traffic to a fully functional path. 416 4.2. Local Repair and Protector 418 The fast protection ability of the mechanism comes from local repair 419 performed by routers upstream adjacent to failures. Each of these 420 routers is referred to as a "point of local repair" (PLR). A PLR 421 MUST be able to detect a failure by using a rapid mechanism, such as 422 physical layer failure detection, Bidirectional Failure Detection 423 (BFD) [RFC5880], etc. In anticipation of the failure, the PLR MUST 424 also pre-establish a bypass tunnel to a "protector", and pre-install 425 a bypass route in the data plane. The bypass tunnel MUST have the 426 property that it will not be affected by topology changes due to the 427 failure. Upon detecting the failure, the PLR invokes the bypass 428 route in the data plane, and reroutes PW traffic to the protector 429 through the bypass tunnel. The protector in turn sends the traffic 430 to the target CE. This procedure is referred to as local repair. 432 Different routers may serve as PLR and protector in different 433 scenarios. 435 o In egress AC protection, the PLR is the primary PE, and the 436 protector is the backup PE (Figure 4). 438 |<-------------- PW1 --------------->| 440 - PE1 -------------- P1 ---------------- PE2 - 441 / PLR \ 442 / | \ 443 CE1 bypass| CE2 444 \ | / 445 \ | / 446 - PE3 -------------- P2 ---------------- PE4 - 447 protector 449 |<-------------- PW2 --------------->| 451 Figure 4 453 o In egress PE node protection, the PLR is the penultimate hop 454 router of the transport tunnel of the primary PW, and the 455 protector is the backup PE (Figure 5). 457 |<-------------- PW1 --------------->| 459 - PE1 -------------- P1 ------- P3 ----- PE2 - 460 / PLR \ \ 461 / \ \ 462 CE1 bypass\ CE2 463 \ \ / 464 \ \ / 465 - PE3 -------------- P2 ---------------- PE4 - 466 protector 468 |<-------------- PW2 --------------->| 470 Figure 5 472 o In S-PE node protection, the PLR is the penultimate hop router of 473 the transport tunnel of the primary PW segment, and the protector 474 is the backup S-PE (Figure 6). 476 |<--------------- PW1 --------------->| 477 |<----- SEG1 ----->|<----- SEG2 ----->| 479 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 480 / PLR \ \ 481 / \ \ 482 CE1 bypass\ CE2 483 \ \ / 484 \ \ / 485 - TPE3 --------------- SPE2 -------------- TPE4 - 486 protector 488 |<----- SEG3 ----->|<----- SEG4 ----->| 489 |<--------------- PW2 --------------->| 491 Figure 6 493 In egress AC protection, a PLR realizes its role based on 494 configuration of a "context identifier" introduced in this document 495 (Section 4.3). The PLR establishes a bypass tunnel to the protector 496 in the same fashion as a normal PSN tunnel. 498 In egress PE and S-PE node protection, a PLR is a transit router on 499 the transport tunnel, and it normally does not have knowledge of the 500 PW(s) carried by the transport tunnel. In this document, the PLR 501 simply computes and establishes a node protection bypass tunnel in 502 the same fashion as the normal IP/MPLS node protection, except that 503 with the notion of context identifier, the bypass tunnel will be 504 established from the PLR to the protector (Section 4.6). Conversely, 505 when the router is no longer a PLR for egress PE or S-PE node 506 protection due to a change in network topology or the transport 507 tunnel's path, the router should revert to the role of regular 508 transit router, including PLR for normal IP/MPLS link or node 509 protection. 511 In local repair, a PLR simply switches all the traffic received on 512 the transport tunnel to the bypass tunnel. This requires that the 513 protector given by the bypass tunnel MUST be intended for all the PWs 514 carried by the transport tunnel. This is achieved by the ingress PE 515 associating a PW with the specific pair of {primary PE, protector} 516 and mapping the PW to a transport tunnel destined for the same 517 {primary PE, protector}. The ingress PE MAY map multiple PWs to the 518 transport tunnel, if they share the {primary PE, protector} in 519 common. 521 In local repair, the PLR keeps PW label intact in packets. This 522 obviates the need for the PLR to maintain bypass routes on a per-PW 523 basis, and allows bypass tunnel sharing between PWs. On the other 524 hand, this imposes a requirement on the protector that it MUST be 525 able to forward the packets based on a PW label that is assigned by 526 the primary PE, and ensure that the traffic MUST eventually reach the 527 target CE. From the protector's perspective, this PW label is an 528 upstream assigned label [RFC5331]. To achieve this, the protector 529 MUST learn the PW label from the primary PE prior to the failure, and 530 install proper forwarding state for the PW label in a dedicated label 531 space associated with the primary PE. During local repair, the 532 protector MUST perform PW label lookup in this label space. 534 The previous examples have shown the scenarios where the protectors 535 are backup (T/S-)PEs. It is also possible that a protector is a 536 dedicated router to serve such role, separate from the backup (T/ 537 S-)PE. During local repair, the PLR still reroutes traffic to the 538 protector through a bypass tunnel. The protector then forwards the 539 traffic to the backup (T/S-)PE, which further forwards the traffic to 540 the target CE via a backup AC or a backup PW segment. More detail 541 will be described in Section 4.4. 543 4.3. Context Identifier 545 A protector may protect multiple primary PEs. The protector MUST 546 maintain a separate label space for each primary PE. Likewise, the 547 PWs terminated on a primary PE may be protected by multiple 548 protectors, each for a subset of the PWs. In any case, a given PW 549 MUST be associated with one and only one pair of {primary PE, 550 protector}. 552 This document introduces the notion of "context identifier" to 553 facilitate protection establishment. A context identifier is an 554 IPv4/v6 address assigned to an ordered pair of {primary PE, 555 protector}. The address MUST be globally unique, or unique in the 556 address space of the network where the primary PE and the protector 557 reside. 559 4.3.1. Semantics 561 The semantics of a context identifier is twofold. 563 o A context identifier identifies a primary PE and an associated 564 protector. It represents the primary PE as PW destination on a 565 per protector basis. A given primary PE may be protected by 566 multiple protectors, each for a subset of the PWs terminated on 567 the primary PE. A distinct context identifier MUST be assigned to 568 the primary PE and each protector. 570 The ingress PE of a PW learns the context identifier of the PW's 571 {primary PE, protector} from the primary PE via Interface_ID TLV 573 [RFC3471, RFC3472] in the LDP Label Mapping message of the PW. 574 The ingress PE then sets up or resolves a transport tunnel with 575 the context identifier, rather than a private IP address of the 576 primary PE, as destination. This destination not only makes the 577 transport tunnel reach the primary PE, but also conveys the 578 identity of the protector to the PLR, which MUST use the context 579 identifier as destination for the bypass tunnel to the protector. 580 The ingress PE MUST map only the PWs terminated by the exact 581 primary PE and protected by the exact protector to the transport 582 tunnel. 584 o A context identifier indicates the primary PE's label space on the 585 protector. The protector may protect PWs for multiple primary 586 PEs. For each primary PE, it MUST maintain a separate label space 587 to store the PW labels assigned by that primary PE. It associates 588 a PW label with a label space via the context identifier of the 589 {primary PE, protector}, as below. 591 In addition to the normal LDP PW signaling, the primary PE MUST 592 have a targeted LDP session with the protector, and advertise PW 593 labels to the protector via LDP Label Mapping messages 594 (Section 6). The primary PE MUST attach the context identifier to 595 each message. Upon receiving the message, the protector MUST 596 install the advertised PW label in the label space identified by 597 the context identifier. 599 When a PLR sets up or resolves a bypass tunnel to the protector, 600 it MUST use the context identifier rather than a private IP 601 address of the protector as destination. The protector MUST use 602 the bypass tunnel, either the MPLS tunnel label or IP tunnel 603 destination address, as the pointer to the corresponding label 604 space. The protector MUST forwards PW packets received on the 605 bypass tunnel based on label lookup in that label space. 607 4.3.2. IGP Advertisement and Path Computation 609 Using a context identifier as destination for both transport tunnel 610 and bypass tunnel requires coordination between the primary PE and 611 the protector in IGP advertisement of the context identifier in 612 routing domain and TE domain. The context identifier should be 613 advertised in such a way that all the routers on the tunnels MUST be 614 able to independently reach the following common view of paths. 616 o The transport tunnel MUST have the primary PE as path endpoint. 618 o The bypass tunnel MUST have the protector as path endpoint. In 619 egress PE and S-PE node protection, the path MUST avoid the 620 primary PE. 622 There are generally two categories of approaches to achieve the 623 above. 625 o The first category does not require an ingress PE or a PLR to have 626 knowledge of the PW egress endpoint protection schema. It does 627 not require any IGP extension for context identifier 628 advertisement. A context identifier is advertised by the primary 629 PE and the protector as an address reachable via both routers. 630 The ingress PE and the PLR can compute paths by using a normal 631 method, such as Dijkstra, CSPF (constrained shortest path first), 632 LFA [RFC5286] and MRT [IP-LDP-FRR-MRT]. One example is to 633 advertise a context identifier as a virtual proxy node connected 634 to the primary PE and the protector, with the link between the 635 proxy node and the primary PE having a more preferable IGP and TE 636 metric than the link between the proxy node and the protector. 637 The transport tunnel will follow the shortest path or a TE path to 638 the primary PE, and be terminated by the primary PE. The PLR will 639 no longer view itself as a penultimate hop of the transport 640 tunnel, but rather two hops away from the proxy node, via the 641 primary PE. Hence, a node protection bypass tunnel will be 642 available via the protector to the proxy node, but actually be 643 terminated by the protector. 645 o The second category require a PLR to have knowledge of the PW 646 egress endpoint protection schema. The primary PE advertises the 647 context identifier as a regular IP address, while the protector 648 advertises it by using an explicit "context identifier" object, 649 which MUST be understood by the PLR. The "context identifier" 650 object requires an IGP extension. In both the routing domain and 651 the TE domain, the context identifier is only reachable via the 652 primary PE. This ensures that the transport tunnel is terminated 653 by the primary PE. The PLR views itself as the penultimate hop of 654 the transport tunnel, and based on the IGP "context identifier" 655 object, it establishes or resolves a bypass tunnel to the 656 advertiser (i.e. the protector), while avoiding the primary PE. 658 The mechanism in this document intends to be flexible on the approach 659 used by a network, as long as it satisfies the above requirements for 660 transport tunnel path and bypass tunnel path. For any approach, the 661 coordination between a primary PE and a protector can be achieved by 662 configuration. 664 4.4. Protection Models 666 There are two protection models based on the location of a protector. 667 A network MAY use either model or both. 669 4.4.1. Co-located Protector 671 In this model, the protector is a backup PE that is directly 672 connected to the target CE via a backup AC, or it is a backup S-PE on 673 a backup PW. That is, the protector is co-located with the backup 674 (S-)PE. Examples of this model have been shown in Figure 4, Figure 5 675 and Figure 6 in Section 4.2. 677 In egress AC protection and egress PE node protection, when a 678 protector receives traffic from the PLR, it forwards the traffic to 679 the CE via the backup AC. This is shown in Figure 7, where PE2 is 680 the PLR for egress AC failure, P3 is the PLR for PE2 failure, and PE4 681 (the backup PE) is the protector. 683 |<-------------- PW1 --------------->| 685 - PE1 -------------- P1 ------- P3 ----- PE2 ---- 686 / PLR \ PLR \ 687 / \ | \ 688 CE1 bypass\ |bypass CE2 689 \ \ | / 690 \ \ | / 691 - PE3 -------------- P2 ---------------- PE4 ---- 692 protector 694 |<-------------- PW2 --------------->| 696 Figure 7 698 In S-PE node protection, when a protector receives traffic from the 699 PLR, it forwards the traffic over the next segment of the backup PW. 700 The T-PE of the backup PW in turn forwards the traffic to the CE via 701 a backup AC. This is shown in Figure 8, where P4 is the PLR for SPE1 702 failure, and SPE2 (the backup S-PE) is the protector for SPE1. 704 |<--------------- PW1 --------------->| 705 |<----- SEG1 ----->|<----- SEG2 ----->| 707 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 708 / PLR \ \ 709 / \ \ 710 CE1 bypass\ CE2 711 \ \ / 712 \ \ / 713 - TPE3 --------------- SPE2 -------------- TPE4 - 714 protector 716 |<----- SEG3 ----->|<----- SEG4 ----->| 717 |<--------------- PW2 --------------->| 719 Figure 8 721 In the co-located protector model, the number of context identifiers 722 needed by a network is the number of distinct {primary PE, backup PE} 723 pairs. From the perspective of scalability, the model is suitable 724 for networks where the number of primary PEs and the average number 725 of backup PEs per primary PE are both relatively low. 727 4.4.2. Centralized Protector 729 In this model, the protector is a dedicated P router or PE router 730 that serves the role. In egress AC protection and egress PE node 731 protection, the protector may or may not be a backup PE with a direct 732 connection to the target CE. In S-PE node protection, the protector 733 may or may not be a backup S-PE on the backup PW. 735 In egress AC protection and egress PE node protection, when the 736 protector receives traffic from the PLR, if the protector has a 737 direct connection (i.e. backup AC) to the CE, it forwards the traffic 738 to the CE via the backup AC, which is similar to Figure 7. 739 Otherwise, it forwards the traffic to a backup PE, which then 740 forwards the traffic to the CE via a backup AC. This is shown in 741 Figure 9, where the protector receives traffic from P3 (the PLR for 742 egress PE failure) or PE2 (the PLR for egress AC failure) and 743 forwards the traffic to PE4 (the backup PE). The protector may be 744 protecting other PWs and other primary PEs as well, which is not 745 shown in this figure for clarity. 747 |<------------- PW1 --------------->| 749 - PE1 ------------- P1 ------- P3 ----- PE2 -- 750 / PLR \ PLR \ 751 / \ / \ 752 / bypass\ /bypass \ 753 / \ / \ 754 CE1 protector CE2 755 \ \ / 756 \ \ / 757 \ \ / 758 \ \ / 759 - PE3 ------------- P2 -----------------PE4 -- 761 |<------------- PW2 --------------->| 763 Figure 9 765 In S-PE node protection, when the protector receives traffic from the 766 PLR, if the protector is a backup S-PE of the backup PW, it forwards 767 the traffic over the next segment of the backup PW, and the T-PE of 768 the backup PW forwards the traffic to the CE via a backup AC, which 769 is similar to Figure 8. Otherwise, the protector first forwards the 770 traffic to the backup S-PE, which then forwards the traffic over the 771 next segment of the backup PW. Finally, the T-PE of the backup PW 772 forwards the traffic to the CE via a backup AC. This is shown in 773 Figure 10, where the protector forwards traffic to SPE2 (the backup 774 S-PE), SPE2 forwards the traffic to TPE4 via SEG4, and TPE4 finally 775 forwards traffic to CE2. The protector may be protecting other PW 776 segments and other primary S-PEs as well, which is not shown in this 777 figure for clarity. 779 |<--------------- PW1 --------------->| 780 |<----- SEG1 ----->|<----- SEG2 ----->| 782 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 783 / PLR \ \ 784 / \ \ 785 / bypass\ \ 786 / \ \ 787 CE1 protector CE2 788 \ \ / 789 \ \ / 790 \ \ / 791 \ \ / 792 - TPE3 --------------- SPE2 -------------- TPE4 - 794 |<----- SEG3 ----->|<----- SEG4 ----->| 795 |<--------------- PW2 --------------->| 797 Figure 10 799 The centralized protector model allows multiple primary PEs to share 800 one protector. Each primary PE may need only one protector. 801 Therefore, the number of context identifiers needed by a network may 802 be bound to the number of primary PEs. 804 4.5. Transport Tunnel 806 A PW is associated with a pair of {primary PE, protector}, which is 807 represented by a unique context identifier. The ingress PE of the PW 808 sets up or resolves a transport tunnel by using the context 809 identifier rather than a private IP address of the primary PE as 810 destination. This not only ensures that the PW is transported to the 811 primary PE, but also facilitates bypass tunnel establishment at PLR, 812 because the context identifier contains the identity of the protector 813 as well. This is also the case for a multi-segment PW, where the 814 ingress PE and egress PE are T/S-PEs. 816 An ingress PE learns the association between a PW and a context 817 identifier from the primary PE, which MUST advertise the context 818 identifier as a "third party next hop" via the IPv4/v6 Interface_ID 819 TLV [RFC3471, RFC3472] in the LDP Label Mapping message of the PW. 821 4.6. Bypass Tunnel 823 A PLR may protect multiple PWs associated with one or multiple pairs 824 of {primary PE, protector}. The PLR MUST establish a bypass tunnel to 825 each protector for each context identifier associated with that 826 protector. The destination of the bypass tunnel MUST be the context 827 identifier (Section 4.3.1). Since the PLR is a transit router of the 828 transport tunnel, it SHOULD derive the context identifier from the 829 destination of the transport tunnel. 831 For examples, in Figure 7 and Figure 9, a bypass tunnel is 832 established from PE2 (PLR for egress AC failure) to the protector, 833 and another bypass tunnel is established from P3 (PLR for egress node 834 failure) to the protector. In Figure 8 and Figure 10, a bypass 835 tunnel is established from P4 (PLR for S-PE failure) to the 836 protector. 838 In local repair, a PLR reroutes traffic to the protector through a 839 bypass tunnel, with PW label intact in the packets. This normally 840 involves pushing a label to the label stack, if the bypass tunnel is 841 an MPLS tunnel, or pushing an IP header to the packets, if the bypass 842 tunnel is an IP tunnel. Upon receipt of the packets, the protector 843 forwards them based on the PW label. Specifically, the protector 844 uses the bypass tunnel as a context to determine the primary PE's 845 label space. If the bypass tunnel is an MPLS tunnel, the protector 846 should have assigned a non-reserved label to the bypass tunnel, and 847 hence this label can serve as the context. If the bypass tunnel is 848 an IP tunnel, the context identifier should be the destination 849 address of IP header. 851 To be useful for local repair, a bypass tunnel MUST have the property 852 that it is not affected by any topology changes caused by the 853 failure. It should remain effective during local repair, until the 854 traffic is moved to another fully functional path, i.e. either the 855 same PW over a fully functional transport tunnel, or another fully 856 functional PW. 858 4.7. Forwarding State on Protector 860 A protector learns PW labels from all the primary PEs that it 861 protects (Section 6.2), and maintains the PW labels in separate label 862 spaces on a per primary PE basis. In the control plane, each label 863 space is identified by the context identifier of the corresponding 864 {primary PE, protector}. In the forwarding plane, it is indicated by 865 the bypass tunnel(s) destined for the context identifier. 867 4.7.1. Examples of Co-located Protector 869 In Figure 7, PE4 is a co-located protector that protects PW1 against 870 egress AC failure and egress node failure. It maintains a label 871 space for PE2, which is identified by the context identifier of {PE2, 872 PE4}. It learns PW1's label from PE2, and installs an forwarding 873 entry for the label in that label space. The nexthop of the 874 forwarding entry indicates a label pop with outgoing interface 875 pointing to the backup AC PE4-CE2. 877 e In Figure 8, SPE2 is a co-located protector that protects PW1 878 against S-PE failure. It maintains a label space for SPE1, which is 879 identified by the context identifier of {SPE1, SPE2}. It learns 880 SEG1's label from SPE1, and installs a forwarding entry in the label 881 space. The nexthop of the forwarding entry indicates a label swap to 882 SEG4's label. 884 4.7.2. Examples of Centralized Protector 886 In the centralized protector model, for each primary PW of which the 887 protector is not a backup (S-)PE, the protector MUST also learn the 888 label of the backup PW from the backup (S-)PE (Section 6.3). This is 889 the backup (S-)PE that the protector will forward traffic to. The 890 protector MUST install a forwarding entry with label swap from the 891 primary PW's label to the backup PW's label. 893 In Figure 9, the protector is a centralized protector that protects 894 PW1 against egress AC failure and egress node failure. It maintains 895 a label space for PE2, which is identified by the context identifier 896 of {PE2, protector}. It learns PW1's label from PE2, and PW2's label 897 from PE4. It installs a forwarding entry for PW1's label in the 898 label space. The nexthop of the forwarding entry indicates a label 899 swap to PW2's label. 901 In Figure 10, the protector is a centralized protector that protects 902 the PW segment SEG1 of PW1 against the node failure of SPE1. It 903 maintains a label space for SPE1, which is identified by the context 904 identifier of {SPE1, protector}. It learns SEG1's label from SPE1, 905 and learns SEG3's label from SPE2. It installs a forwarding entry 906 for SEG1's label in the label space. The nexthop of the forwarding 907 entry indicates a label swap to SEG3's label. 909 5. Revertive Behavior 911 Subsequent to local repair, there are three strategies for a network 912 to restore traffic to a fully functional path. 914 o Global revertive mode 916 If the ingress CE is multi-homed (Figure 1), it MAY switch the 917 traffic to the backup AC which is bound to the backup PW. 918 Alternatively, if the ingress PE hosts a backup PW (Figure 2), the 919 ingress PE MAY switch the traffic to the backup PW. These 920 procedures are referred to as global repair. Possible triggers of 921 global repair include PW status notification, VCCV, BFD, end-to- 922 end OAM between CEs, etc. 924 o Control plane revertive mode 926 In egress PE node protection and S-PE node protection, it is 927 possible that the failure is limited to the link between the PLR 928 and the primary PE, whereas the primary PE is still operational. 929 In this case, the PLR or an upstream router on the transport 930 tunnel MAY reroute the tunnel around the link via an alternative 931 path to the primary PE. Thus, the transport tunnel can heal and 932 continue to carry the PW to the primary PE. This procedure is 933 driven by control plane convergence on the new topology, and is 934 referred to as control plane repair. 936 o Local revertive mode 938 The PLR MAY move traffic back to the primary PW, after the failure 939 is resolved. In egress AC protection, upon detecting that the 940 primary AC is restored, the PLR MAY start forwarding traffic over 941 the AC again. Likewise, in egress PE node protection and S-PE 942 node protection, upon detecting that the primary PE is restored, 943 the PLR MAY re-establish the transport tunnel to the primary PE, 944 and move the traffic from the bypass tunnel back to the transport 945 tunnel. These procedures are referred to as local reversion. 947 It is RECOMMENDED that the fast protection mechanism SHOULD be used 948 in conjunction with the global revertive mode. Particularly in the 949 case of egress PE and S-PE node failures, if the ingress PE or the 950 protector loses communication with the (S-)PE for an extensive period 951 of time, LDP session may go down. Consequently, the ingress PE may 952 bring down the primary PW completely, or the protector may remove the 953 forwarding entry of the primary PW label. In either case, the 954 service will be disrupted. In other words, although the mechanism 955 can temporarily repair traffic, control plane state may eventually 956 expire if the failure persists. Therefore, the global revertive mode 957 SHOULD take place in a timely manner to move traffic to a fully 958 functional path. 960 The control plane revertive mode may automatically happen as part of 961 the convergence of control plane protocols. However, it is only 962 applicable to the specific link failure scenario described above. 964 The local revertive mode is optional. In the circumstances where the 965 failure is caused by resource flapping, local reversion MAY be 966 dampened to limit potential disruption. Local revertive mode MAY be 967 disabled completely by configuration. 969 6. LDP Extensions 971 As described in previous sections, a targeted LDP session MUST be 972 established between each pair of primary PE and protector. The 973 primary PE sends Label Mapping message over this session to advertise 974 primary PW labels to the protector. In the centralized protector 975 model, a targeted LDP session MUST also be established between a 976 backup (S-)PE and the protector. The backup PE sends Label Mapping 977 message over this session to advertise backup PW labels to the 978 protector. 980 To facilitate the procedures, this document defines a new "Protection 981 FEC Element" TLV. The Label Mapping messages of both the LDP 982 sessions above MUST carry this TLV to identify a primary PW. 983 Specifically, in the centralized protector model, the Protection FEC 984 Element TLV advertised by a backup (S-)PE MUST match the one 985 advertised by the primary PE, so that the protector can associate the 986 primary PW's label with the backup PW's label, and perform a label 987 swap. The backup (S-)PE builds such a Protection FEC Element TLV 988 based on local configuration. 990 This document also defines the encoding of Capability Parameter TLV 991 [RFC5561] for a new "Egress Protection Capability", to allow a 992 protector to announce its capability of processing the above 993 Protection FEC Element TLV and performing context specific label 994 switching for PW labels. 996 The procedures in this section are only applicable, if the protector 997 advertises the Egress Protection Capability, the primary PE supports 998 the advertisement of the Protection FEC Element TLV, and in the 999 centralized protector model, the backup PE also supports the 1000 advertisement of the Protection FEC Element TLV. 1002 6.1. Egress Protection Capability TLV 1004 A protector MUST advertise the Egress Protection Capability TLV in 1005 its Initialization message and Capability message, over the LDP 1006 session with a primary PE. In the centralized protector model, the 1007 protector MUST also advertise the TLV over the LDP session with a 1008 backup PE. The TLV carries one or multiple context identifiers. To 1009 the primary PE, the TLV MUST carry the context identifier of the 1010 {primary PE, protector}. In the centralized protector model, the TLV 1011 MUST carry to the backup PE multiple context identifiers, one for 1012 each {primary PE, protector} where the backup PE serves as a backup 1013 for the primary PE. This TLV MUST NOT be advertised by the primary 1014 PE or the backup PE to the protector. 1016 The processing of the Egress Protection Capability TLV by a receiving 1017 router MUST follow the procedures defined in RFC5561. In particular, 1018 the router MUST advertise PW information to the protector by using 1019 the Protection FEC Element TLV, only after it has received the Egress 1020 Protection Capability TLV from the protector. It MUST validate each 1021 context identifier included in the TLV, and advertise the information 1022 of only the PWs that are associated with the context identifier. It 1023 MUST withdraw previously advertised Protection FEC TLVs, when the 1024 protector has withdrawn a previously advertised context identifier or 1025 the entire Egress Protection Capability TLV via Capability message. 1027 The encoding of the Egress Protection Capability TLV is defined as 1028 below. It conforms to the format of Capability Parameter TLV 1029 specified in RFC5561. 1031 0 1 2 3 1032 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 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 |U|F| Egress Protection (TBD) | Length | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 |S| Reserved | | 1037 +-+-+-+-+-+-+-+-+ | 1038 | | 1039 ~ Capability Data = context identifier(s) ~ 1040 | | 1041 | +-+-+-+-+-+-+-+-+ 1042 | | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 Figure 11 1047 The U-bit MUST be set to 1 so that a receiver MUST silently ignore 1048 this TLV if unknown to it, and continue processing the rest of the 1049 message. 1051 The F-bit MUST be set to 0 since this TLV is sent only in 1052 Initialization and Capability messages, which are not forwarded. 1054 The TLV Code Point is TBD. It needs to be assigned by IANA. 1056 The S-bit indicates whether the sender is advertising (S=1) or 1057 withdrawing (S=0) the capability. 1059 The "Capability Data" is encoded with the context identifier of the 1060 {primary PE, protector}. 1062 6.2. PW Label Distribution from Primary PE to Protector 1064 A primary PE MUST advertise a primary PW's label to a protector by 1065 sending a Label Mapping message. The message includes a Protection 1066 FEC Element TLV (see Section 6.4 for encoding), and an Upstream- 1067 Assigned Label TLV [RFC6389] encoded with the PW's label. The 1068 combination of the Protection FEC Element TLV and the PW label 1069 represents the primary PE's forwarding state for the PW. The Label 1070 Mapping message MUST also carry an IPv4/v6 Interface_ID TLV [RFC6389, 1071 RFC3471] encoded with the context identifier of the {primary PE, 1072 protector}. 1074 The protector that receives this Label Mapping message MUST install a 1075 forwarding entry for the PW label in the label space identified by 1076 the context identifier. The nexthop of the forwarding entry MUST 1077 ensure packets to be sent towards the target CE via a backup AC or a 1078 backup (S-)PE, depending on the protection scenario. The protector 1079 MUST silently discard a Label Mapping message if the included context 1080 identifier is unknown to it. 1082 6.3. PW Label Distribution from Backup PE to Protector 1084 In the centralized protector model, a backup PE MUST advertise a 1085 backup PW's label to the protector by sending a Label Mapping 1086 message. The message includes a Protection FEC Element TLV and a 1087 Generic Label TLV encoded with the backup PW's label. This 1088 Protection FEC Element MUST be identical to the Protection FEC 1089 Element TLV that the primary PE advertises to the protector 1090 (Section 6.2). This is achieved through configuration on the backup 1091 PE. The context identifier MUST NOT be encoded in Interface_ID TLV 1092 in this message. 1094 The protector that receives this Label Mapping message MUST associate 1095 the backup PW with the primary PW, based on the common Protection FEC 1096 Element TLV. It MUST distinguish between the Label Mapping message 1097 from the primary PE and the Label Mapping message from the backup PE 1098 based on the respective presence and absence of context identifier in 1099 Interface_ID TLV. It MUST install a forwarding entry for the primary 1100 PW's label in the label space identified by the context identifier. 1101 The nexthop of the forwarding entry MUST indicate a label swap to the 1102 backup PW's label, followed by a label push or IP header push for a 1103 transport tunnel to the backup PE. 1105 6.4. Protection FEC Element TLV 1107 The Protection FEC Element TLV has type 0x83. Its format is defined 1108 as below: 1110 0 1 2 3 1111 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 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | Type(0x83) | Reserved | Encoding Type | Length | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | | 1116 | | 1117 ~ PW Information ~ 1118 | | 1119 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 Figure 12 1125 - Encoding Type 1127 Type of format that PW Information field is encoded. 1129 - Length 1131 Length of PW Information field in octets. 1133 - PW Information 1135 Field of variable length that specifies a PW 1137 For Encoding Type, 1 is defined for the PWid FEC Element format, and 1138 2 is defined for the Generalized PWid FEC Element format [RFC4447]. 1140 6.4.1. Encoding Format for PWid 1141 0 1 2 3 1142 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 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Type(0x83) | Reserved | Enc Type(1) | Length(16) | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Ingress PE Address | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | Egress PE Address | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Group ID | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | PW ID | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 |C| PW Type | Reserved | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 Figure 13 1159 - Ingress PE Address 1161 IP address of the ingress PE of PW. 1163 - Egress PE Address 1165 IP address of the egress PE of PW. 1167 - Group ID 1169 An arbitrary 32-bit value that represents a group of PWs and that 1170 is used to create groups in the PW space. 1172 - PW ID 1174 A non-zero 32-bit connection ID that, together with the PW Type 1175 field, identifies a particular PW. 1177 - Control word bit (C) 1179 A bit that flags the presence of a control word on this PW. If C 1180 = 1, control word is present; If C = 0, control word is not 1181 present. 1183 - PW Type 1185 A 15-bit quantity that represents the type of PW. 1187 6.4.2. Encoding Format for Generalized PWid 1189 0 1 2 3 1190 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 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Type(0x83) | Reserved | Enc Type(2) | Length | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | Ingress PE Address | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Egress PE Address | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 |C| PW Type | Reserved | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | AGI Type | Length | Value | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 ~ AGI Value (contd.) ~ 1203 | | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | AII Type | Length | Value | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 ~ SAII Value (contd.) ~ 1208 | | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | AII Type | Length | Value | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 ~ TAII Value (contd.) ~ 1213 | | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 Figure 14 1218 - Ingress PE Address 1220 IP address of the ingress PE of PW. 1222 - Egress PE Address 1224 IP address of the egress PE of PW. 1226 - Control word bit (C) 1228 A bit that flags the presence of a control word on this PW. If C 1229 = 1, control word is present; If C = 0, control word is not 1230 present. 1232 - PW Type 1234 A 15-bit quantity that represents the type of PW. 1236 - AGI Type, Length, Value, AGI Value 1238 Attachment Group Identifier of PW. 1240 - SAII Type, Length, Value, SAII Value 1242 Source Attachment Individual Identifier of PW. 1244 - TAII Type, Length, Value, TAII Value 1246 Target Attachment Individual Identifier of PW. 1248 7. IANA Considerations 1250 This document defines the encoding of the Capability Parameter TLV 1251 for the new "Egress Protection Capability" in Section 6. This would 1252 require IANA to assign a TLV Code Point to it. 1254 This document defines a new LDP Protection FEC Element TLV in 1255 Section 6. IANA has assigned the type value 0x83 to it. 1257 Value Hex Name Label Advertisement Discipline 1258 ------------------------------------------------------------------- 1259 131 0x83 Protection FEC Element DU 1261 8. Security Considerations 1263 The security considerations discussed in RFC5036, RFC5331, RFC3209, 1264 and RFC4090 apply to this document. There is no additional 1265 consideration. 1267 9. Acknowledgements 1269 This document leverages work done by Hannes Gredler, Yakov Rekhter, 1270 Minto Jeyananth, Kevin Wang and several on MPLS edge protection. 1271 Thanks to Nischal Sheth and Bhupesh Kothari for their contribution. 1272 Thanks to John E Drake, Andrew G Malis, Alexander Vainshtein, Steward 1273 Bryant, and Mach Chen for valuable comments that helped shape this 1274 document and improve its clarity. 1276 10. References 1278 10.1. Normative References 1280 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 1281 Edge-to-Edge (PWE3) Architecture", RFC 3985, 1282 DOI 10.17487/RFC3985, March 2005, 1283 . 1285 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 1286 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 1287 DOI 10.17487/RFC5659, October 2009, 1288 . 1290 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 1291 G. Heron, "Pseudowire Setup and Maintenance Using the 1292 Label Distribution Protocol (LDP)", RFC 4447, 1293 DOI 10.17487/RFC4447, April 2006, 1294 . 1296 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1297 Label Assignment and Context-Specific Label Space", 1298 RFC 5331, DOI 10.17487/RFC5331, August 2008, 1299 . 1301 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 1302 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 1303 October 2007, . 1305 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 1306 Le Roux, "LDP Capabilities", RFC 5561, 1307 DOI 10.17487/RFC5561, July 2009, 1308 . 1310 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1311 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1312 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1313 September 1997, . 1315 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1316 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1317 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1318 . 1320 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1321 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1322 DOI 10.17487/RFC4090, May 2005, 1323 . 1325 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 1326 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 1327 DOI 10.17487/RFC5286, September 2008, 1328 . 1330 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1331 RFC 5714, DOI 10.17487/RFC5714, January 2010, 1332 . 1334 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 1335 Switching (GMPLS) Signaling Functional Description", 1336 RFC 3471, DOI 10.17487/RFC3471, January 2003, 1337 . 1339 [RFC3472] Ashwood-Smith, P., Ed. and L. Berger, Ed., "Generalized 1340 Multi-Protocol Label Switching (GMPLS) Signaling 1341 Constraint-based Routed Label Distribution Protocol (CR- 1342 LDP) Extensions", RFC 3472, DOI 10.17487/RFC3472, January 1343 2003, . 1345 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1346 Label Switching Architecture", RFC 3031, 1347 DOI 10.17487/RFC3031, January 2001, 1348 . 1350 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1351 DOI 10.17487/RFC2328, April 1998, 1352 . 1354 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1355 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1356 . 1358 [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label 1359 Assignment for LDP", RFC 6389, DOI 10.17487/RFC6389, 1360 November 2011, . 1362 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 1363 Regan, J., and S. Amante, "Flow-Aware Transport of 1364 Pseudowires over an MPLS Packet Switched Network", 1365 RFC 6391, DOI 10.17487/RFC6391, November 2011, 1366 . 1368 [IP-LDP-FRR-MRT] 1369 Atlas, A. and R. Kebler, "An Architecture for IP/LDP Fast- 1370 Reroute Using Maximally Redundant Trees", draft-ietf- 1371 rtgwg-mrt-frr-architecture (work in progress), 2011. 1373 10.2. Informative References 1375 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1376 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1377 . 1379 Authors' Addresses 1381 Yimin Shen 1382 Juniper Networks 1383 10 Technology Park Drive 1384 Westford, MA 01886 1385 USA 1387 Phone: +1 9785890722 1388 Email: yshen@juniper.net 1390 Rahul Aggarwal 1391 Arktan, Inc 1393 Email: raggarwa_1@yahoo.com 1395 Wim Henderickx 1396 Alcatel-Lucent 1397 Copernicuslaan 50 1398 2018 Antwerp 1399 Belgium 1401 Email: wim.henderickx@alcatel-lucent.be 1403 Yuanlong Jiang 1404 Huawei Technologies 1406 Email: jiangyuanlong@huawei.com