idnits 2.17.1 draft-ietf-pwe3-endpoint-fast-protection-01.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 (July 24, 2014) is 3558 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 1153, but no explicit reference was found in the text == Unused Reference: 'RFC5659' is defined on line 1156, but no explicit reference was found in the text == Unused Reference: 'RFC4447' is defined on line 1160, but no explicit reference was found in the text == Unused Reference: 'RFC5331' is defined on line 1164, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 1168, but no explicit reference was found in the text == Unused Reference: 'RFC5561' is defined on line 1171, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1178, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 1182, but no explicit reference was found in the text == Unused Reference: 'RFC5286' is defined on line 1186, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 1189, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 1192, but no explicit reference was found in the text == Unused Reference: 'RFC3472' is defined on line 1196, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 1201, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 1204, but no explicit reference was found in the text == Unused Reference: 'RFC5880' is defined on line 1206, but no explicit reference was found in the text == Unused Reference: 'RFC6389' is defined on line 1209, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 1219, 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: January 25, 2015 Arktan, Inc 6 Wim Henderickx 7 Alcatel-Lucent 8 Yuanlong Jiang 9 Huawei Technologies 10 July 24, 2014 12 PW Endpoint Fast Failure Protection 13 draft-ietf-pwe3-endpoint-fast-protection-01 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 January 25, 2015. 47 Copyright Notice 49 Copyright (c) 2014 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 and Failure Cases . . . . . . . . . . . . . 4 67 3.1. Single-Segment PW . . . . . . . . . . . . . . . . . . . . 4 68 3.2. Multi-Segment PW . . . . . . . . . . . . . . . . . . . . 6 69 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Local Repair and Protector . . . . . . . . . . . . . . . 8 71 4.2. Context Identifier . . . . . . . . . . . . . . . . . . . 11 72 4.2.1. Semantics . . . . . . . . . . . . . . . . . . . . . . 11 73 4.2.2. Advertisement and Path Computation . . . . . . . . . 12 74 4.3. Protection Models . . . . . . . . . . . . . . . . . . . . 12 75 4.3.1. Co-located Protector . . . . . . . . . . . . . . . . 13 76 4.3.2. Centralized Protector . . . . . . . . . . . . . . . . 14 77 4.4. Transport Tunnel . . . . . . . . . . . . . . . . . . . . 16 78 4.5. Bypass Tunnel . . . . . . . . . . . . . . . . . . . . . . 17 79 4.6. Forwarding State on Protector . . . . . . . . . . . . . . 17 80 4.6.1. Examples of Co-located Protector . . . . . . . . . . 18 81 4.6.2. Examples of Centralized Protector . . . . . . . . . . 18 82 5. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 18 83 5.1. Egress Protection Capability TLV . . . . . . . . . . . . 19 84 5.2. PW Label Distribution from Primary PE to Protector . . . 20 85 5.3. PW Label Distribution from Backup PE to Protector . . . . 21 86 5.4. Protection FEC Element TLV . . . . . . . . . . . . . . . 21 87 5.4.1. Encoding Format for PWid . . . . . . . . . . . . . . 22 88 5.4.2. Encoding Format for Generalized PWid . . . . . . . . 24 89 6. Revertive Behavior . . . . . . . . . . . . . . . . . . . . . 25 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 95 10.2. Informative References . . . . . . . . . . . . . . . . . 28 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 98 1. Introduction 100 Per RFC 3985, RFC 4447 and RFC 5659, a pseudowire (PW) or PW segment 101 can be thought of as a connection between a pair of forwarders hosted 102 by two PEs, carrying an emulated layer-2 service over a packet 103 switched network (PSN). In the single-segment PW (SS-PW) case, a 104 forwarder binds a PW to an attachment circuit (AC). In the multi- 105 segment PW (MS-PW) case, a forwarder on a terminating PE (T-PE) binds 106 a PW segment to an AC, while a forwarder on a switching PE (S-PE) 107 binds one PW segment to another PW segment. In each direction 108 between the PEs, PW packets are transported by a PSN tunnel, which is 109 called a transport tunnel. 111 In order to protect the layer-2 service against network failures, it 112 is necessary to protect every link and node along the entire data 113 path. For the traffic in a given direction, this include ingress AC, 114 ingress (T-)PE, intermediate routers of transport tunnel, S-PEs, 115 egress (T-)PE, and egress AC. To minimize service disruption upon a 116 failure, it is also desirable that each of these components is 117 protected by a fast protection mechanism based on local repair. Such 118 a mechanism generally involves a bypass path that is pre-computed and 119 pre-installed on the router upstream adjacent to an anticipated 120 failure. The bypass path has the property that it can guide traffic 121 around the failure, while remaining unaffected by the topology 122 changes resulting from the failure. Thus, when the failure occurs, 123 the router can invoke the bypass path to achieve fast restoration for 124 the service. 126 Today, fast protection against ingress AC failure and ingress (T-)PE 127 failure is achievable by using a multi-homed CE and redundant PWs. 128 Fast protection against failure of intermediate router is achievable 129 through RSVP fast-reroute (RFC 4090) or IP/LDP fast-reroute (RFC 130 5714, RFC 5286). However, there is a lack of equivalent mechanism 131 against egress AC failure, egress (T-)PE failure, and S-PE failure. 132 For these failures, service restoration has to rely on global repair 133 or control plane repair. Global repair is normally driven by ingress 134 CE or ingress (T-)PE, and dependent on PW status notification or end- 135 to-end OAM. Control plane repair is dependent on protocol 136 convergence. Therefore, both mechanisms are relatively slow in 137 reacting to the failures and restoring traffic. 139 This document is intended to serve the above need. It specifies a 140 fast protection mechanism based on local repair technique to protect 141 PWs against the following egress endpoint failures. 143 a. Egress AC failure. 145 b. Egress PE failure: Node failure of an egress PE of an SS-PW, or a 146 T-PE of an MS-PW. 148 c. Switching PE failure: Node failure of an S-PE of an MS-PW. 150 The mechanism is applicable to LDP signaled PWs. It is relevant to 151 networks with redundant PWs and multi-homed CEs. It is designed on 152 the basis of MPLS upstream label assignment and context-specific 153 label switching (RFC 5331). Fast protection refers to the ability to 154 restore traffic upon a failure in the order of tens of milliseconds. 155 This is achieved by establishing local protection at the router 156 upstream adjacent to an anticipated failure. Compared with the 157 existing global repair and control plane repair mechanisms, this 158 mechanism can provide faster service restoration. However, it is 159 intended to complement those mechanisms, rather than replacing them 160 in any way. 162 2. Specification of Requirements 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119. 168 3. Reference Models and Failure Cases 170 This document refers to the following topologies to describe failure 171 scenarios and protection procedures. These topologies involve multi- 172 homed CEs and redundant PWs, which are commonly seen in networks with 173 global repair mechanisms. The mechanism in this document intends to 174 use these topologies for local repair purposes. This SHALL enable 175 local repair and global repair to work in tandem to achieve broader 176 coverage of protection for services. 178 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 227 Primary PE: PE2 229 Primary AC: CE2-PE2 231 Backup PW: PW2 233 Backup PE: PE4 235 Backup AC: CE2-PE4 237 In this case, an egress AC failure refers to the failure of the AC 238 CE2-PE2. An egress node failure refers to the failure of PE2. 240 The backup PE, backup PW and backup AC may be used to carry traffic 241 after a PW endpoint failure, when CE1 and CE2 switches traffic to PW2 242 in local repair or global repair, as described later in this 243 document. 245 |<-------------- PW1 --------------->| 247 ------------- P1 ---------------- PE2 - 248 / \ 249 / \ 250 CE1 -- PE1 CE2 251 \ / 252 \ / 253 ------------- P2 ---------------- PE4 - 255 |<-------------- PW2 --------------->| 257 Figure 2 259 Figure 2 shows another possible scenario, where CE1 is single-homed 260 to PE1, while CE2 remains multi-homed to PE2 and PE4. From the 261 perspective of egress protection for the traffic from CE1 to CE2, 262 this topology is not much different than Figure 1. However, for the 263 traffic in the direction from CE2 to CE1, PE1 must anticipate traffic 264 on both PW1 and PW2, and sends it to CE1 over the AC CE1-PE1. 266 3.2. Multi-Segment PW 267 |<--------------- PW1 --------------->| 268 |<----- SEG1 ----->|<----- SEG2 ----->| 270 - TPE1 -------------- SPE1 --------------- TPE2 - 271 / \ 272 / \ 273 CE1 CE2 274 \ / 275 \ / 276 - TPE3 -------------- SPE2 --------------- TPE4 - 278 |<----- SEG3 ----->|<----- SEG4 ----->| 279 |<--------------- PW2 --------------->| 281 Figure 3 283 Figure 3 shows a topology that is similar to Figure 1 but in an MS-PW 284 environment. PW1 and PW2 are both MS-PWs. PW1 is established 285 between TPE1 and TPE2, and switched between segments SEG1 and SEG2 at 286 SPE1. PW2 is established between TPE3 and TPE4, and switched between 287 segments SEG3 and SEG4 at SPE2. CE1 is multi-homed to TPE1 and TPE3. 288 CE2 is multi-homed to TPE2 and TPE4. The transport tunnels of the PW 289 segments are not shown in this figure for clarity. 291 In this document, the following primary and backup roles are assigned 292 for the traffic going from CE1 to CE2: 294 Primary PW: PW1 296 Primary T-PE: TPE2 298 Primary S-PE: SPE1 300 Primary AC: CE2-TPE2 302 Backup PW: PW2 304 Backup T-PE: TPE4 306 Backup S-PE: SPE2 308 Backup AC: CE2-TPE4 310 In this case, an egress AC failure refers to the failure of the AC 311 CE2-TPE2. An egress node failure refers to the failure of TPE2. An 312 S-PE failure refers to the failure of SPE1. 314 The backup T-PE, backup PW and backup AC are used for protecting the 315 primary PW against egress AC failure and egress node failure. The 316 backup S-PE and the backup PW are used for protecting the primary PW 317 against S-PE failure, as described later in this document. 319 For consistency with the SS-PW scenario, primary T-PEs and a primary 320 S-PEs may simply be referred to as primary PEs in this document, 321 where specifics is not required. Similarly, backup T-PEs and backup 322 S-PEs may be referred to as backup PEs. 324 4. Theory of Operation 326 The fast protection mechanism in this document provides three types 327 of protection for PWs, corresponding to the three types of failures 328 described in Section 1. 330 a. Egress AC protection 332 b. Egress (T-)PE node protection 334 c. S-PE node protection 336 The mechanism assumes a multi-homed CE with connectivity to a primary 337 PE and a backup PE, and the existence of a backup PW in the network. 338 In S-PE node protection, it also assumes the existence of a backup 339 S-PE on the backup PW. 341 4.1. Local Repair and Protector 343 The mechanism relies on local repair to be performed by routers 344 upstream adjacent to failures. Each of these routers is referred to 345 as a "point of local repair" (PLR). A PLR MUST be able to detect a 346 failure by using a rapid mechanism, such as physical layer failure 347 detection, Bidirectional Failure Detection (BFD) (RFC 5880), etc. In 348 anticipation of the failure, the PLR MUST also pre-establish a bypass 349 PSN tunnel to a "protector", and pre-install a bypass route in the 350 data plane. The bypass tunnel MUST have the property that it will 351 not be affected by the topology changes in the event of the failure. 352 Upon detecting the failure, the PLR MUST invoke the bypass route in 353 the data plane, and reroute PW traffic to the protector through the 354 bypass tunnel. The protector MUST in turn send the traffic to the 355 target CE. This procedure is referred to as local repair. 357 Different routers may serve as PLR and protector in different 358 scenarios. 360 o In egress AC protection, the PLR is the primary PE that terminates 361 the primary PW and hosts the primary AC, and the protector is the 362 backup PE (Figure 4). 364 |<-------------- PW1 --------------->| 366 - PE1 -------------- P1 ---------------- PE2 - 367 / PLR \ 368 / | \ 369 CE1 bypass| CE2 370 \ | / 371 \ | / 372 - PE3 -------------- P2 ---------------- PE4 - 373 protector 375 |<-------------- PW2 --------------->| 377 Figure 4 379 o In egress PE node protection, the PLR is the penultimate hop 380 router of the transport tunnel of the primary PW, and the 381 protector is the backup PE (Figure 5). 383 |<-------------- PW1 --------------->| 385 - PE1 -------------- P1 ------- P3 ----- PE2 - 386 / PLR \ \ 387 / \ \ 388 CE1 bypass\ CE2 389 \ \ / 390 \ \ / 391 - PE3 -------------- P2 ---------------- PE4 - 392 protector 394 |<-------------- PW2 --------------->| 396 Figure 5 398 o In S-PE node protection, the PLR is the penultimate hop router of 399 the transport tunnel of the primary PW segment, and the protector 400 is the backup S-PE (Figure 6). 402 |<--------------- PW1 --------------->| 403 |<----- SEG1 ----->|<----- SEG2 ----->| 405 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 406 / PLR \ \ 407 / \ \ 408 CE1 bypass\ CE2 409 \ \ / 410 \ \ / 411 - TPE3 --------------- SPE2 -------------- TPE4 - 412 protector 414 |<----- SEG3 ----->|<----- SEG4 ----->| 415 |<--------------- PW2 --------------->| 417 Figure 6 419 A PLR can realize its role based on configuration or the signaling of 420 transport tunnel. For example, in the case where the transport 421 tunnel is signaled by RSVP, the penultimate hop router could realize 422 that it is the PLR for egress (T-)PE or S-PE failure based on the RRO 423 in Resv message, which should indicate that the router is one hop 424 away from the PE. The detail of how this could be achieved on a per- 425 protocol basis is out of the scope of this document. 427 In all scenarios, when a PLR reroutes traffic through a bypass tunnel 428 to a protector during local repair, it MUST keep the label of the 429 primary PW intact in the packets. This obviates the need for the PLR 430 to maintain bypass routes on a per-PW basis, and allows a single 431 bypass tunnel to carry traffic for multiple PWs. 433 The procedure also requires that the protector SHOULD be able to 434 forward the traffic based on a PW label that is assigned by the 435 primary PE, and ensure the traffic to eventually reach the target CE. 436 From the protector's perspective, this PW label is an upstream 437 assigned label (RFC 5331). To accomplish this, the protector SHOULD 438 learning the PW label from the primary PE prior to the failure, and 439 install proper forwarding state for the PW label in a dedicated label 440 space for the primary PE. During local repair, the protector SHOULD 441 perform PW label lookup in this label space. 443 The above examples have shown the scenarios where the protectors are 444 backup (T/S-)PEs. In other scenarios, a protector may be a dedicated 445 router that assumes such role, separate from the backup (T/S-)PE of a 446 primary PW. During local repair, the PLR MUST still reroute traffic 447 to the protector through a bypass tunnel. The protector MUST in turn 448 send the traffic to the backup (T/S-)PE, which MUST then send the 449 traffic to the target CE via a backup AC or a backup PW segment. 450 More detail will be described in Section 4.3. 452 4.2. Context Identifier 454 A protector MAY protect multiple primary PEs. The protector MUST 455 maintain a separate label space for each primary PE. Likewise, the 456 PWs terminated on a primary PE MAY be protected by multiple 457 protectors, each for a subset of the PWs. In any case, a given 458 primary PW SHOULD be associated with one and only one pair of 459 {primary PE, protector}. 461 An IPv4/v6 address is assigned to each ordered pair of {primary PE, 462 protector} to facilitate protection establishment. This address is 463 referred to as a "context identifier". It MUST be globally unique, 464 or unique in the address space of the network where the primary PE 465 and the protector reside. 467 4.2.1. Semantics 469 The semantics of a context identifier is twofold. 471 o It identifies a primary PE and an associated protector. In other 472 words, it identifies a primary PE on a per protector basis. A 473 given primary PE may be protected by multiple protectors, each for 474 a subset of the primary PWs terminated on the primary PE. A 475 distinct context identifier MUST be assigned to the primary PE and 476 each protector. 478 For each primary PW, its ingress PE MUST set up or resolve a 479 transport tunnel with destination as the context identifier of the 480 {primary PE, protector}, rather than a private IP address of the 481 primary PE. This not only allows the transport tunnel to reach 482 the primary PE, but also conveys the identity of the protector to 483 the PLR(s) along the transport tunnel. Each PLR can in turn use 484 this information to set up a bypass tunnel to the protector 485 without relying on local configuration. 487 o It indentifies the primary PE's label space on the protector. The 488 protector may protect PWs for multiple primary PEs. For each 489 primary PE, it MUST maintain a separate label space to store the 490 PW labels assigned by that primary PE. It MUST associate a PW 491 label with a label space via the context identifier of the 492 {primary PE, protector}, as described below. 494 In addition to the normal LDP PW signaling, the primary PE MUST 495 have a targeted LDP session with the protector, and advertise PW 496 labels to the protector via LDP Label Mapping messages (See 497 Section 5 for detail). The primary PE MUST attach the context 498 identifier to each message. Upon receiving the message, the 499 protector MUST install the advertised PW label in the label space 500 identified by the context identifier. 502 When a PLR sets up or resolve a bypass tunnel to the protector, it 503 MUST set the destination to the context identifier, rather than a 504 private IP address of the protector. Once established, the bypass 505 tunnel, with either its MPLS label or IP tunnel destination 506 address, is used as the identifier of label space. On the 507 protector, all PW packets received on the bypass tunnel MUST be 508 forwarded based on a label lookup in that label space. 510 4.2.2. Advertisement and Path Computation 512 Using a context identifier as destination for both transport tunnel 513 and bypass tunnel requires both the primary PE and the protector to 514 advertise the context identifier via IGP as an IP address reachable 515 through both routers in routing domain and/or TE domain. This 516 imposes the following requirements on path computation for these 517 tunnels. 519 o For the transport tunnel, the ingress PE MUST choose the primary 520 PE as the actual endpoint. 522 o For the bypass tunnel, the PLR MUST choose the protector as the 523 actual endpoint. In egress (T-)PE node protection and S-PE node 524 protection, the bypass tunnel MUST avoid the primary (S-)PE. 526 The detail of how the primary PE and the protector may advertise a 527 context identifier is independent of this mechanism and out of the 528 scope of this document. One approach would be to advertise it as a 529 virtual proxy node connected to both routers, with the link between 530 the proxy node and the primary PE having a more preferable IGP or TE 531 metric than the link between the proxy node and the protector. The 532 ultimate goal is for a path computation algorithm, such as CSPF 533 (constrained shortest path first), LFA (RFC 5286) and MRT ([IP-LDP- 534 FRR-MRT]), to be able to compute the paths that meet the above 535 requirements. 537 4.3. Protection Models 539 There are two protection models based on the location of a protector. 540 A network MAY use either model, or a combination of both. 542 4.3.1. Co-located Protector 544 In this model, the protector is a backup PE that is directly 545 connected to the target CE via a backup AC, or it is a backup S-PE on 546 a backup PW. That is, the protector is co-located with the backup 547 (S-)PE. Examples of this model have been introduced in Figure 4, 548 Figure 5 and Figure 6 in Section 4.1. 550 In egress AC protection and egress PE node protection, when a 551 protector receives traffic from the PLR, it forwards the traffic to 552 the CE via the backup AC. This is shown in Figure 7, where PE2 is 553 the PLR for egress AC failure, P3 is the PLR for PE2 failure, and PE4 554 (the backup PE) is the protector. 556 |<-------------- PW1 --------------->| 558 - PE1 -------------- P1 ------- P3 ----- PE2 ---- 559 / PLR \ PLR \ 560 / \ | \ 561 CE1 bypass\ |bypass CE2 562 \ \ | / 563 \ \ | / 564 - PE3 -------------- P2 ---------------- PE4 ---- 565 protector 567 |<-------------- PW2 --------------->| 569 Figure 7 571 In S-PE node protection, when a protector receives traffic from the 572 PLR, it MUST forward the traffic via the next segment of the backup 573 PW. The T-PE of the backup PW MUST in turn forward the traffic to 574 the CE via a backup AC. This is shown in Figure 8, where P4 is the 575 PLR for SPE1 failure, and SPE2 (the backup S-PE) is the protector for 576 SPE1. 578 |<--------------- PW1 --------------->| 579 |<----- SEG1 ----->|<----- SEG2 ----->| 581 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 582 / PLR \ \ 583 / \ \ 584 CE1 bypass\ CE2 585 \ \ / 586 \ \ / 587 - TPE3 --------------- SPE2 -------------- TPE4 - 588 protector 590 |<----- SEG3 ----->|<----- SEG4 ----->| 591 |<--------------- PW2 --------------->| 593 Figure 8 595 In the co-located protector model, the number of context identifiers 596 needed by a network is the number of distinct {primary PE, backup PE} 597 pairs. From the perspective of scalability, the model is suitable 598 for networks where the number of backup PEs for any given primary PE 599 is relatively small. 601 4.3.2. Centralized Protector 603 In this model, the protector is a dedicated P router or PE router 604 that serves the role. In egress AC protection and egress PE node 605 protection, the protector MAY or MAY NOT be a backup PE with a direct 606 connection to the target CE. In S-PE node protection, the protector 607 MAY or MAY NOT be a backup S-PE on the backup PW. 609 In egress AC protection and egress PE node protection, when the 610 protector receives traffic from the PLR, if the protector has a 611 direct connection (i.e. backup AC) to the CE, it MUST forward the 612 traffic to the CE via the backup AC, which is similar to Figure 7. 613 Otherwise, it MUST forward the traffic to a backup PE, which MUST 614 then forward the traffic to the CE via a backup AC. This is shown in 615 Figure 9, where the protector receives traffic from P3 (the PLR for 616 egress PE failure) or PE2 (the PLR for egress AC failure) and 617 forwards the traffic to PE4 (the backup PE). The protector may be 618 protecting other PWs as well, which is not shown in this figure for 619 clarity. 621 |<------------- PW1 --------------->| 623 - PE1 ------------- P1 ------- P3 ----- PE2 -- 624 / PLR \ PLR \ 625 / \ / \ 626 / bypass\ /bypass \ 627 / \ / \ 628 CE1 protector CE2 629 \ \ / 630 \ \ / 631 \ \ / 632 \ \ / 633 - PE3 ------------- P2 -----------------PE4 -- 635 |<------------- PW2 --------------->| 637 Figure 9 639 In S-PE node protection, when the protector receives traffic from the 640 PLR, if the protector is a backup S-PE of the backup PW, it MUST 641 forward the traffic via the next segment of the backup PW, and the 642 T-PE of the backup PW MUST forward the traffic to the CE via a backup 643 AC, which is similar to Figure 8. Otherwise, the protector MUST 644 first forward the traffic to the backup S-PE, which MUST then forward 645 the traffic via the next segment of the backup PW. Finally, the T-PE 646 of the backup PW MUST forward the traffic to the CE via a backup AC. 647 This is shown in Figure 10, where the protector forwards traffic to 648 SPE2 (the backup S-PE), SPE2 forwards the traffic to TPE4 via SEG4, 649 and TPE4 finally forwards traffic to CE2. The protector may be 650 protecting other PW segments as well, which is not shown in this 651 figure for clarity. 653 |<--------------- PW1 --------------->| 654 |<----- SEG1 ----->|<----- SEG2 ----->| 656 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 657 / PLR \ \ 658 / \ \ 659 / bypass\ \ 660 / \ \ 661 CE1 protector CE2 662 \ \ / 663 \ \ / 664 \ \ / 665 \ \ / 666 - TPE3 --------------- SPE2 -------------- TPE4 - 668 |<----- SEG3 ----->|<----- SEG4 ----->| 669 |<--------------- PW2 --------------->| 671 Figure 10 673 The centralized protector model provides the convenience for multiple 674 primary PEs to share one protector. Each primary PE MAY only need 675 the one protector to protect all of its PWs. From the perspective of 676 scalability, the number of context identifiers needed by a network 677 MAY be bound to the number of primary PEs. 679 4.4. Transport Tunnel 681 The ingress PE of a primary PW associates the PW with the primary 682 egress PE through LDP signaling. In addition, as mentioned in 683 Section 4.2.1, the ingress PE MUST associate the transport tunnel of 684 the PW with the context identifier of the {primary PE, protector}, 685 and set up or resolve the transport tunnel by using the context 686 identifier as destination. This not only ensures that PW traffic be 687 transported to the primary PE, but also facilitates bypass tunnel 688 establishment at PLR(s), as the context identifier implies the 689 identity of the protector as well. This is also the case for a 690 multi-segment PW, where the ingress PE and egress PE are T/S-PEs. 692 The association between the transport tunnel and the context 693 identifier at the ingress PE MAY be achieved by configuration or an 694 auto-discovery mechanism. In the later case, the ingress PE MAY 695 learn the context identifier from the primary (egress) PE, if the 696 primary PE advertises the context identifier as "third party next 697 hop" in IPv4/v6 Interface_ID TLV (RFC 3471, RFC 3472) in the LDP 698 Label Mapping message of the primary PW. 700 4.5. Bypass Tunnel 702 A PLR may protect multiple PWs associated with one or multiple pairs 703 of {primary PE, protector}. The PLR MUST establish a bypass tunnel to 704 each protector for each distinct context identifier associated with 705 that protector. The destination of the bypass tunnel MUST be the 706 context identifier (Section 4.2.1). The PLR may derive the context 707 identifier from the destination of the transport tunnel that 708 traverses it. 710 For examples, in Figure 7 and Figure 9, a bypass tunnel is 711 established from PE2 (PLR for egress AC failure) to the protector, 712 and another bypass tunnel is established from P3 (PLR for egress node 713 failure) to the protector. In Figure 8 and Figure 10, a bypass 714 tunnel is established from P4 (PLR for S-PE failure) to the 715 protector. 717 During local repair, the PLR reroutes traffic to the protector 718 through a bypass tunnel with PW label intact in the packets. This 719 normally involves pushing a label to the label stack, if the bypass 720 tunnel is an MPLS tunnel, or pushing an IP header to the packets, if 721 the bypass tunnel is an IP tunnel. The protector MUST in turn 722 forward the traffic based on the PW label. To achieve such kind of 723 forwarding, the protector MUST rely on the bypass tunnel as a context 724 to determine the primary PE's label space. If the bypass tunnel is 725 an MPLS tunnel, the protector MUST have assigned a non-reserved label 726 to the bypass tunnel during the establishment of the bypass tunnel, 727 and hence this label can serve as the context. If the bypass tunnel 728 is an IP tunnel, the protector can simply rely on the context 729 identifier carried as the destination address in IP header. 731 A bypass tunnel MUST have the property that it is not affected by the 732 topology changes caused by the failure. Therefore, it can be used to 733 transmit traffic for local repair. It SHOULD remain effective, until 734 the traffic is moved to another fully functional egress AC, PW and/or 735 transport tunnel. 737 4.6. Forwarding State on Protector 739 A protector MUST learn PW labels from all the primary PEs that it 740 protects (Section 5.2), and maintain the PW labels in respective 741 label spaces of the primary PEs. In the control plane, a label space 742 is identified by the context identifier of a pair of {primary PE, 743 protector}. In the forwarding plane, it is indicated by the bypass 744 tunnel(s) destined for the context identifier. 746 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 1007 0 1 2 3 1008 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 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | Type(0x83) | Reserved | Enc Type(2) | Length | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | Ingress PE Address | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Egress PE Address | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 |C| PW Type | Reserved | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | AGI Type | Length | Value | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 ~ AGI Value (contd.) ~ 1021 | | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | AII Type | Length | Value | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 ~ SAII Value (contd.) ~ 1026 | | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | AII Type | Length | Value | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 ~ TAII Value (contd.) ~ 1031 | | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 Figure 14 1036 - Ingress PE Address 1038 IP address of the ingress PE of PW. 1040 - Egress PE Address 1042 IP address of the egress PE of PW. 1044 - Control word bit (C) 1046 A bit that flags the presence of a control word on this PW. If C 1047 = 1, control word is present; If C = 0, control word is not 1048 present. 1050 - PW Type 1052 A 15-bit quantity that represents the type of PW. 1054 - AGI Type, Length, Value, AGI Value 1056 Attachment Group Identifier of PW. 1058 - SAII Type, Length, Value, SAII Value 1060 Source Attachment Individual Identifier of PW. 1062 - TAII Type, Length, Value, TAII Value 1064 Target Attachment Individual Identifier of PW. 1066 6. Revertive Behavior 1068 Subsequent to local repair, there are three strategies for the 1069 network to restore traffic to a fully functional PW. 1071 o Global revertive mode 1073 If the ingress CE is multi-homed (Figure 1), it MAY switch the 1074 traffic to a backup AC which is bound to a backup PW. 1075 Alternatively, if the ingress PE hosts a backup PW (Figure 2), the 1076 ingress PE MAY switch the traffic to the backup PW. These 1077 procedures are referred to as global repair. Possible triggers of 1078 a global repair include PW status, OAM, and BFD. 1080 o Control plane revertive mode 1082 In egress PE node protection and S-PE node protection, it is 1083 possible that the failure is limited to the link between the PLR 1084 and the primary (S-)PE, whereas the primary (S-)PE is still up. 1085 In this case, the PLR or an upstream router along the transport 1086 tunnel MAY reroute the tunnel around the failed link via an 1087 alternative path. Thus, the transport tunnel can continue to be 1088 used to carry the PW traffic to the primary (S-)PE. This 1089 procedure is driven by control plane convergence, and is referred 1090 to as control plane repair. 1092 o Local revertive mode 1094 The PLR MAY move traffic back to the primary PW, after the failure 1095 is resolved. In egress AC protection, upon detecting that the 1096 primary AC is restored, the PLR MAY start forwarding traffic over 1097 the AC again. Likewise, in egress PE node protection and S-PE 1098 node protection, upon detecting that the primary PE is restored, 1099 the PLR MAY re-establish the primary transport tunnel through the 1100 primary PE, and move the traffic from the bypass tunnel back to 1101 the transport tunnel. These procedures are referred to as local 1102 reversion. 1104 The fast protection mechanism in this document SHOULD be used in 1105 tandem with the global revertive mode. Particularly in the case of 1106 egress (S-)PE failure, if the ingress PE or the protector loses 1107 communication with the (S-)PE for an extensive period of time, the 1108 LDP session between them may go down. Consequently, the ingress PE 1109 may bring down the primary PW, or the protector may remove the 1110 forwarding entry of the primary PW label. In either case, the 1111 service will be disrupted. In other words, although the fast 1112 protection can temporarily repair traffic, control plane state may 1113 eventually be timed out if the failure persists. Therefore, it is 1114 recommended that the global revertive mode SHOULD be set up in 1115 advance, so that traffic can be moved to a fully functional backup PW 1116 shortly after the local repair. 1118 The control plane revertive mode may always happen as part of the 1119 convergence of control plane protocols. However, it is only 1120 applicable to the specific scenarios described above. 1122 The local revertive mode is optional. In the circumstances where the 1123 failure is caused by resource flapping, local reversion MAY be 1124 dampened to limit potential disruptions. Local revertive mode MAY be 1125 disabled completely by configuration. 1127 7. IANA Considerations 1129 This document defines the encoding of the Capability Parameter TLV 1130 for the new "Egress Protection Capability" in Section 5. This would 1131 require IANA to assign a TLV Code Point to it. 1133 This document defines a new LDP Protection FEC Element TLV in 1134 Section 5. IANA has assigned the type value 0x83 to it. 1136 8. Security Considerations 1138 The security considerations discussed in RFC 5036, RFC 5331, RFC 1139 3209, and RFC 4090 apply to this document. 1141 9. Acknowledgements 1143 This document leverages work done by Hannes Gredler, Yakov Rekhter, 1144 Minto Jeyananth and several others on MPLS edge protection. Thanks 1145 to Nischal Sheth, Bhupesh Kothari, and Kevin Wang for their 1146 contribution. Thanks to Yakov Rekhter and John E Drake for reviewing 1147 the document. Thanks to Andrew G Malis for valuable comments. 1149 10. References 1151 10.1. Normative References 1153 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1154 Edge (PWE3) Architecture", RFC 3985, March 2005. 1156 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 1157 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 1158 October 2009. 1160 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1161 Heron, "Pseudowire Setup and Maintenance Using the Label 1162 Distribution Protocol (LDP)", RFC 4447, April 2006. 1164 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1165 Label Assignment and Context-Specific Label Space", RFC 1166 5331, August 2008. 1168 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1169 Specification", RFC 5036, October 2007. 1171 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 1172 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 1174 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1175 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1176 Functional Specification", RFC 2205, September 1997. 1178 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1179 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1180 Tunnels", RFC 3209, December 2001. 1182 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 1183 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 1184 2005. 1186 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 1187 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 1189 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 1190 5714, January 2010. 1192 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1193 (GMPLS) Signaling Functional Description", RFC 3471, 1194 January 2003. 1196 [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- 1197 Protocol Label Switching (GMPLS) Signaling Constraint- 1198 based Routed Label Distribution Protocol (CR-LDP) 1199 Extensions", RFC 3472, January 2003. 1201 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1202 Label Switching Architecture", RFC 3031, January 2001. 1204 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1206 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1207 (BFD)", RFC 5880, June 2010. 1209 [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label 1210 Assignment for LDP", RFC 6389, November 2011. 1212 [IP-LDP-FRR-MRT] 1213 Atlas, A. and R. Kebler, "An Architecture for IP/LDP Fast- 1214 Reroute Using Maximally Redundant Trees", draft-ietf- 1215 rtgwg-mrt-frr-architecture (work in progress), 2011. 1217 10.2. Informative References 1219 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 1220 Networks", RFC 5920, July 2010. 1222 Authors' Addresses 1224 Yimin Shen 1225 Juniper Networks 1226 10 Technology Park Drive 1227 Westford, MA 01886 1228 USA 1230 Phone: +1 9785890722 1231 Email: yshen@juniper.net 1233 Rahul Aggarwal 1234 Arktan, Inc 1236 Email: raggarwa_1@yahoo.com 1237 Wim Henderickx 1238 Alcatel-Lucent 1239 Copernicuslaan 50 1240 2018 Antwerp 1241 Belgium 1243 Email: wim.henderickx@alcatel-lucent.be 1245 Yuanlong Jiang 1246 Huawei Technologies 1248 Email: jiangyuanlong@huawei.com