idnits 2.17.1 draft-shen-pwe3-endpoint-fast-protection-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: At any given time, each CE sends traffic via only one AC and receives traffic via only one AC. The two ACs MAY or MAY NOT be the same. The AC used to send traffic is determined by the CE, and MAY rely on an end-to-end OAM mechanism between the CEs. The AC used for the CE to receive traffic is determined by the state of the network and the protection mechanism in use, as described later in this document. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In this model, the protector is a dedicated P router or PE router that protects all the primary PWs for one or multiple primary PEs. In egress AC protection and egress PE node protection, the protector MAY or MAY NOT be a backup PE with a direct connection to the target CE. In S-PE node protection, it MAY or MAY NOT be a backup S-PE of the backup PW. -- The document date (June 25, 2012) is 4322 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) == Missing Reference: 'ISO10589' is mentioned on line 572, but not defined == Unused Reference: 'RFC3985' is defined on line 1204, but no explicit reference was found in the text == Unused Reference: 'RFC5659' is defined on line 1207, but no explicit reference was found in the text == Unused Reference: 'RFC4447' is defined on line 1211, but no explicit reference was found in the text == Unused Reference: 'RFC5331' is defined on line 1215, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 1222, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1226, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 1230, but no explicit reference was found in the text == Unused Reference: 'RFC5286' is defined on line 1234, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 1237, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 1240, but no explicit reference was found in the text == Unused Reference: 'RFC3472' is defined on line 1244, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 1249, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 1252, but no explicit reference was found in the text == Unused Reference: 'RFC5880' is defined on line 1254, but no explicit reference was found in the text == Unused Reference: 'RFC6389' is defined on line 1257, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 1268, 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 Y. Shen, Ed. 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track R. Aggarwal 5 Expires: December 27, 2012 Arktan, Inc 6 W. Henderickx 7 Alcatel-Lucent 8 June 25, 2012 10 PW Endpoint Fast Failure Protection 11 draft-shen-pwe3-endpoint-fast-protection-02 13 Abstract 15 This document specifies a fast protection mechanism for pseudowires 16 (PWs) against egress attachment circuit failure, egress PE failure 17 (including multi-segment PW terminating PE failure), and multi- 18 segment PW switching PE failure. Designed on the basis of multi- 19 homed CE, PW redundancy, upstream label assignment and context 20 specific label switching, the mechanism enables local repair to be 21 performed by a router adjacent to a failure. In particular, the 22 router can restore PW traffic in the order of tens of milliseconds, 23 by transmitting the traffic to a protector through a pre-established 24 bypass tunnel. Therefore, the mechanism is usable to reduce the 25 packet loss that may happen before any global repair mechanism reacts 26 to the failure or routers converge on the topology changes due to the 27 failure. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 27, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 65 3. Reference Models and Failure Cases . . . . . . . . . . . . . . 4 66 3.1. Single-Segment PW . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Multi-Segment PW . . . . . . . . . . . . . . . . . . . . . 7 68 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. Local Repair and Protector . . . . . . . . . . . . . . . . 8 70 4.2. Context Identifier . . . . . . . . . . . . . . . . . . . . 11 71 4.2.1. Uses of Context Identifier . . . . . . . . . . . . . . 11 72 4.2.2. Advertisement and Path Computation . . . . . . . . . . 12 73 4.3. Protection Models . . . . . . . . . . . . . . . . . . . . 14 74 4.4. Transport Tunnel . . . . . . . . . . . . . . . . . . . . . 17 75 4.5. Bypass Tunnel . . . . . . . . . . . . . . . . . . . . . . 18 76 4.6. PW Forwarding State on Protector . . . . . . . . . . . . . 18 77 4.6.1. Co-located Protector . . . . . . . . . . . . . . . . . 19 78 4.6.2. Centralized Protector . . . . . . . . . . . . . . . . 20 79 4.7. PW Label Distribution from Primary PE to Protector . . . . 22 80 4.7.1. Protection FEC Element Encoding for PWid . . . . . . . 24 81 4.7.2. Protection FEC Element Encoding for Generalized 82 PWid . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 4.8. PW Label Distribution from Backup PE to Protector . . . . 26 84 4.9. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 27 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 30 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 93 1. Introduction 95 Per RFC 3985, RFC 4447 and RFC 5659, a pseudowire (PW) or PW segment 96 can be thought of as a connection between a pair of forwarders hosted 97 by two PEs, carrying an emulated layer-2 service over a packet 98 switched network (PSN). In the single-segment PW (SS-PW) case, a 99 forwarder binds a PW to an attachment circuit (AC). In the multi- 100 segment PW (MS-PW) case, a forwarder on a terminating PE (T-PE) binds 101 a PW segment to an AC, while a forwarder on a switching PE (S-PE) 102 binds one PW segment to another PW segment. In each direction 103 between the PEs, PW packets are transported by a PSN tunnel, which is 104 called a transport tunnel. 106 In order to protect a layer-2 service against network failures, it is 107 necessary to protect every link and node along the entire data path, 108 including ingress AC, ingress (T-)PE, intermediate routers of 109 transport tunnel, S-PEs, egress (T-)PE, and egress AC. To minimize 110 service disruption, it is also desirable that each of these 111 components is protected by a fast protection mechanism based on local 112 repair. Such a mechanism generally involves a bypass path that is 113 pre-computed and pre-installed on a router adjacent to a failure. 114 The bypass path has the property that it can guide traffic around the 115 failure, while remaining unaffected by the topology changes resulting 116 from the failure. When the failure happens, the router can invoke 117 the bypass path to redirect the traffic, achieving fast restoration 118 for the service. 120 Today, fast protection against ingress AC failure and ingress (T-)PE 121 failure is achievable by using a multi-homed CE and redundant PWs, 122 where the CE can detect the failures and move traffic onto a backup 123 ingress AC. Fast protection against failure of intermediate routers 124 is achievable through RSVP fast-reroute (RFC 4090) and IP fast- 125 reroute (RFC 5714 and RFC 5286). However, there is a lack of such 126 protection against egress AC failure, egress (T-)PE failure, and S-PE 127 failure. In these cases, service restoration has to rely on a global 128 repair or control plane repair. Global repair is normally driven by 129 ingress CE or ingress (T-)PE, and dependent on end-to-end OAM. 130 Control plane repair is dependent on protocol convergence. 131 Therefore, both mechanisms are relatively slow in reacting to 132 failures and restoring traffic. 134 This document specifies a fast protection mechanism for PWs based on 135 local repair technique. It can protect PWs against the following 136 types of failures. 138 a. Egress AC failure. 140 b. Egress PE failure: Node failure of egress PE of a SS-PW; Node 141 failure of T-PE of an MS-PW. 143 c. Switching PE failure: Node failure of S-PE of an MS-PW. 145 The mechanism is relevant to networks with redundant PWs and multi- 146 homed CEs. It is designed on the basis of MPLS upstream label 147 assignment and context specific label switching (RFC 5331). Fast 148 protection refers to the ability to restore traffic upon a failure in 149 the order of tens of milliseconds. This is achieved by establishing 150 local protection at the router adjacent to the failure. Compared 151 with the existing global repair and control plane repair mechanisms, 152 this mechanism can provide faster restoration. However, it is 153 intended to complement those mechanisms, rather than replacing them 154 in any way. 156 The mechanism is applicable to LDP signaled PWs. 158 2. Specification of Requirements 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119. 164 3. Reference Models and Failure Cases 166 This document refers to the following topologies to describe PW 167 endpoint failures and protection procedures. These topologies are 168 commonly seen in an environment with multi-homed CEs and redundant 169 PWs for global repair. In this document the fast protection 170 mechanism also use them for the local repair purposes. This SHALL 171 enable local repair and global repair to work in tandem to achieve 172 broader scope of protection with better performance. 174 3.1. Single-Segment PW 176 |<-------------- PW1 --------------->| 178 - PE1 -------------- P1 ---------------- PE2 - 179 / \ 180 / \ 181 CE1 CE2 182 \ / 183 \ / 184 - PE3 -------------- P2 ---------------- PE4 - 186 |<-------------- PW2 --------------->| 188 Figure 1 190 In Figure 1, the IP/MPLS network consists of PE-routers and 191 P-routers. It provides an emulation of a layer-2 service between CE1 192 and CE2. 194 Each CE is multi-homed to two PEs. Hence, there are two divergent 195 paths between the CEs. The first path uses PW1 established between 196 PE1 and PE2, connecting the AC CE1-PE1 and the AC CE2-PE2. The 197 second path uses PW2 established between PE3 and PE4, connecting the 198 AC CE1-PE3 and the AC CE2-PE4. The operational states of all the PWs 199 and ACs are up. The transport tunnels of the PWs are not shown in 200 this figure for clarity. 202 At any given time, each CE sends traffic via only one AC and receives 203 traffic via only one AC. The two ACs MAY or MAY NOT be the same. 204 The AC used to send traffic is determined by the CE, and MAY rely on 205 an end-to-end OAM mechanism between the CEs. The AC used for the CE 206 to receive traffic is determined by the state of the network and the 207 protection mechanism in use, as described later in this document. 209 From the perspective of traffic towards a given CE, the set of PWs, 210 PEs and ACs involved can be viewed to serve primary and backup (or 211 active and standby) roles. When the network is in a steady state, 212 the PW that is intended to carry the traffic is referred to as a 213 primary PW. The PE at the egress of the primary PW is a primary PE. 214 The AC connecting the CE and the primary PE is a primary AC. The 215 other PW that may be used to carry the traffic upon a network failure 216 are referred to as a backup PW. The PE at the egress of the backup 217 PW is a backup PE. The AC connecting the CE and the backup PE is a 218 backup AC. 220 In this document, the following primary and backup roles are assigned 221 for the traffic going from CE1 to CE2: 223 Primary PW: PW1 225 Primary PE: PE2 227 Primary AC: CE2-PE2 229 Backup PW: PW2 231 Backup PE: PE4 233 Backup AC: CE2-PE4 235 In this case, an egress AC failure refers to the failure of the 236 primary AC, i.e. the AC CE2-PE2. An egress node failure refers to 237 the failure of the primary PE, i.e. PE2. 239 The backup PE, backup PW and backup AC may be used to carry the 240 traffic when CE1 and CE2 switches traffic to PW2 during a global 241 repair, or when a local repair takes effect, as described later in 242 this document. 244 |<-------------- PW1 --------------->| 246 ------------- P1 ---------------- PE2 - 247 / \ 248 / \ 249 CE1 -- PE1 CE2 250 \ / 251 \ / 252 ------------- P2 ---------------- PE4 - 254 |<-------------- PW2 --------------->| 256 Figure 2 258 Figure 2 shows another possible scenario, where CE1 is single-homed 259 to PE1, while CE2 remains multi-homed to PE2 and PE4. From the 260 perspective of egress protection for the traffic from CE1 to CE2, 261 this topology is not much different than Figure 1. However, for the 262 traffic in the opposite direction, i.e. from CE2 to CE1, PE1 must 263 anticipate the traffic on PW1 and PW2, and sends it to CE1 over the 264 AC CE1-PE1 in both cases. 266 3.2. Multi-Segment PW 268 |<--------------- PW1 --------------->| 269 |<----- SEG1 ----->|<----- SEG2 ----->| 271 - TPE1 -------------- SPE1 --------------- TPE2 - 272 / \ 273 / \ 274 CE1 CE2 275 \ / 276 \ / 277 - TPE3 -------------- SPE2 --------------- TPE4 - 279 |<----- SEG3 ----->|<----- SEG4 ----->| 280 |<--------------- PW2 --------------->| 282 Figure 3 284 Figure 3 shows a topology that is similar to Figure 1 but in an MS-PW 285 environment. PW1 and PW2 are both MS-PWs. PW1 is established 286 between TPE1 and TPE2, and switched between segments SEG1 and SEG2 at 287 SPE1. PW2 is established between TPE3 and TPE4, and switched between 288 segments SEG3 and SEG4 at SPE2. CE1 is multi-homed to TPE1 and TPE3. 289 CE2 is multi-homed to TPE2 and TPE4. The transport tunnels of the PW 290 segments are not shown in this figure for clarity. 292 In this document, the following primary and backup roles are assigned 293 for the traffic going from CE1 to CE2: 295 Primary PW: PW1 297 Primary T-PE: TPE2 299 Primary S-PE: SPE1 301 Primary AC: CE2-TPE2 303 Backup PW: PW2 305 Backup T-PE: TPE4 307 Backup S-PE: SPE2 309 Backup AC: CE2-TPE4 311 In this case, an egress AC failure refers to the failure of the 312 primary AC, i.e. the AC CE2-TPE2. An egress node failure refers to 313 the failure of the primary T-PE, i.e. TPE2. In addition, an 314 switching node failure refers to the failure of the primary S-PE, 315 i.e. SPE1. 317 The backup T-PE, backup PW and backup AC are used for protecting the 318 primary PW against egress AC failure and egress node failure. The 319 backup S-PE and the backup PW are used for protecting the primary PW 320 against switching node failure, as described later in this document. 322 For consistency with the SS-PW scenario, primary T-PEs and a primary 323 S-PEs may simply be referred to as primary PEs in this document, 324 where specifics is not required. Similarly, backup T-PEs and backup 325 S-PEs may be referred to as backup PEs. 327 4. Theory of Operation 329 The fast protection mechanism in this document provides three types 330 of protection for PWs, corresponding to the three types of failures 331 described in Section 1. 333 a. Egress AC protection 335 b. Egress (T-)PE node protection 337 c. S-PE node protection 339 The mechanism is only relevant when the target CE is multi-homed to a 340 primary PE and a backup PE, and when there is a backup PW in the 341 network. In S-PE node protection, it is also assumed that there is a 342 backup S-PE on the backup PW. 344 4.1. Local Repair and Protector 346 The mechanism relies on local repair to be performed by routers 347 adjacent to failures. Each of these routers is referred to as a 348 "point of local repair" (PLR). A PLR MUST be able to detect a 349 failure by using a rapid mechanism, such as physical layer failure 350 detection, Bidirectional Failure Detection (BFD) (RFC 5880), etc. In 351 anticipation of the failure, the PLR MUST also pre-establish a bypass 352 PSN tunnel to a "protector", and pre-install a bypass route in the 353 FIB (forwarding information base). The bypass tunnel has the 354 property that it is not affected by the topology changes caused by 355 the failure. Upon detecting the failure, the PLR MUST invoke the 356 bypass route and forward traffic to the protector through the bypass 357 tunnel. The protector MUST in turn forward the traffic towards the 358 target CE, which may or may not be directly attached to the 359 protector. This procedure is referred to as local repair. 361 Different routers may serve as PLRs and protectors in different 362 scenarios. 364 o In egress AC protection, the PLR is the primary PE that hosts the 365 primary AC, and the protector is the backup PE (Figure 4). 367 |<-------------- PW1 --------------->| 369 - PE1 -------------- P1 ---------------- PE2 - 370 / PLR \ 371 / | \ 372 CE1 bypass| CE2 373 \ | / 374 \ | / 375 - PE3 -------------- P2 ---------------- PE4 - 376 protector 378 |<-------------- PW2 --------------->| 380 Figure 4 382 o In egress PE node protection, the PLR is the penultimate hop 383 router of transport tunnel of primary PW, and the protector is the 384 backup PE (Figure 5). 386 |<-------------- PW1 --------------->| 388 - PE1 -------------- P1 ------- P3 ----- PE2 - 389 / PLR \ \ 390 / \ \ 391 CE1 bypass\ CE2 392 \ \ / 393 \ \ / 394 - PE3 -------------- P2 ---------------- PE4 - 395 protector 397 |<-------------- PW2 --------------->| 399 Figure 5 401 o In S-PE node protection, the PLR is the penultimate hop router of 402 transport tunnel of primary PW segment, and the protector is the 403 backup S-PE (Figure 6). 405 |<--------------- PW1 --------------->| 406 |<----- SEG1 ----->|<----- SEG2 ----->| 408 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 409 / PLR \ \ 410 / \ \ 411 CE1 bypass\ CE2 412 \ \ / 413 \ \ / 414 - TPE3 --------------- SPE2 -------------- TPE4 - 415 protector 417 |<----- SEG3 ----->|<----- SEG4 ----->| 418 |<--------------- PW2 --------------->| 420 Figure 6 422 When a PLR forwards traffic through a bypass tunnel to a protector, 423 it MUST keep the original PW label intact. In particular, it SHOULD 424 NOT forward the traffic based on the PW label or modify the PW label. 425 Such forwarding state on the PLR has the advantages that it 426 represents simple forwarding operations and it is easy to set up. 427 The PLR does not need to learn PW labels or install bypass routes on 428 a per PW label basis. 430 This also means that the protector MUST forward the traffic based on 431 a PW label that is assigned by the primary PE, and ensure that the 432 traffic can eventually reach the target CE. From the protector's 433 perspective, this PW label is an upstream assigned label (RFC 5331). 434 This is accomplished by learning the PW label from the primary PE, 435 installing the proper forwarding state for the PW label in the label 436 space associated with the primary PE, and performing PW label lookup 437 in this label space. 439 A protector MAY be a backup (S-)PE as illustrated in the above 440 examples, or a dedicated router that assumes such a role. In the 441 later case, the protector is not necessarily the backup (S-)PE of a 442 given primary PW. During a local repair, the PLR still forwards 443 traffic to the protector through a bypass tunnel, and the protector 444 MUST then forward the traffic to the backup (S-)PE, which finally 445 forwards the traffic to the target CE via a backup AC or a backup PW 446 segment. More detail will be provided in Section 4.3. 448 A protector MAY protect primary PWs for one or multiple primary PEs. 449 The protector MUST maintain a separate label space for each primary 450 PE. Likewise, the primary PWs hosted by a primary PE MAY be 451 protected by multiple protectors, each for a subset of the PWs. In 452 any case, a primary PW is associated with one and only one pair of 453 {primary PE, protector}. 455 4.2. Context Identifier 457 An IPv4/v6 address is assigned to each ordered pair of {primary PE, 458 protector} to facilitate protection establishment. This address is 459 referred to as a "context identifier". It MUST be globally unique, 460 or unique within the address space of the network where the primary 461 PE and the protector reside. 463 4.2.1. Uses of Context Identifier 465 A context identifier serves two purposes. 467 o It identifies a primary PE and an associated protector. In other 468 words, it identifies a primary PE on a per protector basis. A 469 given primary PE may be protected by multiple protectors, each for 470 a subset of the primary PWs hosted by the primary PE. Therefore, 471 a distinct context identifier MUST be assigned to the primary PE 472 for each protector. 474 For a primary PW, its transport tunnel MUST be destined for the 475 context identifier of its {primary PE, protector}, rather than an 476 IP address of the primary PE. This not only enables the transport 477 tunnel to follow a path to the primary PE, but also indicates the 478 protector to the PLR(s). 480 o It indicates the primary PE's label space to a protector. The 481 protector may protect primary PWs for multiple primary PEs. It 482 MUST maintain a separate label space for each primary PE. PW 483 labels assigned by a given primary PE MUST be associated with the 484 label space indicated by the context identifier of the {primary 485 PE, protector}. The association is accomplished as below. 487 When the primary PE advertises the label of a primary PW to the 488 protector, it MUST attach the information of the context 489 identifier (Section 4.7). Upon receiving the advertisement, the 490 protector MUST install the PW label in the label space 491 corresponding to the context identifier. 493 A bypass tunnel MUST be destined for the context identifier, 494 rather than an IP address of the protector. Therefore, the bypass 495 tunnel (either MPLS tunnel label or IP tunnel destination address) 496 is equivalent to the context identifier. All packets received on 497 the bypass tunnel MUST be forwarded in the label space indicated 498 by the bypass tunnel. 500 4.2.2. Advertisement and Path Computation 502 Using a context identifier as destination for both transport and 503 bypass tunnels imposes the following requirements on path computation 504 for these tunnels. 506 o On the ingress PE, path computation for a transport tunnel MUST 507 choose the primary PE as the endpoint. 509 o On a PLR, path computation for a bypass tunnel MUST avoid the 510 primary PE and choose the protector as the endpoint. The path 511 MUST NOT traverse the primary PE. 513 In order to satisfy these requirements, a context identifier SHOULD 514 be advertised by IGP and/or IGP-TE in the routing domain and/or the 515 TE domain, depending on the tunnel technologies of the network. 517 o If RSVP-TE is used to establish both transport and bypass tunnels, 518 the context identifier MUST be advertised by IGP-TE. 520 o If IP or LDP is used to establish both transport and bypass 521 tunnels, the context identifier MUST be advertised by IGP. 523 o If IP or LDP is used for transport tunnels while RSVP-TE is used 524 for bypass tunnels, or vice versa, the context identifier MUST be 525 advertised by both IGP and IGP-TE. 527 In any case, it is recommended that the context identifier SHOULD be 528 advertised as a proxy node that is dual-attached to the primary PE 529 and the protector via unnumbered point-to-point interfaces, as shown 530 in Figure 7. This schema ensures that the CSPF (constrained shortest 531 path first), LFA (loop free alternate; RFC 5286) and MRT (maximally 532 redundant trees; [IP-LDP-FRR-MRT]) algorithms can compute the 533 expected paths for the transport tunnel and bypass tunnel, whether 534 the tunnels are MPLS tunnels or IP tunnels. 536 primary PE - 537 \ metric 1, TE metric 1, bandwidth max 538 \ 539 \ 540 \ 541 \ metric max, TE metric max, bandwidth 0 542 | 543 proxy node 544 | 545 / metric max, TE metric max, bandwidth 0 546 / 547 / 548 / 549 / metric X, TE metric Y, bandwidth max 550 protector - 552 Figure 7 554 o The primary PE advertises an unnumbered link to the proxy node, 555 with metric 1, TE metric 1, and maximum bandwidth. 557 o The protector advertises an unnumbered link to the proxy node, 558 with metric X, TE metric Y, and maximum bandwidth. X SHOULD be 559 carefully chosen so that the path from any given source node 560 (ingress PE or PLR) via the protector to the proxy node will have 561 a higher metric than the corresponding path from the source node 562 via the primary PE to the proxy node. The same requirement 563 applies to Y as well for TE paths. 565 o The primary PE advertises the proxy node with two unnumbered links 566 to the primary PE and the protector, respectively. The router ID 567 of the proxy node is the context identifier. Both unnumbered 568 links are advertised with maximum metric, maximum TE metric, and 569 zero bandwidth. This ensures that the proxy node does not serve 570 as a transit node for any paths. 572 In the case of ISIS [ISO10589], the system ID is derived from the 573 context identifier with Binary Coded Decimal (BCD) encoding. The 574 resulting system-ID MUST be unique. The LSP (Link State Packet) 575 MUST include an Area Address TLV, and MAY include a Dynamic 576 Hostname TLV. The area addresses MUST be a subset of or 577 preferably identical to those advertised by the primary PE at the 578 corresponding level. The hostname MAY be derived from the context 579 identifier and the primary PE's hostname. The Overload bit MUST 580 be set to 1. The Attached and the Partition Repair bits MUST be 581 set to 0. 583 In the case of OSPF (RFC 2328), the Advertising Router and Link 584 State ID of the router LSA (Link State Advertisement) MUST both be 585 the context identifier. All options bits in the router LSA MUST 586 be set to zero. 588 With this schema, the proxy node is reachable via both the primary PE 589 and the protector in the routing domain and the TE domain. For any 590 given ingress PE or PLR, the path via the primary PE to the proxy 591 node is considered to have a higher preference than the path via the 592 protector, due to the lower metric. Therefore, in path computation 593 for a transport tunnel, a path via the primary PE SHOULD always be 594 selected. However, in path computation for a bypass tunnel, where 595 the primary PE must be avoided, a path via the protector SHOULD be 596 selected. 598 4.3. Protection Models 600 There are two protection models based on the location and role of a 601 protector. A network MAY use either protection model, or a 602 combination of both. 604 1. Co-located protector 606 In this model, the protector is a backup PE that is directly 607 connected to the target CE via a backup AC, or it is a backup 608 S-PE on a backup PW. That is, the protector is co-located with 609 the backup (S-)PE. Examples of this model have been introduced 610 in Figure 4, Figure 5 and Figure 6 in Section 4.1. 612 In egress AC protection and egress PE node protection, when a 613 protector receives traffic from the PLR, it forwards the traffic 614 to the CE via the backup AC. This is shown in Figure 8, where 615 PE2 is the PLR for egress AC failure, P3 is the PLR for PE2 616 failure, and PE4 (the backup PE) is the protector. 618 |<-------------- PW1 --------------->| 620 - PE1 -------------- P1 ------- P3 ----- PE2 ---- 621 / PLR \ PLR \ 622 / \ | \ 623 CE1 bypass\ |bypass CE2 624 \ \ | / 625 \ \ | / 626 - PE3 -------------- P2 ---------------- PE4 ---- 627 protector 629 |<-------------- PW2 --------------->| 631 Figure 8 633 In S-PE node protection, when a protector receives traffic from 634 the PLR, it MUST forward the traffic via the next segment of the 635 backup PW. The T-PE of the backup PW MUST forward the traffic to 636 the CE via a backup AC. This is shown in Figure 9, where P4 is 637 the PLR for SPE1 failure, and SPE2 (the backup S-PE) is the 638 protector for SPE1 (the primary S-PE). 640 |<--------------- PW1 --------------->| 641 |<----- SEG1 ----->|<----- SEG2 ----->| 643 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 644 / PLR \ \ 645 / \ \ 646 CE1 bypass\ CE2 647 \ \ / 648 \ \ / 649 - TPE3 --------------- SPE2 -------------- TPE4 - 650 protector 652 |<----- SEG3 ----->|<----- SEG4 ----->| 653 |<--------------- PW2 --------------->| 655 Figure 9 657 In the co-located protector model, the number of context 658 identifiers required by a network is the number of distinct 659 {primary PE, backup PE} pairs. Therefore, the model is suitable 660 for scenarios where the number backup PEs for any given primary 661 PE is relatively small. 663 2. Centralized protector 665 In this model, the protector is a dedicated P router or PE router 666 that protects all the primary PWs for one or multiple primary 667 PEs. In egress AC protection and egress PE node protection, the 668 protector MAY or MAY NOT be a backup PE with a direct connection 669 to the target CE. In S-PE node protection, it MAY or MAY NOT be 670 a backup S-PE of the backup PW. 672 In egress AC protection and egress PE node protection, when the 673 protector receives traffic from the PLR, if the protector has a 674 direct connection (i.e. backup AC) to the CE, it MUST forward the 675 traffic to the CE via the backup AC, which is similar to 676 Figure 8. Otherwise, it MUST forward the traffic to a backup PE, 677 which MUST then forward the traffic to the CE via a backup AC. 678 This is shown in Figure 10, where the protector receives traffic 679 from P3 or PE2 (the PLRs) and forwards the traffic to PE4 (the 680 backup PE). The protector may be protecting other PWs as well, 681 which are not shown in this figure. 683 |<------------- PW1 --------------->| 685 - PE1 ------------- P1 ------- P3 ----- PE2 -- 686 / PLR \ PLR \ 687 / \ / \ 688 / bypass\ /bypass \ 689 / \ / \ 690 CE1 protector CE2 691 \ \ / 692 \ \ / 693 \ \ / 694 \ \ / 695 - PE3 ------------- P2 -----------------PE4 -- 697 |<------------- PW2 --------------->| 699 Figure 10 701 In S-PE node protection, when the protector receives traffic from 702 the PLR, if the protector is a backup S-PE of the backup PW, it 703 MUST forward the traffic via the next segment of the backup PW, 704 and the T-PE of the backup PW MUST forward the traffic to the CE 705 via a backup AC, which is similar to Figure 9. Otherwise, the 706 protector MUST first forward the traffic to the backup S-PE, 707 which MUST then forward the traffic via the next segment of the 708 backup PW. Finally, the T-PE of the backup PW MUST forward the 709 traffic to the CE via a backup AC. This is shown in Figure 11, 710 where the protector forwards traffic to SPE2 (the backup S-PE). 711 The protector may be protecting other PW segments as well, which 712 are not shown in this figure. 714 |<--------------- PW1 --------------->| 715 |<----- SEG1 ----->|<----- SEG2 ----->| 717 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 718 / PLR \ \ 719 / \ \ 720 / bypass\ \ 721 / \ \ 722 CE1 protector CE2 723 \ \ / 724 \ \ / 725 \ \ / 726 \ \ / 727 - TPE3 --------------- SPE2 -------------- TPE4 - 729 |<----- SEG3 ----->|<----- SEG4 ----->| 730 |<--------------- PW2 --------------->| 732 Figure 11 734 In the centralized protector model, each primary PE MAY only need 735 one protector to protect all of its PWs. Therefore, the number 736 of context identifiers required by a network can be as low as the 737 number of primary PEs. 739 4.4. Transport Tunnel 741 The ingress PE of a primary PW (or PW segment) associates the PW with 742 the primary egress PE through LDP signaling. The ingress PE MUST 743 also associate the transport tunnel of the PW with the context 744 identifier of the {primary PE, protector} of the PW. In particular, 745 the destination of the transport tunnel MUST be the context 746 identifier (Section 4.2.1). This not only ensures PW traffic to be 747 transported to the primary PE, but also facilitates bypass tunnel 748 establishment for PLR(s), as the context identifier implies both the 749 primary PE and the protector. 751 The association between the transport tunnel and the context 752 identifier MAY be achieved by configuration or an auto-discovery 753 mechanism. In the later case, the ingress PE MAY learn the context 754 identifier from the primary PE, if the primary PE advertises the 755 context identifier as "third party next hop" in an IPv4/v6 756 Interface_ID TLV (RFC 3471, RFC 3472) in LDP Label Mapping message. 758 4.5. Bypass Tunnel 760 A PLR may provide protection for multiple primary PWs associated with 761 one or multiple pairs of {primary PE, protector}. The PLR MUST 762 establish a bypass tunnel to each protector for each distinct context 763 identifier associated with the protector. The destination of the 764 bypass tunnel MUST be the context identifier, as described in 765 Section 4.2.1. The association between the destination and the 766 context identifier can be achieved by PLR learning or inheriting 767 destination address from the transport tunnel. 769 For examples, in Figure 8 and Figure 10, a bypass tunnel is 770 established from PE2 (PLR for egress AC failure) to the protector, 771 and another bypass tunnel is established from P3 (PLR for egress node 772 failure) to the protector. In Figure 9 and Figure 11, a bypass 773 tunnel is established from P4 (PLR for switching node failure) to the 774 protector. 776 During a local repair, the PLR forwards traffic to the protector 777 through the bypass tunnel with PW label intact. This normally 778 involves pushing an MPLS label to the label stack, if the bypass 779 tunnel is an MPLS tunnel, or pushing an IP header to the packet, if 780 the bypass tunnel is an IP tunnel. The protector MUST then forward 781 the traffic based on this PW label, i.e. an upstream assigned label. 782 In order to perform such forwarding, the protector MUST treat the 783 bypass tunnel as a context to determine the primary PE's label space. 784 Specifically, if the bypass tunnel is an MPLS tunnel, the protector 785 MUST assign a non-reserved label for the bypass tunnel, and use this 786 label as the context. If the bypass tunnel is an IP tunnel, the 787 destination address in its IP header should be the context 788 identifier. 790 A bypass tunnel MUST have the property that it is not affected by the 791 topology changes caused by the failure that the bypass tunnel 792 protects against. Therefore, it can be used to transmit traffic 793 during the convergence period of routing protocols and the delay of 794 global repair. It will remain effective, until the current transport 795 tunnel is rerouted around the failure, or the traffic is moved to 796 another PW or transport tunnel. 798 4.6. PW Forwarding State on Protector 800 A protector MUST be able to forward traffic based on the PW label 801 assigned by a primary PE. Therefore, it MUST learn the PW labels 802 from all the primary PEs that it protects (Section 4.7), and maintain 803 the PW labels in separate label spaces for the primary PEs. 805 In the control plane, a primary PE's label space is identified by the 806 context identifier of the {primary PE, protector}. When the 807 protector learns a PW label from the primary PE, it MUST associate 808 the PW label with the label space via this context identifier. In 809 the forwarding plane, the label space is indicated by bypass tunnels 810 that are destined for the context identifier. 812 4.6.1. Co-located Protector 814 In Figure 12, PE4 is a co-located protector that protects PW1 against 815 egress AC failure and egress node failure. It maintains a label 816 space for PE2, which is identified by the context identifier of {PE2, 817 PE4}. It learns from PE2 the label that PE2 has assigned to PW1, and 818 installs an forwarding entry for the label in the label space. The 819 nexthop of the forwarding entry indicates a label pop with outgoing 820 interface pointing to the backup AC CE2-PE4. 822 |<-------------- PW1 --------------->| 824 - PE1 -------------- P1 ------- P3 ----- PE2 ---- 825 / PLR \ PLR \ 826 / \ | \ 827 CE1 bypass\ |bypass CE2 828 \ \ | / 829 \ \ | / 830 - PE3 -------------- P2 ---------------- PE4 ---- 831 protector 833 |<-------------- PW2 --------------->| 835 Figure 12 837 In Figure 13, SPE2 is a co-located protector that protects PW1 838 against switching node failure. It maintains a label space for SPE1, 839 which is identified by the context identifier of {SPE1, SPE2}. It 840 learns the label that SPE1 has assigned to the PW segment SEG1, and 841 installs a forwarding entry in the label space. The nexthop of the 842 forwarding entry indicates a label swap to the label of the PW 843 segment SEG4. 845 |<--------------- PW1 --------------->| 846 |<----- SEG1 ----->|<----- SEG2 ----->| 848 - TPE1 ----- P4 ----- SPE1 --------------- TPE2 - 849 / PLR \ \ 850 / \ \ 851 CE1 bypass\ CE2 852 \ \ / 853 \ \ / 854 - TPE3 --------------- SPE2 --------------- TPE4 - 855 protector 857 |<----- SEG3 ----->|<----- SEG4 ----->| 858 |<--------------- PW2 --------------->| 860 Figure 13 862 4.6.2. Centralized Protector 864 In the centralized protector model, for each primary PW of which the 865 protector is not a backup (S-)PE, the protector MUST also learn the 866 label of the backup PW from the backup (S-)PE (Section 4.8). This is 867 the backup (S-)PE that the protector will forward traffic to. The 868 protector MUST use the label as the outgoing label for the forwarding 869 entry of the primary PW label. 871 In Figure 14, the protector is a centralized protector that protects 872 PW1 against egress AC failure and egress node failure. It maintains 873 a label space for PE2, which is identified by the context identifier 874 of {PE2, protector}. It learns from PE2 the label that PE2 has 875 assigned to PW1, and learns from PE4 the label that PE4 has assigned 876 to PW2. It installs a forwarding entry for PW1's label in the label 877 space. The nexthop of the forwarding entry indicates a label swap to 878 PW2's label. 880 |<------------- PW1 --------------->| 882 - PE1 ------------- P1 ------- P3 ----- PE2 -- 883 / PLR \ PLR \ 884 / \ / \ 885 / bypass\ /bypass \ 886 / \ / \ 887 CE1 protector CE2 888 \ \ / 889 \ \ / 890 \ \ / 891 \ \ / 892 - PE3 ------------- P2 -----------------PE4 -- 894 |<------------- PW2 --------------->| 896 Figure 14 898 In Figure 15, the protector is a centralized protector that protects 899 the PW segment SEG1 of PW1 against switching node failure of SPE1. 900 It maintains a label space for SPE1, which is identified by the 901 context identifier of {SPE1, protector}. It learns from SPE1 the 902 label that SPE1 has assigned to SEG1, and learns from SPE2 the label 903 that SPE2 has assigned to SEG3. It installs a forwarding entry for 904 SEG1's label in the label space. The nexthop of the forwarding entry 905 indicates a label swap to SEG3's label. 907 |<--------------- PW1 --------------->| 908 |<----- SEG1 ----->|<----- SEG2 ----->| 910 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 911 / PLR \ \ 912 / \ \ 913 / bypass\ \ 914 / \ \ 915 CE1 protector CE2 916 \ \ / 917 \ \ / 918 \ \ / 919 \ \ / 920 - TPE3 --------------- SPE2 -------------- TPE4 - 922 |<----- SEG3 ----->|<----- SEG4 ----->| 923 |<--------------- PW2 --------------->| 925 Figure 15 927 4.7. PW Label Distribution from Primary PE to Protector 929 A primary PE MUST distribute the label of each primary PW to the 930 protector that protects the PW. To achieve this, the primary PE MUST 931 establish a targeted LDP session with the protector. For each 932 primary PW, the primary PE SHOULD advertise over that session a 933 Protection FEC Element via Label Mapping message. The Protection FEC 934 Element is a new LDP FEC, and its encoding is described below. The 935 PW's label is encoded in the message using the Upstream-Assigned 936 Label TLV defined in (RFC 6389). The Protection FEC Element and the 937 PW label combined represent the primary PE's forwarding state for the 938 PW. The Label Mapping message SHOULD also carry an IPv4/v6 939 Interface_ID TLV (RFC 6389, RFC 3471) encoded with the context 940 identifier of the {primary PE, protector}. 942 The protector that receives this Label Mapping message SHOULD install 943 a forwarding entry for the PW label in the label space identified by 944 the context identifier. The nexthop of the forwarding entry SHOULD 945 allow packets to be sent towards the target CE via a backup AC or a 946 backup (S-)PE, depending on the protection model and SS-PW or MS-PW 947 scenario involved. 949 The Protection FEC Element has type 0x83. It is defined as below: 951 0 1 2 3 952 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 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Type(0x83) | Reserved | Encoding Type | Length | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | | 957 | | 958 ~ PW Information ~ 959 | | 960 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 Figure 16 966 - Encoding Type 968 Type of format that PW Information field is encoded. 970 - Length 972 Length of PW Information field in octets. 974 - PW Information 976 Field of variable length that specifies a PW 978 For Encoding Type, 1 is defined for the PWid FEC Element format, and 979 2 is defined for the Generalized PWid FEC Element format (RFC 4447). 981 4.7.1. Protection FEC Element Encoding for PWid 983 0 1 2 3 984 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 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Type(0x83) | Reserved | Enc Type(1) | Length(16) | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Ingress PE Address | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Egress PE Address | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Group ID | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | PW ID | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 |C| PW Type | Reserved | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 Figure 17 1001 - Ingress PE Address 1003 IP address of the ingress PE of PW. 1005 - Egress PE Address 1007 IP address of the egress PE of PW. 1009 - Group ID 1011 An arbitrary 32-bit value that represents a group of PWs and that 1012 is used to create groups in the PW space. 1014 - PW ID 1016 A non-zero 32-bit connection ID that, together with the PW Type 1017 field, identifies a particular PW. 1019 - Control word bit (C) 1021 A bit that flags the presence of a control word on this PW. If C 1022 = 1, control word is present; If C = 0, control word is not 1023 present. 1025 - PW Type 1026 A 15-bit quantity that represents the type of PW. 1028 4.7.2. Protection FEC Element Encoding for Generalized PWid 1030 0 1 2 3 1031 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 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | Type(0x83) | Reserved | Enc Type(2) | Length | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Ingress PE Address | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Egress PE Address | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 |C| PW Type | Reserved | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | AGI Type | Length | Value | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 ~ AGI Value (contd.) ~ 1044 | | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | AII Type | Length | Value | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 ~ SAII Value (contd.) ~ 1049 | | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | AII Type | Length | Value | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 ~ TAII Value (contd.) ~ 1054 | | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 Figure 18 1059 - Ingress PE Address 1061 IP address of the ingress PE of PW. 1063 - Egress PE Address 1065 IP address of the egress PE of PW. 1067 - Control word bit (C) 1069 A bit that flags the presence of a control word on this PW. If C 1070 = 1, control word is present; If C = 0, control word is not 1071 present. 1073 - PW Type 1075 A 15-bit quantity that represents the type of PW. 1077 - AGI Type, Length, Value, AGI Value 1079 Attachment Group Identifier of PW. 1081 - SAII Type, Length, Value, SAII Value 1083 Source Attachment Individual Identifier of PW. 1085 - TAII Type, Length, Value, TAII Value 1087 Target Attachment Individual Identifier of PW. 1089 4.8. PW Label Distribution from Backup PE to Protector 1091 In the centralized protector model, a protector may not be a backup 1092 (S-)PE for some primary PWs. For these PWs, in addition to learning 1093 PW labels from the primary PEs, the protector MUST also learn the 1094 labels of backup PWs and backup PW segments from backup (S-)PEs. 1096 To achieve this, each backup (S-)PE MUST establish a targeted LDP 1097 session with the protector. The backup PE SHOULD advertise over that 1098 session a Protection FEC Element for the backup PW via Label Mapping 1099 message. The content of this Protection FEC Element MUST match the 1100 Protection FEC Element that the primary PE advertises to the 1101 protector (section 4.8). The Label Mapping message SHOULD also 1102 include a Generic Label TLV encoded with the backup PW's label. The 1103 context identifier SHOULD NOT be encoded in Interface_ID TLV in this 1104 message. The Protection FEC Element and the backup PW's label 1105 combined represent the backup PE's forwarding state for the backup 1106 PW. 1108 The protector that receives this Label Mapping message SHOULD 1109 associate the backup PW with the primary PW, based on the common 1110 Protection FEC Element. It SHOULD distinguish between the message 1111 from the primary PE and the message from the backup PE based on the 1112 presence and absence of context identifier in Interface_ID TLV. It 1113 SHOULD install a forwarding entry for the primary PW's label in the 1114 label space identified by the context identifier. The nexthop of the 1115 forwarding entry SHOULD indicate a label swap to the backup PW's 1116 label. 1118 4.9. Revertive Behavior 1120 After a local repair takes effect, PW traffic is redirected from a 1121 PLR to a protector and then to target CE. There are three strategies 1122 for restoring the traffic to a fully working PW. 1124 o Global revertive mode 1126 If the ingress CE is multi-homed (Figure 1), it MAY switch the 1127 traffic to a backup AC which is bound to a backup PW. Or, if the 1128 ingress PE hosts a backup PW (Figure 2), it MAY switch the traffic 1129 to the backup PW. These procedures are referred to as global 1130 repairs, and are driven by ingress CE or ingress PE. Possible 1131 triggers of a global repair include PW status, OAM, and BFD. 1133 o Control plane revertive mode 1135 In egress PE node protection and S-PE node protection, it is 1136 possible that the failure is limited to the link between the PLR 1137 and the primary (S-)PE, while the primary (S-)PE is still up. In 1138 this case, if the PLR or an upstream router along the transport 1139 tunnel can reach the primary (S-)PE via an alternative route, it 1140 MAY reroute the transport tunnel around the failed link, so that 1141 the transport tunnel can continue to carry the PW traffic to the 1142 primary (S-)PE. This procedure is driven by control plane 1143 convergence, and is referred to as control plane repair. 1145 o Local revertive mode 1147 The PLR MAY move traffic back to the primary PW, after the failure 1148 is resolved. In egress AC protection, upon detecting that the 1149 primary AC is restored, the PLR MAY start forwarding traffic via 1150 the AC again. Likewise, in egress PE node protection and 1151 switching node protection, upon detecting that the primary PE is 1152 restored, the PLR MAY re-establish the primary transport tunnel, 1153 move the traffic back to the tunnel. These procedures are 1154 referred to as local reversion. 1156 The fast protection mechanism in this document SHOULD always be used 1157 in tandem with the globally revertive mode. Particularly in the case 1158 of egress (S-)PE failure, if the ingress PE or the protector loses 1159 communication with the (S-)PE for an extensive period of time, the 1160 LDP session between them may go down. Consequently, the ingress PE 1161 may bring down the primary PW, or the protector may delete the 1162 forwarding entry of the primary PW label from the label space. In 1163 either case, the service will be disrupted. In other words, although 1164 the fast protection can temporarily repair traffic, control plane 1165 states may eventually time out if the failure persists. Therefore, 1166 it is recommended that the global revertive mode SHOULD always be 1167 established in advance, so that it can move traffic to a fully 1168 working backup PW shortly after the local repair. 1170 The control plane revertive mode is optional, because it only applies 1171 to the specific scenarios of egress PE failure and S-PE failure. 1173 The local revertive mode is optional. In the circumstances where the 1174 failure is caused by resource flapping, local reversion MAY be 1175 dampened to limit potential disruptions. Local revertive mode MAY be 1176 disabled completely by configuration. 1178 5. IANA Considerations 1180 IANA maintains a registry of LDP FECs at the registry "Label 1181 Distribution Protocol" in the sub-registry called "Forwarding 1182 Equivalence Class (FEC) Type Name Space". 1184 This document defines a new LDP Protection FEC Element in 1185 Section 4.7. IANA has assigned the type value 0x83 to it. 1187 6. Security Considerations 1189 The security considerations discussed in RFC 5036, RFC 5331, RFC 1190 3209, and RFC 4090 apply to this document. 1192 7. Acknowledgements 1194 This document leverages work done by Hannes Gredler, Yakov Rekhter, 1195 Minto Jeyananth and several others on MPLS edge protection. Thanks 1196 to Nischal Sheth, Bhupesh Kothari, and Kevin Wang for their 1197 contribution. Thanks to Yakov Rekhter and John E Drake for reviewing 1198 the document. 1200 8. References 1202 8.1. Normative References 1204 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1205 Edge (PWE3) Architecture", RFC 3985, March 2005. 1207 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 1208 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 1209 October 2009. 1211 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1212 Heron, "Pseudowire Setup and Maintenance Using the Label 1213 Distribution Protocol (LDP)", RFC 4447, April 2006. 1215 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1216 Label Assignment and Context-Specific Label Space", 1217 RFC 5331, August 2008. 1219 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1220 Specification", RFC 5036, October 2007. 1222 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1223 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1224 Functional Specification", RFC 2205, September 1997. 1226 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1227 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1228 Tunnels", RFC 3209, December 2001. 1230 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 1231 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1232 May 2005. 1234 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 1235 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 1237 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1238 RFC 5714, January 2010. 1240 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1241 (GMPLS) Signaling Functional Description", RFC 3471, 1242 January 2003. 1244 [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- 1245 Protocol Label Switching (GMPLS) Signaling Constraint- 1246 based Routed Label Distribution Protocol (CR-LDP) 1247 Extensions", RFC 3472, January 2003. 1249 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1250 Label Switching Architecture", RFC 3031, January 2001. 1252 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1254 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1255 (BFD)", RFC 5880, June 2010. 1257 [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label 1258 Assignment for LDP", RFC 6389, November 2011. 1260 [IP-LDP-FRR-MRT] 1261 Atlas, A. and R. Kebler, "An Architecture for IP/LDP Fast- 1262 Reroute Using Maximally Redundant Trees", 1263 draft-ietf-rtgwg-mrt-frr-architecture (work in progress), 1264 2011. 1266 8.2. Informative References 1268 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 1269 Networks", RFC 5920, July 2010. 1271 Authors' Addresses 1273 Yimin Shen (editor) 1274 Juniper Networks 1275 10 Technology Park Drive 1276 Westford, MA 01886 1277 USA 1279 Phone: +1 9785890722 1280 Email: yshen@juniper.net 1282 Rahul Aggarwal 1283 Arktan, Inc 1285 Email: raggarwa_1@yahoo.com 1287 Wim Henderickx 1288 Alcatel-Lucent 1289 Copernicuslaan 50 1290 2018 Antwerp 1291 Belgium 1293 Email: wim.henderickx@alcatel-lucent.be