idnits 2.17.1 draft-shen-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 MPLS 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 of one or multiple primary PEs. In egress AC protection and egress node protection, the protector MAY or MAY NOT be a backup PE with a direct connection to the target CE. In switching node protection, it MAY or MAY NOT be a backup S-PE on a backup PW. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: To achieve this, each backup (S-)PE MUST establish a targeted LDP session with the protector. The backup PE MUST advertise over that session a Protection FEC Element for the backup PW via Label Mapping message. The content of this Protection FEC Element MUST match the Protection FEC Element that the primary PE advertises to the protector (section 4.8). The Label Mapping message MUST also include a Generic Label TLV encoded with the backup PW's label. The context identifier SHOULD not be encoded in Interface_ID TLV in this message. The Protection FEC Element and the backup PW's label together represent the backup PE's forwarding state for the backup PW. -- The document date (February 27, 2012) is 4442 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: 'RFC 3985' is mentioned on line 89, but not defined == Missing Reference: 'RFC 4447' is mentioned on line 906, but not defined ** Obsolete undefined reference: RFC 4447 (Obsoleted by RFC 8077) == Missing Reference: 'RFC 5659' is mentioned on line 89, but not defined == Missing Reference: 'RFC 4090' is mentioned on line 713, but not defined == Missing Reference: 'RFC 5331' is mentioned on line 736, but not defined == Missing Reference: 'RFC 5880' is mentioned on line 327, but not defined == Missing Reference: 'RFC 2328' is mentioned on line 576, but not defined == Missing Reference: 'RFC 3471' is mentioned on line 636, but not defined == Missing Reference: 'RFC 3472' is mentioned on line 636, but not defined == Missing Reference: 'RFC 3031' is mentioned on line 664, but not defined == Missing Reference: 'RFC 2205' is mentioned on line 706, but not defined == Missing Reference: 'RFC 3209' is mentioned on line 706, but not defined == Unused Reference: 'RFC3985' is defined on line 1116, but no explicit reference was found in the text == Unused Reference: 'RFC5659' is defined on line 1119, but no explicit reference was found in the text == Unused Reference: 'RFC4447' is defined on line 1123, but no explicit reference was found in the text == Unused Reference: 'RFC5331' is defined on line 1127, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 1134, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1138, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 1142, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 1146, but no explicit reference was found in the text == Unused Reference: 'RFC3472' is defined on line 1150, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 1155, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 1158, but no explicit reference was found in the text == Unused Reference: 'RFC5880' is defined on line 1160, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 1176, 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' Summary: 4 errors (**), 0 flaws (~~), 30 warnings (==), 3 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 R. Aggarwal 4 Intended status: Standards Track Juniper Networks 5 Expires: August 30, 2012 W. Henderickx 6 Alcatel-Lucent 7 February 27, 2012 9 PW Endpoint Fast Failure Protection 10 draft-shen-pwe3-endpoint-fast-protection-01 12 Abstract 14 This document specifies a fast protection mechanism for pseudowires 15 (PWs) against egress attachment circuit (AC) failure, egress PE 16 failure, and switching PE failure. Designed on the basis of multi- 17 homed CE, PW redundancy, upstream label assignment and context 18 specific label switching, the mechanism enables local repair to be 19 performed immediately upon a failure. In particular, the router at 20 point of local repair (PLR) can redirect PW traffic to a protector 21 via a bypass LSP in the order of tens of milliseconds, achieving fast 22 protection that is comparable to RSVP fast-reroute. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 30, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 60 3. Reference Models and Failure Cases . . . . . . . . . . . . . . 4 61 3.1. Single-Segment PW . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Multi-Segment PW . . . . . . . . . . . . . . . . . . . . . 6 63 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7 64 4.1. Protector and Context Identifier . . . . . . . . . . . . . 9 65 4.2. Protection Models . . . . . . . . . . . . . . . . . . . . 9 66 4.3. Context Identifier Advertisement by IGP . . . . . . . . . 12 67 4.4. LSP and Context Identifier Association . . . . . . . . . . 14 68 4.5. PW and Context Identifier Association . . . . . . . . . . 14 69 4.6. Bypass LSP . . . . . . . . . . . . . . . . . . . . . . . . 15 70 4.6.1. RSVP Signaled Bypass LSP and Backup LSP . . . . . . . 15 71 4.6.2. LDP Signaled Bypass LSP . . . . . . . . . . . . . . . 16 72 4.7. Forwarding State on Protector . . . . . . . . . . . . . . 17 73 4.8. PW Label Distribution from Primary PE to Protector . . . . 19 74 4.8.1. Protection FEC Element Encoding for PWid . . . . . . . 21 75 4.8.2. Protection FEC Element Encoding for Generalized 76 PWid . . . . . . . . . . . . . . . . . . . . . . . . . 22 77 4.9. PW Label Distribution from Backup PE to Protector . . . . 23 78 4.10. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 24 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 26 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 87 1. Introduction 89 Per [RFC 3985], [RFC 4447] and [RFC 5659], a pseudowire (PW) or PW 90 segment can be thought of as a connection between a pair of 91 forwarders hosted by two PEs, carrying an emulated layer-2 service. 92 In the single-segment PW (SS-PW) case, a forwarder binds a PW to an 93 attachment circuit (AC). In the multi-segment PW (MS-PW) case, a 94 forwarder on terminating PE (T-PE) binds a PW segment to an AC, while 95 a forwarder on switching PE (S-PE) binds one PW segment to another PW 96 segment. PW packets are transported between PEs through an MPLS 97 tunnel in each direction, which is called a transport LSP. 99 In order to protect a layer-2 service against network failures, it is 100 necessary to protect every link and node along the entire data path, 101 including ingress AC, ingress (T-)PE, intermediate LSRs of transport 102 LSP, S-PEs, egress (T-)PE, and egress AC. To minimize traffic 103 disruption upon a failure, it is also desirable that each of these 104 components is protected by a fast protection mechanism based on local 105 repair. 107 Today, fast protection against ingress AC failure and ingress (T-)PE 108 failure is achievable by using multi-homed CE and redundant PWs. fast 109 protection against failure of LSR is achievable through RSVP fast- 110 reroute [RFC 4090]. However, there is a lack of similar protection 111 against egress AC failure, egress (T-)PE failure, and S-PE failure. 112 In these cases, a global repair mechanism has to be relied on. 113 Global repair mechanisms are normally driven by ingress CE or ingress 114 (T-)PE, and dependent on control plane convergence. Therefore, they 115 are relatively slow in reacting to failures and restoring traffic. 117 This document specifies a fast protection mechanism for PWs based on 118 the technique of local repair. The mechanism can protect PWs against 119 the following types of failures. 121 a. Egress AC failure. 123 b. Egress node failure: Failure of egress PE of a SS-PW; Failure of 124 T-PE of an MS-PW. 126 c. Switching node failure: Failure of S-PE of an MS-PW. 128 The mechanism is relevant to networks with redundant PWs and multi- 129 homed CEs. It is designed on the basis of MPLS upstream label 130 assignment and context specific label switching [RFC 5331]. fast 131 protection refers to the ability to perform local repair upon a 132 failure in the order of tens of milliseconds, which is comparable to 133 RSVP fast-reroute [RFC 4090]. This is achieved by establishing local 134 protection at the router adjacent to the failure. Compared with the 135 existing global repair mechanisms, this mechanism can provide faster 136 failure detection and traffic restoration. However, this mechanism 137 is intended to complement the global repair mechanisms, rather than 138 replacing them in any way. 140 The mechanism is applicable to LDP signaled PWs. 142 2. Specification of Requirements 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119. 148 3. Reference Models and Failure Cases 150 This document refers to the following topologies to describe PW 151 endpoint failures and protection procedures. These topologies are 152 commonly seen in PW redundancy for end-to-end global protection. In 153 this document, the fast protection mechanism also use them for the 154 local repair purposes. This SHALL allow local repair and global 155 repair to work in tandem to achieve broader scope of protection for 156 services. 158 3.1. Single-Segment PW 160 |<-------------- PW1 --------------->| 162 - PE1 -------------- P1 ---------------- PE2 - 163 / \ 164 / \ 165 CE1 CE2 166 \ / 167 \ / 168 - PE3 -------------- P2 ---------------- PE4 - 170 |<-------------- PW2 --------------->| 172 Figure 1 174 In Figure 1, the MPLS network consists of PE-routers and P-routers. 175 It provides an emulation of a layer-2 service between CE1 and CE2. 177 Each CE is multi-homed to two PEs. Hence, there are two divergent 178 paths between the CEs. The first path uses PW1 established between 179 PE1 and PE2, connecting the AC CE1-PE1 and the AC CE2-PE2. The 180 second path uses PW2 established between PE3 and PE4, connecting the 181 AC CE1-PE3 and the AC CE2-PE4. The operational states of all the PWs 182 and ACs are up. 184 At any given time, each CE sends traffic via only one AC and receives 185 traffic via only one AC. The two ACs MAY or MAY NOT be the same. 186 The AC used to send traffic is determined by the CE, and MAY rely on 187 an end-to-end OAM mechanism between the CEs. The AC used for the CE 188 to receive traffic is determined by the state of the MPLS network and 189 the protection mechanism in use, as described later in this document. 191 From the perspective of traffic towards a given CE, the set of PWs, 192 PEs and ACs involved can be viewed to serve primary and backup (or 193 active and standby) roles. When the MPLS network is in a steady 194 state, the PW that is intended to carry the traffic is referred to as 195 a primary PW. The PE at the egress of the primary PW is a primary 196 PE. The AC connecting the CE and the primary PE is a primary AC. 197 The other PWs that may be used to carry the traffic upon a network 198 failure are referred to as backup PWs. The PE at the egress of a 199 backup PW is a backup PE. The AC connecting the CE and a backup PE 200 is a backup AC. 202 In this document, the following primary and backup roles are assigned 203 for the traffic going from CE1 to CE2: 205 Primary PW: PW1 207 Primary PE: PE2 209 Primary AC: CE2-PE2 211 Backup PW: PW2 213 Backup PE: PE4 215 Backup AC: CE2-PE4 217 In this case, an egress AC failure refers to the failure of the 218 primary AC, i.e. the AC CE2-PE2. An egress node failure refers to 219 the failure of the primary PE, i.e. PE2. 221 The backup PE, backup PW and backup AC may be used to carry the 222 traffic when CE1 and CE2 switches traffic to PW2 during a global 223 repair, or when a local repair takes effect, as described later in 224 this document. 226 |<-------------- PW1 --------------->| 228 ------------- P1 ---------------- PE2 - 229 / \ 230 / \ 231 CE1 -- PE1 CE2 232 \ / 233 \ / 234 ------------- P2 ---------------- PE4 - 236 |<-------------- PW2 --------------->| 238 Figure 2 240 Figure 2 shows another possible scenario, where CE2 remains multi- 241 homed to PE2 and PE4, while CE1 is single-homed to PE1. From the 242 perspective of egress protection for the traffic from CE1 to CE2, 243 this topology is not much different than Figure 1. However, for the 244 traffic in the opposite direction, i.e. from CE2 to CE1, PE1 must 245 anticipate the traffic on PW1 and PW2, and sends it to CE1 over the 246 AC CE1-PE1 in both cases. 248 3.2. Multi-Segment PW 250 |<--------------- PW1 --------------->| 251 |<----- SEG1 ----->|<----- SEG2 ----->| 253 - TPE1 -------------- SPE1 --------------- TPE2 - 254 / \ 255 / \ 256 CE1 CE2 257 \ / 258 \ / 259 - TPE3 -------------- SPE2 --------------- TPE4 - 261 |<----- SEG3 ----->|<----- SEG4 ----->| 262 |<--------------- PW2 --------------->| 264 Figure 3 266 Figure 3 shows a topology that is similar to Figure 1 but in an MS-PW 267 environment. PW1 and PW2 are both MS-PWs. PW1 is established 268 between TPE1 and TPE2, and switched at SPE1. PW2 is established 269 between TPE3 and TPE4, and switched at SPE2. CE1 is multi-homed to 270 TPE1 and TPE3. CE2 is multi-homed to TPE2 and TPE4. 272 In this document, the following primary and backup roles are assigned 273 for the traffic going from CE1 to CE2: 275 Primary PW: PW1 277 Primary T-PE: TPE2 279 Primary S-PE: SPE1 281 Primary AC: CE2-TPE2 283 Backup PW: PW2 285 Backup T-PE: TPE4 287 Backup S-PE: SPE2 289 Backup AC: CE2-TPE4 291 In this case, an egress AC failure refers to the failure of the 292 primary AC, i.e. the AC CE2-TPE2. An egress node failure refers to 293 the failure of the primary T-PE, i.e. TPE2. In addition, an 294 switching node failure refers to the failure of the primary S-PE, 295 i.e. SPE1. 297 The backup T-PE, backup PW and backup AC are used in the protection 298 against egress AC failure and egress node failure. The backup S-PE 299 and the backup PW are used in the protection against switching node 300 failure, as described later in this document. 302 For consistency with the SS-PW scenario, primary T-PEs and a primary 303 S-PEs may simply be referred to as primary PEs in this document, 304 where specifics is not required. Similarly, backup T-PEs and backup 305 S-PEs may be referred to as backup PEs. 307 4. Theory of Operation 309 The fast protection mechanism in this document provides three types 310 of protection for PWs, corresponding to the three types of failures 311 described in Section 3. 313 a. Egress AC protection 315 b. Egress node protection for (T-)PE 317 c. Switching node protection for S-PE 319 The mechanism is only relevant when the target CE is multi-homed to a 320 primary PE and one or more backup PEs, and when there is a backup PW 321 in the network. In switching node protection, it is also assumed 322 that there SHOULD be a backup S-PE on the backup PW. 324 The mechanism relies on local repair to be performed by routers 325 adjacent to failures. Such a router MUST be able to detect failures 326 by using a rapid mechanism, such as physical layer failure detection, 327 Bidirectional Failure Detection (BFD) [RFC 5880], etc. The router 328 MUST also pre-establish an MPLS LSP, called bypass LSP, in 329 anticipation of failures. This router is referred to as a point of 330 local repair (PLR), as it serves the same role as the PLR in RSVP 331 fast-reroute [RFC 4090]. 333 o In egress AC protection, the PLR is considered as the primary PE 334 that hosts the primary AC. Upon a failure of the primary AC, the 335 PLR invokes the route of the bypass LSP and redirects traffic to a 336 backup PE, which in turn sends the traffic to the CE via a backup 337 AC. 339 o In egress node protection, the PLR is considered as the 340 penultimate hop router of transport LSP of primary PW. Upon a 341 failure of the primary PE, the PLR invokes the route of the bypass 342 LSP and redirects traffic to a backup PE, which in turn sends the 343 traffic to the CE via a backup AC. 345 o In switching node protection, the PLR is considered as the 346 penultimate hop router of transport LSP of current primary PW 347 segment. Upon a failure of primary S-PE, the PLR invokes the 348 route of the bypass LSP and redirects traffic to a backup S-PE 349 LSP. The backup S-PE then sends the traffic via the next segment 350 of the backup PW to the backup T-PE. The backup T-PE finally 351 sends the traffic to the CE via a backup AC. 353 In all the above cases, each backup (S-)PE is said to serve as a 354 "protector" for the primary PW. 356 It is also possible to have a dedicated router serving as a 357 protector. In this case, the protector is not a backup (S-)PE of the 358 primary PW. During a local repair, the PLR still redirects traffic 359 to the protector via a bypass LSP. The protector MUST then send the 360 traffic to a backup (S-)PE via an MPLS LSP. Finally, the backup 361 (S-)PE sends the traffic towards the CE via a backup AC or backup PW 362 segment. 364 In any case, when a PLR redirects traffic to a protector during local 365 repair, it MUST keep the PW label intact. This simplifies the backup 366 forwarding state that the PLR must install in advance, and reduces 367 overheads in setting up the protection. This also means that the 368 protector MUST be able to forward the traffic based on a label that 369 is assigned by the primary PE. From the protector's perspective, 370 this label is an upstream assigned label [RFC 5331]. Hence, the 371 protector MUST look up the label in a context-specific label space. 373 4.1. Protector and Context Identifier 375 A router that protects a PW against egress endpoint failures and is 376 able to forward traffic based on the PW label assigned by the primary 377 PE is called a protector. This is the router that a PLR will 378 redirect traffic to during a local repair. It MUST forward the 379 traffic in such a way that the traffic can eventually reach the 380 target CE. Examples of protector include backup (S-)PE and a 381 dedicated router that assumes such a role. 383 A given protector MAY protect multiple PWs that are terminated at one 384 or multiple primary PEs. Likewise, the PWs terminated at a given 385 primary PE MAY be protected by multiple protectors, each for a subset 386 of the PWs. In any case, each PW is associated with one and only one 387 pair of {primary PE, protector}. 389 For each ordered pair of {primary PE, protector}, an IPv4/v6 address 390 is assigned to identify the two routers and their relationship. This 391 address is referred to as a "context identifier", as it indicates the 392 forwarding context for the protector with regard to the primary PE. 393 Each context identifier MUST be globally unique, or unique within the 394 address space of the network where the primary PE and the protector 395 reside. 397 4.2. Protection Models 399 There are two protection models based on the location and role of a 400 protector. 402 1. Co-located protector 404 In this model, the protector is a backup PE that is directly 405 connected to the target CE via a backup AC, or it is a backup 406 S-PE on a backup PW. That is, the protector is co-located with 407 the backup (S-)PE. 409 In egress AC protection and egress node protection, when a 410 protector receives traffic from the PLR, it MUST send the traffic 411 directly to the CE via the backup AC. This is shown in Figure 4, 412 where PE2 is the PLR for egress AC failure, P3 is the PLR for PE2 413 failure, and PE4 (the backup PE) is the protector. 415 |<-------------- PW1 --------------->| 417 - PE1 -------------- P1 ------- P3 ----- PE2 - 418 / PLR \ PLR \ 419 / \ \ 420 CE1 \ CE2 421 \ \ / 422 \ \ / 423 - PE3 -------------- P2 ---------------- PE4 - 424 protector 426 |<-------------- PW2 --------------->| 428 Figure 4 430 In switching node protection, when a protector receives traffic 431 from the PLR, it MUST send the traffic via the next segment of 432 the backup PW. The T-PE of the backup PW MUST send the traffic 433 to the CE via a backup AC. This is shown in Figure 5, where P4 434 is the PLR for SPE1 failure, and SPE2 (the backup S-PE) serves as 435 the protector for SPE1 (the primary S-PE). 437 |<--------------- PW1 --------------->| 438 |<----- SEG1 ----->|<----- SEG2 ----->| 440 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 441 / PLR \ \ 442 / \ \ 443 CE1 \ CE2 444 \ \ / 445 \ \ / 446 - TPE3 --------------- SPE2 -------------- TPE4 - 447 protector 449 |<----- SEG3 ----->|<----- SEG4 ----->| 450 |<--------------- PW2 --------------->| 452 Figure 5 454 In this model, the number of context identifiers required by a 455 network is the number of distinct {primary PE, backup PE} pairs. 456 Therefore, the model is suitable for scenarios where the number 457 backup PEs for any given primary PE is relatively small. 459 2. Centralized protector 461 In this model, the protector is a dedicated P router or PE router 462 that protects all the primary PWs of one or multiple primary PEs. 463 In egress AC protection and egress node protection, the protector 464 MAY or MAY NOT be a backup PE with a direct connection to the 465 target CE. In switching node protection, it MAY or MAY NOT be a 466 backup S-PE on a backup PW. 468 In egress AC protection and egress node protection, when the 469 protector receives traffic from the PLR, if the protector has a 470 direct connection (i.e. backup AC) to the CE, it MUST send the 471 traffic to the CE via the backup AC, similar to Figure 4. 472 Otherwise, it MUST send the traffic to a backup PE, which MUST 473 then send the traffic to the CE via a backup AC. This is shown 474 in Figure 6, where the protector receives traffic from P3 or PE2 475 (the PLR) and sends the traffic to PE4 (the backup PE). The 476 protector may be protecting other PWs as well, which are not 477 shown. 479 |<-------------- PW1 --------------->| 481 - PE1 -------------- P1 ------- P3 ----- PE2 - 482 / PLR \ PLR \ 483 / \ \ 484 CE1 protector CE2 485 \ \ / 486 \ \ / 487 - PE3 -------------- P2 ---------------- PE4 - 489 |<-------------- PW2 --------------->| 491 Figure 6 493 In switching node protection, when the protector receives traffic 494 from the PLR, if the protector is a backup S-PE on a backup PW, 495 it MUST send the traffic via the next segment of the backup PW, 496 and the T-PE of the backup PW MUST send the traffic to the CE via 497 a backup AC, similar to Figure 5. Otherwise, the protector MUST 498 first send the traffic to an backup S-PE, which MUST then send 499 the traffic via the next segment of the backup PW. Finally, the 500 T-PE of the backup PW MUST send the traffic to the CE via a 501 backup AC. This is shown in Figure 7, where the protector sends 502 traffic to SPE2 (the backup S-PE). The protector may be 503 protecting other PW segments as well, which are not shown. 505 |<--------------- PW1 --------------->| 506 |<----- SEG1 ----->|<----- SEG2 ----->| 508 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 509 / PLR \ \ 510 / \ \ 511 CE1 protector CE2 512 \ \ / 513 \ \ / 514 - TPE3 --------------- SPE2 -------------- TPE4 - 516 |<----- SEG3 ----->|<----- SEG4 ----->| 517 |<--------------- PW2 --------------->| 519 Figure 7 521 In this model, each primary PE MAY only need one protector to 522 protect all of its PWs. Therefore, the number of context 523 identifiers required by a network can be as low as the number of 524 primary PEs. 526 A network MAY use either protection model, or a combination of both, 527 depending on requirements. 529 4.3. Context Identifier Advertisement by IGP 531 The context identifier of a pair of {primary PE, protector} MUST be 532 advertised by IGP and IGP-TE as a virtual node that is connected to 533 both the primary PE and the protector via unnumbered point-to-point 534 links. This virtual node is called a "context node", as shown in 535 Figure 8. This is useful to facilitate path computation and 536 selection for the context identifier (Section 4.4). 538 primary PE - 539 \ (metric 1, TE metric 1, bandwidth max) 540 \ 541 \ 542 \ 543 \ (metric max, TE metric max, bandwidth 0) 544 | 545 context node 546 | 547 / (metric max, TE metric max, bandwidth 0) 548 / 549 / 550 / 551 / (metric max, TE metric max, bandwidth max) 552 protector - 554 Figure 8 556 The advertisement involves the following parts: 558 o The primary PE advertises the context node with two unnumbered 559 links to the primary PE and the protector, respectively. The 560 router ID of the context node is the context identifier. Both 561 unnumbered links are advertised with maximum routable metric, 562 maximum TE metric, and zero bandwidth. Other TE parameters may be 563 advertised for the links based on configuration. 565 In the case of ISIS [ISO10589], the system ID is derived from the 566 context identifier with Binary Coded Decimal (BCD) encoding. The 567 resulting system-ID MUST be unique. The LSP (Link State Packet) 568 MUST include an Area Address TLV, and MAY include a Dynamic 569 Hostname TLV. The area addresses MUST be a subset of or 570 preferably identical to those advertised by the primary PE at the 571 corresponding level. The hostname MAY be derived from the context 572 identifier and the primary PE's hostname. The Overload bit MUST 573 be set to 1. The Attached and the Partition Repair bits MUST be 574 set to 0. 576 In the case of OSPF [RFC 2328], the Advertising Router and Link 577 State ID of the router LSA (Link State Advertisement) MUST both be 578 the context identifier. All options bits in the router LSA MUST 579 be set to zero. 581 o The primary PE advertises an unnumbered link to the context node, 582 with metric 1, TE metric 1, and maximum bandwidth. Other TE 583 parameters may be advertised for the link based on configuration. 585 o The protector advertises an unnumbered link to the context node, 586 with maximum routable metric, maximum TE metric, and maximum 587 bandwidth. Other TE parameters may be advertised for the link 588 based on configuration. 590 4.4. LSP and Context Identifier Association 592 The transport LSP of a primary PW MUST be destined for the context 593 identifier of the {primary PE, protector} of the PW, rather than an 594 address of the primary PE. This MAY be based on configuration or an 595 auto-discovery mechanism. 597 Similarly, a bypass LSP initiated by a PLR towards a protector MUST 598 also be destined for that context identifier, rather than an address 599 of the protector. When the transport LSP is an RSVP signaled LSP and 600 bypass LSP creation is triggered by RSVP fast-reroute mechanism 601 (Section 4.6.1), the bypass LSP MAY inherit the context identifier as 602 the destination from the transport LSP. Otherwise, this MAY be based 603 on configuration as well. 605 Since the context identifier is advertised by IGP and IGP-TE as a 606 context node connected to both the primary PE and the protector, the 607 path computation and selection for these LSPs MUST meet the following 608 requirements. 610 o The transport LSP MUST prefer the primary PE to reach the context 611 identifier. The path MUST be terminated at the primary PE. 613 o The bypass LSP MUST avoid the primary PE, leaving the protector as 614 the only viable router to reach the context identifier. The path 615 MUST be terminated at the protector, and MUST NOT traverse the 616 primary PE. 618 When these LSPs are RSVP signaled LSPs, these requirements can be 619 satisfied by using Constrained Shortest Path First (CSPF) algorithm. 620 When the LSPs are LDP signaled LSPs, it MAY require both the primary 621 PE and the protector to advertise the context identifier as an LDP 622 IPv4/v6 FEC. 624 4.5. PW and Context Identifier Association 626 The ingress PE of a primary PW (or PW segment) MUST associate the PW 627 with the primary (S-)PE, as in normal LDP signaling. 629 The ingress PE MUST also associate the PW with the context identifier 630 of the {primary PE, protector}, and use the context identifier as the 631 destination address to resolve a transport LSP for the PW. As 632 described in Section 4.4, a candidate LSP MUST be destined for the 633 context identifier. The association MAY be based on configuration, 634 or the ingress PE MAY learn it from the primary PE. In the later 635 case, the primary PE MAY advertise the context identifier as "third 636 party next hop" in an IPv4/v6 Interface_ID TLV [RFC 3471, RFC 3472] 637 in LDP Label Mapping message. 639 4.6. Bypass LSP 641 The set of PWs protected by a PLR may be associated with one or 642 multiple pairs of {primary PE, protector}. The PLR MUST establish a 643 bypass LSP to each protector for each distinct context identifier of 644 the protector. The destination of the bypass LSP MUST be the context 645 identifier. 647 For examples, in Figure 4 and Figure 6, a bypass LSP is established 648 from PE2 (PLR for egress AC failure) to the protector, and another 649 bypass LSP is established from P3 (PLR for egress node failure) to 650 the protector. The destinations of both bypass LSPs are the context 651 identifier of {PE2, protector}. In Figure 5 and Figure 7, a bypass 652 LSP is established from P4 (PLR for switching node failure) to the 653 protector. Its destination is the context identifier of {SPE1, 654 protector}. 656 During a local repair, a PLR MUST redirect traffic to the protector 657 via the bypass LSP with PW label intact. Each PW packet will carry a 658 label stack of two labels. The inner label is the PW label, and the 659 outer label is the bypass LSP's label. The protector MUST then 660 forward the traffic based on this PW label, i.e. an upstream assigned 661 label that is assigned by the primary PE. 663 In order for the protector to perform such kind of forwarding, the 664 bypass LSP MUST use ultimate hop popping (UHP) [RFC 3031]. That is, 665 the protector MUST assign an un-reserved label to the bypass LSP. 666 This label indicates the forwarding context, i.e. the context- 667 specific label space of the primary PE, in which all PW packets 668 received on the bypass LSP MUST be forwarded. The protector MUST 669 install a forwarding entry for this label, with a label pop and a 670 nexthop pointing to the context-specific label space. Thus, all 671 packets with an inner label will be forwarded based on a label lookup 672 in that label space. 674 A bypass LSP may be signaled by RSVP or LDP, which may or may not be 675 the same as the signaling protocol of transport LSPs. 677 4.6.1. RSVP Signaled Bypass LSP and Backup LSP 679 If a bypass LSP is an RSVP signaled LSP, its path MAY be statically 680 configured or dynamically computed by CSPF (Section 4.4). 682 If the transport LSP is LDP signaled, the bypass LSP will be a 683 standalone LSP from the PLR to the protector. Its creation MAY be 684 based on configuration. 686 If the transport LSP is RSVP signaled, creation of the bypass LSP 687 depends on specific protection scenarios. In egress AC protection, 688 the PLR is the primary PE. In this case, the bypass LSP is a 689 standalone LSP from the PLR to the protector, and its creation MAY be 690 based on configuration. In egress node protection and switching node 691 protection, the PLR is the penultimate-hop router of the transport 692 LSP. In this case, the PLR MUST rely on the RSVP facility-backup 693 fast-reroute mechanism to create the bypass LSP and perform local 694 repair, as described below. 696 o When the primary PE builds an RRO for Resv message of the 697 transport LSP, it MUST encode the context identifier (i.e. context 698 node) as IPv4/v6 address and implicit NULL (3) as label, before 699 inserting its own address and label. This will allow the PLR to 700 view itself as two hops away from the destination, with the 701 primary PE as nexthop, and the context node as next-nexthop. 703 o The PLR SHOULD start signaling a node-protection bypass LSP based 704 on the "local protection desired" and "node protection desired" 705 bits that are set in SESSION_ATTRIBUTE of Path message of the 706 transport LSP [RFC 2205, RFC 3209, RFC 4090]. 708 o After the bypass LSP is established, the PLR MUST set the "local 709 protection available" and "node protection" bits in the RRO of 710 Resv message of the transport LSP. 712 o In the event of an egress node or switching node failure, the PLR 713 MUST signal a backup LSP [RFC 4090] to the protector via the 714 bypass LSP. The protector MUST terminate the backup LSP as egress 715 router. After the backup LSP is established, PLR MUST set the 716 "local protection in use" bit in the RRO of Resv message of the 717 transport LSP. 719 This procedure only imposes a specific requirement on the primary PE 720 to insert an extra hop in the RRO of Resv message. The PLR SHOULD 721 behave as in normal RSVP facility-backup fast-reroute. In fact, the 722 procedure is transparent to the PLR, and the PLR does not need to be 723 aware of it in order to participate. 725 4.6.2. LDP Signaled Bypass LSP 727 If a bypass LSP is an LDP signaled LSP, its FEC MUST be the context 728 identifier advertised by the protector (Section 4.4). The PLR MUST 729 select this FEC to perform local repair. 731 4.7. Forwarding State on Protector 733 A protector MUST be able to forward traffic based on the PW labels 734 assigned by primary PEs. Hence, it MUST learn the PW labels from the 735 primary PEs, and maintain the labels in a separate context-specific 736 label space [RFC 5331] for each primary PE (Section 4.8). In the 737 control plane, each context-specific label space is identified by the 738 context identifier of associated {primary PE, protector}. When the 739 protector learns a label from a primary PE, it MUST map the label to 740 a context-specific label space via this context identifier. In the 741 forwarding plane, each context-specific label space is indicated by 742 the UHP labels of associated bypass LSPs. 744 In Figure 9, PE4 is a co-located protector that protects PW1 against 745 egress AC failure and egress node failure. It maintains a context- 746 specific label space for PE2, which is identified by the context 747 identifier of {PE2, PE4}. It learns from PE2 the label that PE2 has 748 assigned to PW1, and installs an forwarding entry for the label in 749 the context-specific label space. The nexthop of the forwarding 750 entry indicates a label pop with outgoing interface pointing to the 751 backup AC CE2-PE4. 753 |<-------------- PW1 --------------->| 755 - PE1 -------------- P1 ------- P3 ----- PE2 - 756 / PLR \ PLR \ 757 / \ \ 758 CE1 \ CE2 759 \ \ / 760 \ \ / 761 - PE3 -------------- P2 ---------------- PE4 - 762 protector 764 |<-------------- PW2 --------------->| 766 Figure 9 768 In Figure 10, SPE2 is a co-located protector that protects PW1 769 against switching node failure. It maintains a context-specific 770 label space for SPE1, which is identified by the context identifier 771 of {SPE1, SPE2}. It learns the label that SPE1 has assigned to the 772 PW segment SEG1, and installs a forwarding entry in the context- 773 specific label space. The nexthop of the forwarding entry indicates 774 a label swap to the label of the PW segment SEG4, and then a label 775 push with the label of the transport LSP of SEG4. 777 |<--------------- PW1 --------------->| 778 |<----- SEG1 ----->|<----- SEG2 ----->| 780 - TPE1 ----- P4 ----- SPE1 --------------- TPE2 - 781 / PLR \ \ 782 / \ \ 783 CE1 \ CE2 784 \ \ / 785 \ \ / 786 - TPE3 --------------- SPE2 --------------- TPE4 - 787 protector 789 |<----- SEG3 ----->|<----- SEG4 ----->| 790 |<--------------- PW2 --------------->| 792 Figure 10 794 In the centralized protector model, for each primary PW of which the 795 protector is not a backup (S-)PE, the protector MUST also learn the 796 label of a backup PW from a backup (S-)PE (Section 4.9). This is the 797 backup (S-)PE that the protector will send traffic to. The protector 798 MUST use the label as the outgoing label for the forwarding entry of 799 the primary PW label in the context-specific label space. 801 In Figure 11, the protector is a centralized protector that protects 802 PW1 against egress AC failure and egress node failure. It maintains 803 a context-specific label space for PE2, which is identified by the 804 context identifier of {PE2, protector}. It learns from PE2 the label 805 that PE2 has assigned to PW1, and learns from PE4 the label that PE4 806 has assigned to PW2. It installs a forwarding entry for PW1's label 807 in the context-specific label space. The nexthop of the forwarding 808 entry is a label swap to PW2's label, followed by a label push with 809 the label of a transport LSP from the protector to PE4. 811 |<-------------- PW1 --------------->| 813 - PE1 -------------- P1 ------- P3 ----- PE2 - 814 / PLR \ PLR \ 815 / \ \ 816 CE1 protector CE2 817 \ \ / 818 \ \ / 819 - PE3 -------------- P2 ---------------- PE4 - 821 |<-------------- PW2 --------------->| 823 Figure 11 825 In Figure 12, the protector is a centralized protector that protects 826 the PW segment SEG1 of PW1 against switching node failure of SPE1. 827 It maintains a context-specific label space for SPE1, which is 828 identified by the context identifier of {SPE1, protector}. It learns 829 from SPE1 the label that SPE1 has assigned to SEG1, and learns from 830 SPE2 the label that SPE2 has assigned to SEG3. It installs a 831 forwarding entry for SEG1's label in the context-specific label 832 space. The nexthop of the forwarding entry is a label swap to the 833 label of SEG3, followed by a label push with the label of a transport 834 LSP from the protector to SPE2. 836 |<--------------- PW1 --------------->| 837 |<----- SEG1 ----->|<----- SEG2 ----->| 839 - TPE1 ----- P4 ----- SPE1 -------------- TPE2 - 840 / PLR \ \ 841 / \ \ 842 CE1 protector CE2 843 \ \ / 844 \ \ / 845 - TPE3 --------------- SPE2 -------------- TPE4 - 847 |<----- SEG3 ----->|<----- SEG4 ----->| 848 |<--------------- PW2 --------------->| 850 Figure 12 852 4.8. PW Label Distribution from Primary PE to Protector 854 A primary PE MUST distribute the label of each primary PW to the 855 protector that protects the PW. This PW label is considered as 856 upstream assigned label from the protector's perspective. 858 To achieve this, the primary PE MUST establish a targeted LDP session 859 with the protector. For each primary PW, the primary PE MUST 860 advertise over that session a Protection FEC Element via Label 861 Mapping message. The Protection FEC Element is a new LDP FEC, and 862 its encoding is described below. The PW's label is encoded in the 863 message using the Upstream-Assigned Label TLV defined in [LDP- 864 UPSTREAM]. The Protection FEC Element and the PW label together 865 represent the primary PE's forwarding state for the PW. The Label 866 Mapping message MUST also carry an IPv4/v6 Interface_ID TLV [LDP- 867 UPSTREAM, RFC 3471] encoded with the context identifier of the 868 {primary PE, protector}. 870 The protector that receives this Label Mapping message MUST install a 871 forwarding entry for the PW label in the context-specific label space 872 identified by the context identifier. As mentioned above, the 873 nexthop of the forwarding entry MUST allow packets to be sent towards 874 the target CE via a backup AC or a backup (S-)PE, depending on the 875 protection model and SS-PW or MS-PW scenario involved. 877 The Protection FEC Element has type 0x83. It is defined as below: 879 0 1 2 3 880 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 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Type(0x83) | Reserved | Encoding Type | Length | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | | 885 | | 886 ~ PW Information ~ 887 | | 888 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 Figure 13 894 - Encoding Type 896 Type of format that PW Information field is encoded. 898 - Length 900 Length of PW Information field in octets. 902 - PW Information 903 Field of variable length that specifies a PW 905 For Encoding Type, 1 is defined for the PWid FEC Element format, and 906 2 is defined for the Generalized PWid FEC Element format [RFC 4447]. 908 4.8.1. Protection FEC Element Encoding for PWid 910 0 1 2 3 911 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 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Type(0x83) | Reserved | Enc Type(1) | Length(16) | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Ingress PE Address | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Egress PE Address | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Group ID | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | PW ID | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 |C| PW Type | Reserved | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 Figure 14 928 - Ingress PE Address 930 IP address of the ingress PE of PW. 932 - Egress PE Address 934 IP address of the egress PE of PW. 936 - Group ID 938 An arbitrary 32-bit value that represents a group of PWs and that 939 is used to create groups in the PW space. 941 - PW ID 943 A non-zero 32-bit connection ID that, together with the PW Type 944 field, identifies a particular PW. 946 - Control word bit (C) 947 A bit that flags the presence of a control word on this PW. If C 948 = 1, control word is present; If C = 0, control word is not 949 present. 951 - PW Type 953 A 15-bit quantity that represents the type of PW. 955 4.8.2. Protection FEC Element Encoding for Generalized PWid 957 0 1 2 3 958 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 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Type(0x83) | Reserved | Enc Type(2) | Length | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Ingress PE Address | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Egress PE Address | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 |C| PW Type | Reserved | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | AGI Type | Length | Value | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 ~ AGI Value (contd.) ~ 971 | | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | AII Type | Length | Value | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 ~ SAII Value (contd.) ~ 976 | | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | AII Type | Length | Value | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 ~ TAII Value (contd.) ~ 981 | | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 Figure 15 986 - Ingress PE Address 988 IP address of the ingress PE of PW. 990 - Egress PE Address 991 IP address of the egress PE of PW. 993 - Control word bit (C) 995 A bit that flags the presence of a control word on this PW. If C 996 = 1, control word is present; If C = 0, control word is not 997 present. 999 - PW Type 1001 A 15-bit quantity that represents the type of PW. 1003 - AGI Type, Length, Value, AGI Value 1005 Attachment Group Identifier of PW. 1007 - SAII Type, Length, Value, SAII Value 1009 Source Attachment Individual Identifier of PW. 1011 - TAII Type, Length, Value, TAII Value 1013 Target Attachment Individual Identifier of PW. 1015 4.9. PW Label Distribution from Backup PE to Protector 1017 In the centralized protection model, in addition to learning PW 1018 labels from primary PEs (Section 4.8), a protector MUST also learn 1019 from backup (S-)PEs the labels of backup PWs and backup PW segments 1020 for which the protector is not a backup (S-)PE. 1022 To achieve this, each backup (S-)PE MUST establish a targeted LDP 1023 session with the protector. The backup PE MUST advertise over that 1024 session a Protection FEC Element for the backup PW via Label Mapping 1025 message. The content of this Protection FEC Element MUST match the 1026 Protection FEC Element that the primary PE advertises to the 1027 protector (section 4.8). The Label Mapping message MUST also include 1028 a Generic Label TLV encoded with the backup PW's label. The context 1029 identifier SHOULD not be encoded in Interface_ID TLV in this message. 1030 The Protection FEC Element and the backup PW's label together 1031 represent the backup PE's forwarding state for the backup PW. 1033 The protector that receives this Label Mapping message MUST associate 1034 the backup PW with the primary PW, based on the common Protection FEC 1035 Element. It MUST distinguish between the message from the primary PE 1036 and the message from the backup PE based on the presence and absence 1037 of context identifier in Interface_ID TLV. It MUST install a 1038 forwarding entry for the primary PW's label in the context-specific 1039 label space indentified by the context identifier. The nexthop of 1040 the forwarding entry MUST be a label swap to the backup PW's label, 1041 followed by a label push with the label of a transport LSP from the 1042 protector to the backup PE. 1044 4.10. Revertive Behavior 1046 After a PLR locally repairs a primary PW and redirects traffic to a 1047 protector, there are two strategies for restoring the traffic to a 1048 fully working PW. 1050 o Global revertive mode 1052 While the traffic is taking a detour via the protector, if the 1053 ingress CE is multi-homed (Figure 1), it MAY switch the traffic to 1054 a backup AC which is bound to a backup PW. Or, if the ingress PE 1055 hosts a backup PW (Figure 2), it MAY switch the traffic to the 1056 backup PW. These procedures are referred to as global repair, and 1057 are driven by ingress CE or ingress PE. Possible triggers of 1058 global repair include PW status, OAM, BFD, and control plane 1059 convergence. 1061 o Local revertive mode 1063 The PLR MAY move traffic back to the primary PW, after the failure 1064 is resolved. In egress AC protection, upon detecting that the 1065 primary AC is restored, the PLR MAY start forwarding traffic via 1066 the AC again. Likewise, in egress node protection and switching 1067 node protection, upon detecting that the primary PE is restored, 1068 the PLR MAY re-signal the primary transport LSP to the primary PE. 1069 After the LSP is re-established, the PLR MAY move the traffic back 1070 to the LSP. These procedures are referred to as local reversion. 1072 The fast protection mechanism in this document SHOULD always be used 1073 in tandem with the globally revertive mode. Particularly in the case 1074 of egress (S-)PE failure, if the ingress PE or the protector loses 1075 communication with the (S-)PE for an extensive period of time, the 1076 LDP session between them may go down. Consequently, the ingress PE 1077 may bring down the primary PW, or the protector may delete the 1078 forwarding entry of the primary PW label from the context-specific 1079 label space. In either case, the service will be disrupted. In 1080 other words, although the fast protection can temporarily repair 1081 traffic, control plane states may start to time out if the failure 1082 persists. Therefore, it is recommended that the global revertive 1083 mode SHOULD always be established in advance, so that it can move 1084 traffic to a fully working backup PW shortly after the local repair. 1086 The local revertive mode is optional. In the circumstances where the 1087 failure is caused by resource flapping, local reversion MAY be 1088 dampened to limit potential disruptions. Local revertive mode MAY be 1089 disabled completely by configuration. 1091 5. IANA Considerations 1093 IANA maintains a registry of LDP FECs at the registry "Label 1094 Distribution Protocol" in the sub-registry called "Forwarding 1095 Equivalence Class (FEC) Type Name Space". 1097 This document defines a new LDP Protection FEC Element in 1098 Section 4.8. IANA has assigned the type value 0x83 to it. 1100 6. Security Considerations 1102 The security considerations discussed in RFC 5036, RFC 5331, RFC 1103 3209, and RFC 4090 apply to this document. 1105 7. Acknowledgements 1107 This document leverages work done by Hannes Gredler, Yakov Rekhter, 1108 Minto Jeyananth and several others on MPLS edge protection. Thanks 1109 to Nischal Sheth, Bhupesh Kothari, and Kevin Wang for their 1110 contribution. 1112 8. References 1114 8.1. Normative References 1116 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1117 Edge (PWE3) Architecture", RFC 3985, March 2005. 1119 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 1120 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 1121 October 2009. 1123 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1124 Heron, "Pseudowire Setup and Maintenance Using the Label 1125 Distribution Protocol (LDP)", RFC 4447, April 2006. 1127 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1128 Label Assignment and Context-Specific Label Space", 1129 RFC 5331, August 2008. 1131 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1132 Specification", RFC 5036, October 2007. 1134 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1135 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1136 Functional Specification", RFC 2205, September 1997. 1138 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1139 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1140 Tunnels", RFC 3209, December 2001. 1142 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 1143 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1144 May 2005. 1146 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1147 (GMPLS) Signaling Functional Description", RFC 3471, 1148 January 2003. 1150 [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- 1151 Protocol Label Switching (GMPLS) Signaling Constraint- 1152 based Routed Label Distribution Protocol (CR-LDP) 1153 Extensions", RFC 3472, January 2003. 1155 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1156 Label Switching Architecture", RFC 3031, January 2001. 1158 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1160 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1161 (BFD)", RFC 5880, June 2010. 1163 [LDP-UPSTREAM] 1164 Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment 1165 for LDP", draft-ietf-mpls-ldp-upstream (work in progress), 1166 2011. 1168 [ISO10589] ISO, "Intermediate System to Intermediate System intra- 1169 domain routeing information exchange protocol for use in 1170 conjunction with the protocol for providing the 1171 connectionless-mode network service (ISO 8473)", 1172 International Standard 10589:2002, Second Edition, 2002. 1174 8.2. Informative References 1176 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 1177 Networks", RFC 5920, July 2010. 1179 Authors' Addresses 1181 Yimin Shen (editor) 1182 Juniper Networks 1183 10 Technology Park Drive 1184 Westford, MA 01886 1185 USA 1187 Phone: +1 9785890722 1188 Email: yshen@juniper.net 1190 Rahul Aggarwal 1191 Juniper Networks 1192 1194 N Mathilda Avenue 1193 Sunnyvale, CA 94089 1194 USA 1196 Phone: +1 4089362720 1197 Email: rahul@juniper.net 1199 Wim Henderickx 1200 Alcatel-Lucent 1201 Copernicuslaan 50 1202 2018 Antwerp 1203 Belgium 1205 Email: wim.henderickx@alcatel-lucent.be