idnits 2.17.1 draft-ietf-pwe3-endpoint-fast-protection-00.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 serves the role. 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 on the backup PW. -- The document date (December 13, 2013) is 3787 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 1150, but no explicit reference was found in the text == Unused Reference: 'RFC5659' is defined on line 1153, but no explicit reference was found in the text == Unused Reference: 'RFC4447' is defined on line 1157, but no explicit reference was found in the text == Unused Reference: 'RFC5331' is defined on line 1161, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 1165, but no explicit reference was found in the text == Unused Reference: 'RFC5561' is defined on line 1168, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 1171, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1175, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 1179, but no explicit reference was found in the text == Unused Reference: 'RFC5286' is defined on line 1183, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 1186, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 1189, but no explicit reference was found in the text == Unused Reference: 'RFC3472' is defined on line 1193, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 1198, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 1201, but no explicit reference was found in the text == Unused Reference: 'RFC5880' is defined on line 1203, but no explicit reference was found in the text == Unused Reference: 'RFC6389' is defined on line 1206, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 1216, 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 (~~), 21 warnings (==), 2 comments (--). 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: June 16, 2014 Arktan, Inc 6 Wim Henderickx 7 Alcatel-Lucent 8 Yuanlong Jiang 9 Huawei Technologies 10 December 13, 2013 12 PW Endpoint Fast Failure Protection 13 draft-ietf-pwe3-endpoint-fast-protection-00 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. Designed on the basis of 21 multi-homed CE, PW redundancy, 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. In 24 particular, the router can restore PW traffic in the order of tens of 25 milliseconds, by transmitting the traffic to a protector through a 26 pre-established bypass tunnel. Therefore, the mechanism can 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 June 16, 2014. 47 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 . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Multi-Segment PW . . . . . . . . . . . . . . . . . . . . 6 68 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. Local Repair and Protector . . . . . . . . . . . . . . . 8 70 4.2. Context Identifier . . . . . . . . . . . . . . . . . . . 10 71 4.2.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 10 72 4.2.2. Advertisement and Path Computation . . . . . . . . . 11 73 4.3. Protection Models . . . . . . . . . . . . . . . . . . . . 12 74 4.3.1. Co-located Protector . . . . . . . . . . . . . . . . 12 75 4.3.2. Centralized Protector . . . . . . . . . . . . . . . . 13 76 4.4. Transport Tunnel . . . . . . . . . . . . . . . . . . . . 15 77 4.5. Bypass Tunnel . . . . . . . . . . . . . . . . . . . . . . 16 78 4.6. Forwarding State on Protector . . . . . . . . . . . . . . 16 79 4.6.1. Examples of Co-located Protector . . . . . . . . . . 16 80 4.6.2. Examples of Centralized Protector . . . . . . . . . . 17 81 5. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 17 82 5.1. Egress Protection Capability TLV . . . . . . . . . . . . 18 83 5.2. PW Label Distribution from Primary PE to Protector . . . 20 84 5.3. PW Label Distribution from Backup PE to Protector . . . . 20 85 5.4. Protection FEC Element TLV . . . . . . . . . . . . . . . 20 86 5.4.1. Encoding Format for PWid . . . . . . . . . . . . . . 21 87 5.4.2. Encoding Format for Generalized PWid . . . . . . . . 22 88 6. Revertive Behavior . . . . . . . . . . . . . . . . . . . . . 24 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 94 10.2. Informative References . . . . . . . . . . . . . . . . . 27 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 97 1. Introduction 99 Per RFC 3985, RFC 4447 and RFC 5659, a pseudowire (PW) or PW segment 100 can be thought of as a connection between a pair of forwarders hosted 101 by two PEs, carrying an emulated layer-2 service over a packet 102 switched network (PSN). In the single-segment PW (SS-PW) case, a 103 forwarder binds a PW to an attachment circuit (AC). In the multi- 104 segment PW (MS-PW) case, a forwarder on a terminating PE (T-PE) binds 105 a PW segment to an AC, while a forwarder on a switching PE (S-PE) 106 binds one PW segment to another PW segment. In each direction 107 between the PEs, PW packets are transported by a PSN tunnel, which is 108 called a transport tunnel. 110 In order to protect the layer-2 service against network failures, it 111 is necessary to protect every link and node along the entire data 112 path. For the traffic in a given direction, this include ingress AC, 113 ingress (T-)PE, intermediate routers of transport tunnel, S-PEs, 114 egress (T-)PE, and egress AC. To minimize service disruption upon a 115 failure, it is also desirable that each of these components is 116 protected by a fast protection mechanism based on local repair. Such 117 a mechanism generally involves a bypass path that is pre-computed and 118 pre-installed on the router upstream adjacent to an anticipated 119 failure. The bypass path has the property that it can guide traffic 120 around the failure, while remaining unaffected by the topology 121 changes resulting from the failure. Thus, when the failure occurs, 122 the router can invoke the bypass path to achieve fast restoration for 123 the service. 125 Today, fast protection against ingress AC failure and ingress (T-)PE 126 failure is achievable by using a multi-homed CE and redundant PWs. 127 Fast protection against failure of intermediate router is achievable 128 through RSVP fast-reroute (RFC 4090) or IP/LDP fast-reroute (RFC 129 5714, RFC 5286). However, there is a lack of equivalent mechanism 130 against egress AC failure, egress (T-)PE failure, and S-PE failure. 131 For these failures, service restoration has to rely on global repair 132 or control plane repair. Global repair is normally driven by ingress 133 CE or ingress (T-)PE, and dependent on PW status notification or end- 134 to-end OAM. Control plane repair is dependent on protocol 135 convergence. Therefore, both mechanisms are relatively slow in 136 reacting to the failures and restoring traffic. 138 This document is intended to serve the above need. It specifies a 139 fast protection mechanism based on local repair technique to protect 140 PWs against the following egress endpoint failures. 142 a. Egress AC failure. 144 b. Egress PE failure: Node failure of an egress PE of an SS-PW, or a 145 T-PE of an MS-PW. 147 c. Switching PE failure: Node failure of an S-PE of an MS-PW. 149 The mechanism is applicable to LDP signaled PWs. It is relevant to 150 networks with redundant PWs and multi-homed CEs. It is designed on 151 the basis of MPLS upstream label assignment and context-specific 152 label switching (RFC 5331). Fast protection refers to the ability to 153 restore traffic upon a failure in the order of tens of milliseconds. 154 This is achieved by establishing local protection at the router 155 upstream adjacent to an anticipated failure. Compared with the 156 existing global repair and control plane repair mechanisms, this 157 mechanism can provide faster service restoration. However, it is 158 intended to complement those mechanisms, rather than replacing them 159 in any way. 161 2. Specification of Requirements 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119. 167 3. Reference Models and Failure Cases 169 This document refers to the following topologies to describe failure 170 scenarios and protection procedures. These topologies involve multi- 171 homed CEs and redundant PWs, which are commonly seen in networks with 172 global repair mechanisms. The mechanism in this document intends to 173 use these topologies for local repair purposes. This SHALL enable 174 local repair and global repair to work in tandem to achieve broader 175 coverage of protection for services. 177 3.1. Single-Segment PW 179 |<-------------- PW1 --------------->| 181 - PE1 -------------- P1 ---------------- PE2 - 182 / \ 183 / \ 184 CE1 CE2 185 \ / 186 \ / 187 - PE3 -------------- P2 ---------------- PE4 - 189 |<-------------- PW2 --------------->| 191 Figure 1 193 In Figure 1, the IP/MPLS network consists of PE-routers and 194 P-routers. It provides an emulation of a layer-2 service between CE1 195 and CE2. 197 Each CE is multi-homed to two PEs. Hence, there are two divergent 198 paths between the CEs. The first path uses PW1 established between 199 PE1 and PE2, connecting the AC CE1-PE1 and the AC CE2-PE2. The 200 second path uses PW2 established between PE3 and PE4, connecting the 201 AC CE1-PE3 and the AC CE2-PE4. The operational states of all the PWs 202 and ACs are up. The transport tunnels of the PWs are not shown in 203 this figure for clarity. 205 At any given time, each CE sends traffic via only one AC and receives 206 traffic via only one AC. The two ACs MAY or MAY NOT be the same. 207 The AC used to send traffic is determined by the CE, and MAY rely on 208 an end-to-end OAM mechanism between the CEs. The AC used for the CE 209 to receive traffic is determined by the state of the network and the 210 protection mechanism in use, as described later in this document. 212 From the perspective of traffic flowing towards a given CE, the set 213 of PWs, PEs and ACs involved can be viewed to serve primary and 214 backup (or active and standby) roles. When the network is in a 215 steady state, the PW that is intended to carry the traffic is 216 referred to as a primary PW. The PE at the egress of the primary PW 217 is a primary PE. The AC connecting the CE and the primary PE is a 218 primary AC. The other PW may be used to carry the traffic upon a 219 network failure, and is referred to as a backup PW. The PE at the 220 egress of the backup PW is a backup PE. The AC connecting the CE and 221 the backup PE is a backup AC. 223 In this document, the following primary and backup roles are assigned 224 for the traffic going from CE1 to CE2: 226 Primary PW: PW1 228 Primary PE: PE2 230 Primary AC: CE2-PE2 232 Backup PW: PW2 234 Backup PE: PE4 236 Backup AC: CE2-PE4 238 In this case, an egress AC failure refers to the failure of the AC 239 CE2-PE2. An egress node failure refers to the failure of PE2. 241 The backup PE, backup PW and backup AC may be used to carry traffic 242 after a PW endpoint failure, when CE1 and CE2 switches traffic to PW2 243 in local repair or global repair, as described later in this 244 document. 246 |<-------------- PW1 --------------->| 248 ------------- P1 ---------------- PE2 - 249 / \ 250 / \ 251 CE1 -- PE1 CE2 252 \ / 253 \ / 254 ------------- P2 ---------------- PE4 - 256 |<-------------- PW2 --------------->| 258 Figure 2 260 Figure 2 shows another possible scenario, where CE1 is single-homed 261 to PE1, while CE2 remains multi-homed to PE2 and PE4. From the 262 perspective of egress protection for the traffic from CE1 to CE2, 263 this topology is not much different than Figure 1. However, for the 264 traffic in the direction from CE2 to CE1, PE1 must anticipate traffic 265 on both PW1 and PW2, and sends it to CE1 over the AC CE1-PE1. 267 3.2. Multi-Segment PW 269 |<--------------- PW1 --------------->| 270 |<----- SEG1 ----->|<----- SEG2 ----->| 272 - TPE1 -------------- SPE1 --------------- TPE2 - 273 / \ 274 / \ 275 CE1 CE2 276 \ / 277 \ / 278 - TPE3 -------------- SPE2 --------------- TPE4 - 280 |<----- SEG3 ----->|<----- SEG4 ----->| 281 |<--------------- PW2 --------------->| 283 Figure 3 285 Figure 3 shows a topology that is similar to Figure 1 but in an MS-PW 286 environment. PW1 and PW2 are both MS-PWs. PW1 is established 287 between TPE1 and TPE2, and switched between segments SEG1 and SEG2 at 288 SPE1. PW2 is established between TPE3 and TPE4, and switched between 289 segments SEG3 and SEG4 at SPE2. CE1 is multi-homed to TPE1 and TPE3. 290 CE2 is multi-homed to TPE2 and TPE4. The transport tunnels of the PW 291 segments are not shown in this figure for clarity. 293 In this document, the following primary and backup roles are assigned 294 for the traffic going from CE1 to CE2: 296 Primary PW: PW1 298 Primary T-PE: TPE2 300 Primary S-PE: SPE1 302 Primary AC: CE2-TPE2 304 Backup PW: PW2 306 Backup T-PE: TPE4 308 Backup S-PE: SPE2 310 Backup AC: CE2-TPE4 312 In this case, an egress AC failure refers to the failure of the AC 313 CE2-TPE2. An egress node failure refers to the failure of TPE2. An 314 S-PE failure refers to the failure of SPE1. 316 The backup T-PE, backup PW and backup AC are used for protecting the 317 primary PW against egress AC failure and egress node failure. The 318 backup S-PE and the backup PW are used for protecting the primary PW 319 against S-PE failure, as described later in this document. 321 For consistency with the SS-PW scenario, primary T-PEs and a primary 322 S-PEs may simply be referred to as primary PEs in this document, 323 where specifics is not required. Similarly, backup T-PEs and backup 324 S-PEs may be referred to as backup PEs. 326 4. Theory of Operation 328 The fast protection mechanism in this document provides three types 329 of protection for PWs, corresponding to the three types of failures 330 described in Section 1. 332 a. Egress AC protection 334 b. Egress (T-)PE node protection 336 c. S-PE node protection 337 The mechanism assumes a multi-homed CE with connectivity to a primary 338 PE and a backup PE, and the existence of a backup PW in the network. 339 In S-PE node protection, it also assumes the existence of a backup 340 S-PE on the backup PW. 342 4.1. Local Repair and Protector 344 The mechanism relies on local repair to be performed by routers 345 upstream adjacent to failures. Each of these routers is referred to 346 as a "point of local repair" (PLR). A PLR MUST be able to detect a 347 failure by using a rapid mechanism, such as physical layer failure 348 detection, Bidirectional Failure Detection (BFD) (RFC 5880), etc. In 349 anticipation of the failure, the PLR MUST also pre-establish a bypass 350 PSN tunnel to a "protector", and pre-install a bypass route in the 351 data plane. The bypass tunnel MUST have the property that it will 352 not be affected by the topology changes in the event of the failure. 353 Upon detecting the failure, the PLR MUST invoke the bypass route in 354 the data plane, and reroute PW traffic to the protector through the 355 bypass tunnel. The protector MUST in turn send the traffic to the 356 target CE. This procedure is referred to as local repair. 358 Different routers may serve as PLR and protector in different 359 scenarios. 361 o In egress AC protection, the PLR is the primary PE that terminates 362 the primary PW and hosts the primary AC, and the protector is the 363 backup PE (Figure 4). 365 |<-------------- PW1 --------------->| 367 - PE1 -------------- P1 ---------------- PE2 - 368 / PLR \ 369 / | \ 370 CE1 bypass| CE2 371 \ | / 372 \ | / 373 - PE3 -------------- P2 ---------------- PE4 - 374 protector 376 |<-------------- PW2 --------------->| 378 Figure 4 380 o In egress PE node protection, the PLR is the penultimate hop 381 router of the transport tunnel of the primary PW, and the 382 protector is the backup PE (Figure 5). 384 |<-------------- PW1 --------------->| 386 - PE1 -------------- P1 ------- P3 ----- PE2 - 387 / PLR \ \ 388 / \ \ 389 CE1 bypass\ CE2 390 \ \ / 391 \ \ / 392 - PE3 -------------- P2 ---------------- PE4 - 393 protector 395 |<-------------- PW2 --------------->| 397 Figure 5 399 o In S-PE node protection, the PLR is the penultimate hop router of 400 the transport tunnel of the primary PW segment, and the protector 401 is the backup S-PE (Figure 6). 403 |<--------------- PW1 --------------->| 404 |<----- SEG1 ----->|<----- SEG2 ----->| 406 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 407 / PLR \ \ 408 / \ \ 409 CE1 bypass\ CE2 410 \ \ / 411 \ \ / 412 - TPE3 --------------- SPE2 -------------- TPE4 - 413 protector 415 |<----- SEG3 ----->|<----- SEG4 ----->| 416 |<--------------- PW2 --------------->| 418 Figure 6 420 A PLR can realize its role based on configuration or the signaling of 421 transport tunnel. For example, in the case where the transport 422 tunnel is signaled by RSVP, the penultimate hop router could realize 423 that it is the PLR for egress (T-)PE or S-PE failure based on the RRO 424 in Resv message, which should indicate that the router is one hop 425 away from the PE. The detail of how this could be achieved on a per- 426 protocol basis is out of the scope of this document. 428 In all scenarios, when a PLR reroutes traffic through a bypass tunnel 429 to a protector during local repair, it MUST keep the label of the 430 primary PW intact in the packets. This obviates the need for the PLR 431 to maintain bypass routes on a per-PW basis, and allows a single 432 bypass tunnel to carry traffic for multiple PWs. 434 The procedure also requires that the protector SHOULD be able to 435 forward the traffic based on a PW label that is assigned by the 436 primary PE, and ensure the traffic to eventually reach the target CE. 437 From the protector's perspective, this PW label is an upstream 438 assigned label (RFC 5331). To accomplish this, the protector SHOULD 439 learning the PW label from the primary PE prior to the failure, and 440 install proper forwarding state for the PW label in a dedicated label 441 space for the primary PE. During local repair, the protector SHOULD 442 perform PW label lookup in this label space. 444 The above examples have shown the scenarios where the protectors are 445 backup (T/S-)PEs. In other scenarios, a protector may be a dedicated 446 router that assumes such role, separate from the backup (T/S-)PE of a 447 primary PW. During local repair, the PLR MUST still reroute traffic 448 to the protector through a bypass tunnel. The protector MUST in turn 449 send the traffic to the backup (T/S-)PE, which MUST then send the 450 traffic to the target CE via a backup AC or a backup PW segment. 451 More detail will be described in Section 4.3. 453 4.2. Context Identifier 455 A protector MAY protect multiple primary PEs. The protector MUST 456 maintain a separate label space for each primary PE. Likewise, the 457 PWs terminated on a primary PE MAY be protected by multiple 458 protectors, each for a subset of the PWs. In any case, a given 459 primary PW SHOULD be associated with one and only one pair of 460 {primary PE, protector}. 462 An IPv4/v6 address is assigned to each ordered pair of {primary PE, 463 protector} to facilitate protection establishment. This address is 464 referred to as a "context identifier". It MUST be globally unique, 465 or unique in the address space of the network where the primary PE 466 and the protector reside. 468 4.2.1. Semantics 470 The semantics of a context identifier is twofold. 472 o It identifies a primary PE and an associated protector. In other 473 words, it identifies a primary PE on a per protector basis. A 474 given primary PE may be protected by multiple protectors, each for 475 a subset of the primary PWs terminated on the primary PE. A 476 distinct context identifier MUST be assigned to the primary PE and 477 each protector. 479 For each primary PW, its ingress PE MUST set up or resolve a 480 transport tunnel with destination as the context identifier of the 481 {primary PE, protector}, rather than a private IP address of the 482 primary PE. This not only allows the transport tunnel to reach 483 the primary PE, but also conveys the identity of the protector to 484 the PLR(s) along the transport tunnel. Each PLR can in turn use 485 this information to set up a bypass tunnel to the protector 486 without relying on local configuration. 488 o It indentifies the primary PE's label space on the protector. The 489 protector may protect PWs for multiple primary PEs. For each 490 primary PE, it MUST maintain a separate label space to store the 491 PW labels assigned by that primary PE. It MUST associate a PW 492 label with a label space via the context identifier of the 493 {primary PE, protector}, as described below. 495 In addition to the normal LDP PW signaling, the primary PE MUST 496 have a targeted LDP session with the protector, and advertise PW 497 labels to the protector via LDP Label Mapping messages (See 498 Section 5 for detail). The primary PE MUST attach the context 499 identifier to each message. Upon receiving the message, the 500 protector MUST install the advertised PW label in the label space 501 identified by the context identifier. 503 When a PLR sets up or resolve a bypass tunnel to the protector, it 504 MUST set the destination to the context identifier, rather than a 505 private IP address of the protector. Once established, the bypass 506 tunnel, with either its MPLS label or IP tunnel destination 507 address, is used as the identifier of label space. On the 508 protector, all PW packets received on the bypass tunnel MUST be 509 forwarded based on a label lookup in that label space. 511 4.2.2. Advertisement and Path Computation 513 Using a context identifier as destination for both transport tunnel 514 and bypass tunnel requires both the primary PE and the protector to 515 advertise the context identifier via IGP as an IP address reachable 516 through both routers in routing domain and/or TE domain. This 517 imposes the following requirements on path computation for these 518 tunnels. 520 o For the transport tunnel, the ingress PE MUST choose the primary 521 PE as the actual endpoint. 523 o For the bypass tunnel, the PLR MUST choose the protector as the 524 actual endpoint. In egress (T-)PE node protection and S-PE node 525 protection, the bypass tunnel MUST avoid the primary (S-)PE. 527 The detail of how the primary PE and the protector may advertise a 528 context identifier is independent of this mechanism and out of the 529 scope of this document. One approach would be to advertise it as a 530 virtual proxy node connected to both routers, with the link between 531 the proxy node and the primary PE having a more preferable IGP or TE 532 metric than the link between the proxy node and the protector. The 533 ultimate goal is for a path computation algorithm, such as CSPF 534 (constrained shortest path first), LFA (RFC 5286) and MRT ([IP-LDP- 535 FRR-MRT]), to be able to compute the paths that meet the above 536 requirements. 538 4.3. Protection Models 540 There are two protection models based on the location of a protector. 541 A network MAY use either model, or a combination of both. 543 4.3.1. Co-located Protector 545 In this model, the protector is a backup PE that is directly 546 connected to the target CE via a backup AC, or it is a backup S-PE on 547 a backup PW. That is, the protector is co-located with the backup 548 (S-)PE. Examples of this model have been introduced in Figure 4, 549 Figure 5 and Figure 6 in Section 4.1. 551 In egress AC protection and egress PE node protection, when a 552 protector receives traffic from the PLR, it forwards the traffic to 553 the CE via the backup AC. This is shown in Figure 7, where PE2 is 554 the PLR for egress AC failure, P3 is the PLR for PE2 failure, and PE4 555 (the backup PE) is the protector. 557 |<-------------- PW1 --------------->| 559 - PE1 -------------- P1 ------- P3 ----- PE2 ---- 560 / PLR \ PLR \ 561 / \ | \ 562 CE1 bypass\ |bypass CE2 563 \ \ | / 564 \ \ | / 565 - PE3 -------------- P2 ---------------- PE4 ---- 566 protector 568 |<-------------- PW2 --------------->| 570 Figure 7 572 In S-PE node protection, when a protector receives traffic from the 573 PLR, it MUST forward the traffic via the next segment of the backup 574 PW. The T-PE of the backup PW MUST in turn forward the traffic to 575 the CE via a backup AC. This is shown in Figure 8, where P4 is the 576 PLR for SPE1 failure, and SPE2 (the backup S-PE) is the protector for 577 SPE1. 579 |<--------------- PW1 --------------->| 580 |<----- SEG1 ----->|<----- SEG2 ----->| 582 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 583 / PLR \ \ 584 / \ \ 585 CE1 bypass\ CE2 586 \ \ / 587 \ \ / 588 - TPE3 --------------- SPE2 -------------- TPE4 - 589 protector 591 |<----- SEG3 ----->|<----- SEG4 ----->| 592 |<--------------- PW2 --------------->| 594 Figure 8 596 In the co-located protector model, the number of context identifiers 597 needed by a network is the number of distinct {primary PE, backup PE} 598 pairs. From the perspective of scalability, the model is suitable 599 for networks where the number of backup PEs for any given primary PE 600 is relatively small. 602 4.3.2. Centralized Protector 604 In this model, the protector is a dedicated P router or PE router 605 that serves the role. In egress AC protection and egress PE node 606 protection, the protector MAY or MAY NOT be a backup PE with a direct 607 connection to the target CE. In S-PE node protection, the protector 608 MAY or MAY NOT be a backup S-PE on the backup PW. 610 In egress AC protection and egress PE node protection, when the 611 protector receives traffic from the PLR, if the protector has a 612 direct connection (i.e. backup AC) to the CE, it MUST forward the 613 traffic to the CE via the backup AC, which is similar to Figure 7. 614 Otherwise, it MUST forward the traffic to a backup PE, which MUST 615 then forward the traffic to the CE via a backup AC. This is shown in 616 Figure 9, where the protector receives traffic from P3 (the PLR for 617 egress PE failure) or PE2 (the PLR for egress AC failure) and 618 forwards the traffic to PE4 (the backup PE). The protector may be 619 protecting other PWs as well, which is not shown in this figure for 620 clarity. 622 |<------------- PW1 --------------->| 624 - PE1 ------------- P1 ------- P3 ----- PE2 -- 625 / PLR \ PLR \ 626 / \ / \ 627 / bypass\ /bypass \ 628 / \ / \ 629 CE1 protector CE2 630 \ \ / 631 \ \ / 632 \ \ / 633 \ \ / 634 - PE3 ------------- P2 -----------------PE4 -- 636 |<------------- PW2 --------------->| 638 Figure 9 640 In S-PE node protection, when the protector receives traffic from the 641 PLR, if the protector is a backup S-PE of the backup PW, it MUST 642 forward the traffic via the next segment of the backup PW, and the 643 T-PE of the backup PW MUST forward the traffic to the CE via a backup 644 AC, which is similar to Figure 8. Otherwise, the protector MUST 645 first forward the traffic to the backup S-PE, which MUST then forward 646 the traffic via the next segment of the backup PW. Finally, the T-PE 647 of the backup PW MUST forward the traffic to the CE via a backup AC. 648 This is shown in Figure 10, where the protector forwards traffic to 649 SPE2 (the backup S-PE), SPE2 forwards the traffic to TPE4 via SEG4, 650 and TPE4 finally forwards traffic to CE2. The protector may be 651 protecting other PW segments as well, which is not shown in this 652 figure for clarity. 654 |<--------------- PW1 --------------->| 655 |<----- SEG1 ----->|<----- SEG2 ----->| 657 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 658 / PLR \ \ 659 / \ \ 660 / bypass\ \ 661 / \ \ 662 CE1 protector CE2 663 \ \ / 664 \ \ / 665 \ \ / 666 \ \ / 667 - TPE3 --------------- SPE2 -------------- TPE4 - 669 |<----- SEG3 ----->|<----- SEG4 ----->| 670 |<--------------- PW2 --------------->| 672 Figure 10 674 The centralized protector model provides the convenience for multiple 675 primary PEs to share one protector. Each primary PE MAY only need 676 the one protector to protect all of its PWs. From the perspective of 677 scalability, the number of context identifiers needed by a network 678 MAY be bound to the number of primary PEs. 680 4.4. Transport Tunnel 682 The ingress PE of a primary PW associates the PW with the primary 683 egress PE through LDP signaling. In addition, as mentioned in 684 Section 4.2.1, the ingress PE MUST associate the transport tunnel of 685 the PW with the context identifier of the {primary PE, protector}, 686 and set up or resolve the transport tunnel by using the context 687 identifier as destination. This not only ensures that PW traffic be 688 transported to the primary PE, but also facilitates bypass tunnel 689 establishment at PLR(s), as the context identifier implies the 690 identity of the protector as well. This is also the case for a 691 multi-segment PW, where the ingress PE and egress PE are T/S-PEs. 693 The association between the transport tunnel and the context 694 identifier at the ingress PE MAY be achieved by configuration or an 695 auto-discovery mechanism. In the later case, the ingress PE MAY 696 learn the context identifier from the primary (egress) PE, if the 697 primary PE advertises the context identifier as "third party next 698 hop" in IPv4/v6 Interface_ID TLV (RFC 3471, RFC 3472) in the LDP 699 Label Mapping message of the primary PW. 701 4.5. Bypass Tunnel 703 A PLR may protect multiple PWs associated with one or multiple pairs 704 of {primary PE, protector}. The PLR MUST establish a bypass tunnel to 705 each protector for each distinct context identifier associated with 706 that protector. The destination of the bypass tunnel MUST be the 707 context identifier (Section 4.2.1). The PLR may derive the context 708 identifier from the destination of the transport tunnel that 709 traverses it. 711 For examples, in Figure 7 and Figure 9, a bypass tunnel is 712 established from PE2 (PLR for egress AC failure) to the protector, 713 and another bypass tunnel is established from P3 (PLR for egress node 714 failure) to the protector. In Figure 8 and Figure 10, a bypass 715 tunnel is established from P4 (PLR for S-PE failure) to the 716 protector. 718 During local repair, the PLR reroutes traffic to the protector 719 through a bypass tunnel with PW label intact in the packets. This 720 normally involves pushing a label to the label stack, if the bypass 721 tunnel is an MPLS tunnel, or pushing an IP header to the packets, if 722 the bypass tunnel is an IP tunnel. The protector MUST in turn 723 forward the traffic based on the PW label. To achieve such kind of 724 forwarding, the protector MUST rely on the bypass tunnel as a context 725 to determine the primary PE's label space. If the bypass tunnel is 726 an MPLS tunnel, the protector MUST have assigned a non-reserved label 727 to the bypass tunnel during the establishment of the bypass tunnel, 728 and hence this label can serve as the context. If the bypass tunnel 729 is an IP tunnel, the protector can simply rely on the context 730 identifier carried as the destination address in IP header. 732 A bypass tunnel MUST have the property that it is not affected by the 733 topology changes caused by the failure. Therefore, it can be used to 734 transmit traffic for local repair. It SHOULD remain effective, until 735 the traffic is moved to another fully functional egress AC, PW and/or 736 transport tunnel. 738 4.6. Forwarding State on Protector 740 A protector MUST learn PW labels from all the primary PEs that it 741 protects (Section 5.2), and maintain the PW labels in respective 742 label spaces of the primary PEs. In the control plane, a label space 743 is identified by the context identifier of a pair of {primary PE, 744 protector}. In the forwarding plane, it is indicated by the bypass 745 tunnel(s) destined for the context identifier. 747 4.6.1. Examples of Co-located Protector 748 In Figure 7, PE4 is a co-located protector that protects PW1 against 749 egress AC failure and egress node failure. It maintains a label 750 space for PE2, which is identified by the context identifier of {PE2, 751 PE4}. It learns PW1's label from PE2, and installs an forwarding 752 entry for the label in that label space. The nexthop of the 753 forwarding entry indicates a label pop with outgoing interface 754 pointing to the backup AC CE2-PE4. 756 In Figure 8, SPE2 is a co-located protector that protects PW1 against 757 S-PE failure. It maintains a label space for SPE1, which is 758 identified by the context identifier of {SPE1, SPE2}. It learns 759 SEG1's label from SPE1, and installs a forwarding entry in the label 760 space. The nexthop of the forwarding entry indicates a label swap to 761 SEG4's label. 763 4.6.2. Examples of Centralized Protector 765 In the centralized protector model, for each primary PW of which the 766 protector is not a backup (S-)PE, the protector MUST also learn the 767 label of the backup PW from the backup (S-)PE (Section 5.3). This is 768 the backup (S-)PE that the protector will forward traffic to. The 769 protector MUST install a forwarding entry with label swap from the 770 primary PW's label to the backup PW's label. 772 In Figure 9, the protector is a centralized protector that protects 773 PW1 against egress AC failure and egress node failure. It maintains 774 a label space for PE2, which is identified by the context identifier 775 of {PE2, protector}. It learns PW1's label from PE2, and PW2's label 776 from PE4. It installs a forwarding entry for PW1's label in the 777 label space. The nexthop of the forwarding entry indicates a label 778 swap to PW2's label. 780 In Figure 10, the protector is a centralized protector that protects 781 the PW segment SEG1 of PW1 against the node failure of SPE1. It 782 maintains a label space for SPE1, which is identified by the context 783 identifier of {SPE1, protector}. It learns SEG1's label from SPE1, 784 and learns SEG3's label from SPE2. It installs a forwarding entry 785 for SEG1's label in the label space. The nexthop of the forwarding 786 entry indicates a label swap to SEG3's label. 788 5. LDP Extensions 790 As described in previous sections, a targeted LDP session MUST be 791 established between each pair of primary PE and protector. The 792 primary PE sends Label Mapping message over this session to advertise 793 primary PW labels to the protector. In the centralized protector 794 model, a targeted LDP session MUST also be established between a 795 backup (S-)PE and a protector. The backup PE sends Label Mapping 796 message over this session to advertise backup PW labels to the 797 protector. 799 To facilitate the procedures, this document defines a new "Protection 800 FEC Element" TLV. The Label Mapping messages of both the LDP 801 sessions above MUST carry this TLV to indicate the identity of a 802 primary PW. Specifically, in the centralized protector model, the 803 Protection FEC Element TLV advertised by a backup (S-)PE MUST match 804 the one advertised by the primary PE, so that the protector can 805 associate the primary PW's label with the backup PW's label, and 806 perform a label swap. 808 This document also defines the encoding of Capability Parameter TLV 809 (RFC 5561) for a new "Egress Protection Capability", to allow a 810 protector to announce its capability of processing the above 811 Protection FEC Element TLV and performing context specific label 812 switching for PW labels. 814 The procedures in this section are only applicable, if the protector 815 advertises the Egress Protection Capability, the primary PE supports 816 the advertisement of the Protection FEC Element TLV, and in the 817 centralized protector model, the backup PE also supports the 818 advertisement of the Protection FEC Element TLV. 820 5.1. Egress Protection Capability TLV 822 A protector MUST advertise the Egress Protection Capability TLV in 823 its Initialization message and Capability message, over the LDP 824 session with a primary PE. In the centralized protector model, the 825 protector MUST also advertise the TLV over the LDP session with a 826 backup PE. The TLV carries one or multiple context identifiers. To 827 the primary PE, the TLV SHOULD carry the context identifier of the 828 {primary PE, protector}. In the centralized protector model, the TLV 829 SHOULD carry to the backup PE multiple context identifiers, one for 830 each {primary PE, protector} where the backup PE serves as a backup 831 for the primary PE. This TLV SHOULD NOT be advertised by the primary 832 PE or the backup PE to the protector. 834 The processing of the Egress Protection Capability TLV by a receiving 835 router SHOULD follow the procedures defined in RFC 5561. In 836 particular, the router SHOULD advertise PW information to the 837 protector by using the Protection FEC Element TLV, only after it has 838 received the Egress Protection Capability TLV from the protector. It 839 SHOULD validate each context identifier included in the TLV, and 840 advertise the information of only those PWs that are associated with 841 the context identifier. It SHOULD withdraw previously advertised 842 Protection FEC TLVs, when the protector has withdrawn a previously 843 advertised context identifier or the entire Egress Protection 844 Capability TLV via Capability message. 846 The encoding of the Egress Protection Capability TLV is defined as 847 below. It conforms to the format of Capability Parameter TLV 848 specified in RFC 5561. 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 |U|F| Egress Protection (TBD) | Length | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 |S| Reserved | | 856 +-+-+-+-+-+-+-+-+ | 857 | | 858 ~ Capability Data = context identifier(s) ~ 859 | | 860 | +-+-+-+-+-+-+-+-+ 861 | | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 Figure 11 866 The U-bit MUST be set to 1 so that a receiver MUST silently ignore 867 this TLV if unknown to it, and continue processing the rest of the 868 message. 870 The F-bit MUST be set to 0 since this TLV is sent only in 871 Initialization and Capability messages, which are not forwarded. 873 The TLV Code Point is TBD. It needs to be assigned by IANA. 875 The S-bit indicates whether the sender is advertising (S=1) or 876 withdrawing (S=0) the capability. 878 The "Capability Data" is encoded with the context identifier of the 879 {primary PE, protector}. 881 5.2. PW Label Distribution from Primary PE to Protector 883 A primary PE SHOULD advertise a primary PW's label to a protector by 884 sending a Label Mapping message. The message includes a Protection 885 FEC Element TLV (see Section 5.4 for encoding), and an Upstream- 886 Assigned Label TLV (RFC 6389) encoded with the PW's label. The 887 combination of the Protection FEC Element TLV and the PW label 888 represents the primary PE's forwarding state for the PW. The Label 889 Mapping message SHOULD also carry an IPv4/v6 Interface_ID TLV (RFC 890 6389, RFC 3471) encoded with the context identifier of the {primary 891 PE, protector}. 893 The protector that receives this Label Mapping message SHOULD install 894 a forwarding entry for the PW label in the label space identified by 895 the context identifier. The nexthop of the forwarding entry SHOULD 896 ensure packets to be sent towards the target CE via a backup AC or a 897 backup (S-)PE, depending on the protection scenario. The protector 898 SHOULD silently discard a Label Mapping message if the included 899 context identifier is unknown to it. 901 5.3. PW Label Distribution from Backup PE to Protector 903 In the centralized protector model, a backup PE SHOULD advertise a 904 backup PW's label to a protector by sending a Label Mapping message. 905 The message includes a Protection FEC Element TLV and a Generic Label 906 TLV encoded with the backup PW's label. This Protection FEC Element 907 MUST be identical to the Protection FEC Element TLV that the primary 908 PE advertises to the protector (Section 5.2). The context identifier 909 SHOULD NOT be encoded in Interface_ID TLV in this message. 911 The protector that receives this Label Mapping message SHOULD 912 associate the backup PW with the primary PW, based on the common 913 Protection FEC Element TLV. It SHOULD distinguish between the Label 914 Mapping message from the primary PE and the Label Mapping message 915 from the backup PE based on the respective presence and absence of 916 context identifier in Interface_ID TLV. It SHOULD install a 917 forwarding entry for the primary PW's label in the label space 918 identified by the context identifier. The nexthop of the forwarding 919 entry SHOULD indicate a label swap to the backup PW's label, followed 920 by a label push or IP header push for a transport tunnel to the 921 backup PE. 923 5.4. Protection FEC Element TLV 925 The Protection FEC Element TLV has type 0x83. Its format is defined 926 as below: 928 0 1 2 3 929 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 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | Type(0x83) | Reserved | Encoding Type | Length | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | | 934 | | 935 ~ PW Information ~ 936 | | 937 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Figure 12 943 - Encoding Type 945 Type of format that PW Information field is encoded. 947 - Length 949 Length of PW Information field in octets. 951 - PW Information 953 Field of variable length that specifies a PW 955 For Encoding Type, 1 is defined for the PWid FEC Element format, and 956 2 is defined for the Generalized PWid FEC Element format (RFC 4447). 958 5.4.1. Encoding Format for PWid 959 0 1 2 3 960 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 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Type(0x83) | Reserved | Enc Type(1) | Length(16) | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Ingress PE Address | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Egress PE Address | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Group ID | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | PW ID | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 |C| PW Type | Reserved | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 Figure 13 977 - Ingress PE Address 979 IP address of the ingress PE of PW. 981 - Egress PE Address 983 IP address of the egress PE of PW. 985 - Group ID 987 An arbitrary 32-bit value that represents a group of PWs and that 988 is used to create groups in the PW space. 990 - PW ID 992 A non-zero 32-bit connection ID that, together with the PW Type 993 field, identifies a particular PW. 995 - Control word bit (C) 997 A bit that flags the presence of a control word on this PW. If C 998 = 1, control word is present; If C = 0, control word is not 999 present. 1001 - PW Type 1003 A 15-bit quantity that represents the type of PW. 1005 5.4.2. Encoding Format for Generalized PWid 1006 0 1 2 3 1007 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 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | Type(0x83) | Reserved | Enc Type(2) | Length | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Ingress PE Address | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Egress PE Address | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 |C| PW Type | Reserved | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | AGI Type | Length | Value | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 ~ AGI Value (contd.) ~ 1020 | | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | AII Type | Length | Value | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 ~ SAII Value (contd.) ~ 1025 | | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | AII Type | Length | Value | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 ~ TAII Value (contd.) ~ 1030 | | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 Figure 14 1035 - Ingress PE Address 1037 IP address of the ingress PE of PW. 1039 - Egress PE Address 1041 IP address of the egress PE of PW. 1043 - Control word bit (C) 1045 A bit that flags the presence of a control word on this PW. If C 1046 = 1, control word is present; If C = 0, control word is not 1047 present. 1049 - PW Type 1051 A 15-bit quantity that represents the type of PW. 1053 - AGI Type, Length, Value, AGI Value 1054 Attachment Group Identifier of PW. 1056 - SAII Type, Length, Value, SAII Value 1058 Source Attachment Individual Identifier of PW. 1060 - TAII Type, Length, Value, TAII Value 1062 Target Attachment Individual Identifier of PW. 1064 6. Revertive Behavior 1066 Subsequent to local repair, there are three strategies for the 1067 network to restore traffic to a fully functional PW. 1069 o Global revertive mode 1071 If the ingress CE is multi-homed (Figure 1), it MAY switch the 1072 traffic to a backup AC which is bound to a backup PW. 1073 Alternatively, if the ingress PE hosts a backup PW (Figure 2), the 1074 ingress PE MAY switch the traffic to the backup PW. These 1075 procedures are referred to as global repair. Possible triggers of 1076 a global repair include PW status, OAM, and BFD. 1078 o Control plane revertive mode 1080 In egress PE node protection and S-PE node protection, it is 1081 possible that the failure is limited to the link between the PLR 1082 and the primary (S-)PE, whereas the primary (S-)PE is still up. 1083 In this case, the PLR or an upstream router along the transport 1084 tunnel MAY reroute the tunnel around the failed link via an 1085 alternative path. Thus, the transport tunnel can continue to be 1086 used to carry the PW traffic to the primary (S-)PE. This 1087 procedure is driven by control plane convergence, and is referred 1088 to as control plane repair. 1090 o Local revertive mode 1092 The PLR MAY move traffic back to the primary PW, after the failure 1093 is resolved. In egress AC protection, upon detecting that the 1094 primary AC is restored, the PLR MAY start forwarding traffic over 1095 the AC again. Likewise, in egress PE node protection and S-PE 1096 node protection, upon detecting that the primary PE is restored, 1097 the PLR MAY re-establish the primary transport tunnel through the 1098 primary PE, and move the traffic from the bypass tunnel back to 1099 the transport tunnel. These procedures are referred to as local 1100 reversion. 1102 The fast protection mechanism in this document SHOULD be used in 1103 tandem with the global revertive mode. Particularly in the case of 1104 egress (S-)PE failure, if the ingress PE or the protector loses 1105 communication with the (S-)PE for an extensive period of time, the 1106 LDP session between them may go down. Consequently, the ingress PE 1107 may bring down the primary PW, or the protector may remove the 1108 forwarding entry of the primary PW label. In either case, the 1109 service will be disrupted. In other words, although the fast 1110 protection can temporarily repair traffic, control plane state may 1111 eventually be timed out if the failure persists. Therefore, it is 1112 recommended that the global revertive mode SHOULD be set up in 1113 advance, so that traffic can be moved to a fully functional backup PW 1114 shortly after the local repair. 1116 The control plane revertive mode may always happen as part of the 1117 convergence of control plane protocols. However, it is only 1118 applicable to the specific scenarios described above. 1120 The local revertive mode is optional. In the circumstances where the 1121 failure is caused by resource flapping, local reversion MAY be 1122 dampened to limit potential disruptions. Local revertive mode MAY be 1123 disabled completely by configuration. 1125 7. IANA Considerations 1127 This document defines the encoding of the Capability Parameter TLV 1128 for the new "Egress Protection Capability" in Section 5. This would 1129 require IANA to assign a TLV Code Point to it. 1131 This document defines a new LDP Protection FEC Element TLV in 1132 Section 5. IANA has assigned the type value 0x83 to it. 1134 8. Security Considerations 1136 The security considerations discussed in RFC 5036, RFC 5331, RFC 1137 3209, and RFC 4090 apply to this document. 1139 9. Acknowledgements 1141 This document leverages work done by Hannes Gredler, Yakov Rekhter, 1142 Minto Jeyananth and several others on MPLS edge protection. Thanks 1143 to Nischal Sheth, Bhupesh Kothari, and Kevin Wang for their 1144 contribution. Thanks to Yakov Rekhter and John E Drake for reviewing 1145 the document. Thanks to Andrew G Malis for valuable comments. 1147 10. References 1148 10.1. Normative References 1150 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1151 Edge (PWE3) Architecture", RFC 3985, March 2005. 1153 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 1154 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 1155 October 2009. 1157 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1158 Heron, "Pseudowire Setup and Maintenance Using the Label 1159 Distribution Protocol (LDP)", RFC 4447, April 2006. 1161 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1162 Label Assignment and Context-Specific Label Space", RFC 1163 5331, August 2008. 1165 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1166 Specification", RFC 5036, October 2007. 1168 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 1169 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 1171 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1172 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1173 Functional Specification", RFC 2205, September 1997. 1175 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1176 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1177 Tunnels", RFC 3209, December 2001. 1179 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 1180 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 1181 2005. 1183 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 1184 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 1186 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 1187 5714, January 2010. 1189 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1190 (GMPLS) Signaling Functional Description", RFC 3471, 1191 January 2003. 1193 [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- 1194 Protocol Label Switching (GMPLS) Signaling Constraint- 1195 based Routed Label Distribution Protocol (CR-LDP) 1196 Extensions", RFC 3472, January 2003. 1198 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1199 Label Switching Architecture", RFC 3031, January 2001. 1201 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1203 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1204 (BFD)", RFC 5880, June 2010. 1206 [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label 1207 Assignment for LDP", RFC 6389, November 2011. 1209 [IP-LDP-FRR-MRT] 1210 Atlas, A. and R. Kebler, "An Architecture for IP/LDP Fast- 1211 Reroute Using Maximally Redundant Trees", draft-ietf- 1212 rtgwg-mrt-frr-architecture (work in progress), 2011. 1214 10.2. Informative References 1216 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 1217 Networks", RFC 5920, July 2010. 1219 Authors' Addresses 1221 Yimin Shen 1222 Juniper Networks 1223 10 Technology Park Drive 1224 Westford, MA 01886 1225 USA 1227 Phone: +1 9785890722 1228 Email: yshen@juniper.net 1230 Rahul Aggarwal 1231 Arktan, Inc 1233 Email: raggarwa_1@yahoo.com 1234 Wim Henderickx 1235 Alcatel-Lucent 1236 Copernicuslaan 50 1237 2018 Antwerp 1238 Belgium 1240 Email: wim.henderickx@alcatel-lucent.be 1242 Yuanlong Jiang 1243 Huawei Technologies 1245 Email: jiangyuanlong@huawei.com