idnits 2.17.1 draft-shen-pwe3-endpoint-fast-protection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: At any given time, each CE sends traffic on only one AC and receives traffic on 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 CE and its peer CE. The AC used for the CE to receive traffic is determined by the MPLS network. == 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 PE is a PE that serves as a centralized protector for multiple or all segments which it MAY or MAY NOT have a direct connection to. -- The document date (July 11, 2011) is 4665 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 4090' is mentioned on line 592, but not defined == Missing Reference: 'RFC 5331' is mentioned on line 371, but not defined == Missing Reference: 'RFC 3471' is mentioned on line 556, but not defined == Missing Reference: 'RFC 4447' is mentioned on line 472, but not defined ** Obsolete undefined reference: RFC 4447 (Obsoleted by RFC 8077) == Missing Reference: 'RFC 3472' is mentioned on line 556, but not defined == Missing Reference: 'RFC 2205' is mentioned on line 589, but not defined == Missing Reference: 'RFC 3209' is mentioned on line 589, but not defined == Unused Reference: 'RFC5331' is defined on line 752, but no explicit reference was found in the text == Unused Reference: 'RFC5036' is defined on line 756, but no explicit reference was found in the text == Unused Reference: 'RFC4447' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 763, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'RFC3472' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 784, but no explicit reference was found in the text == Unused Reference: 'RFC5920' is defined on line 800, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 2 errors (**), 0 flaws (~~), 20 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Aggarwal 3 Internet-Draft Y. Shen, Ed. 4 Intended status: Standards Track Juniper Networks 5 Expires: January 12, 2012 July 11, 2011 7 PW Endpoint Fast Failure Protection 8 draft-shen-pwe3-endpoint-fast-protection-00 10 Abstract 12 This document specifies a mechanism for protecting pseudowires (PW) 13 against egress attachment circuit (AC) failure and egress PE failure. 14 Designed on the basis of multi-homed CE, upstream label assignment 15 and context specific label switching, the mechanism enables local 16 repair to be performed immediately upon a failure. In particular, 17 the router at point of local repair (PLR) can redirect PW traffic to 18 a protector PE via a bypass LSP in the order of tens of milliseconds, 19 achieving fast protection that is comparable to MPLS fast reroute. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 12, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 57 3. Reference Model and Failure Cases . . . . . . . . . . . . . . 3 58 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Segment and Context Identifier . . . . . . . . . . . . . . 6 60 4.2. Protector PE and Protection Models . . . . . . . . . . . . 7 61 4.3. Context Identifier Advertisement by IGP . . . . . . . . . 8 62 4.4. Forwarding State on Protector PE . . . . . . . . . . . . . 9 63 4.5. PW Label Distribution from Primary PE to Protector PE . . 10 64 4.6. PW Label Distribution from Backup PE to Protector PE . . . 12 65 4.7. PW and Context Identifier Association at Ingress . . . . . 13 66 4.8. Bypass LSP . . . . . . . . . . . . . . . . . . . . . . . . 13 67 4.8.1. RSVP-TE Signaled Bypass LSP and Backup LSP . . . . . . 14 68 4.8.2. LDP Signaled Bypass LSP . . . . . . . . . . . . . . . 14 69 4.9. CSPF Computation for Path to Context Identifier . . . . . 14 70 5. Egress Link Failure . . . . . . . . . . . . . . . . . . . . . 15 71 5.1. Co-located Protector PE . . . . . . . . . . . . . . . . . 15 72 5.2. Centralized Protector PE . . . . . . . . . . . . . . . . . 16 73 6. Egress Node Failure . . . . . . . . . . . . . . . . . . . . . 17 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 82 1. Introduction 84 This document specifies a fast-protection mechanism for pseudowires 85 (PW) against the following failure cases. 87 a. Egress link failure: Failure of an egress attachment circuit 88 (AC). 90 b. Egress node failure: Failure of an egress PE. 92 The procedures in this document are relevant only when a CE is multi- 93 homed to two or more PEs. They are designed on the basis of MPLS 94 upstream label assignment and context specific label switching [RFC 95 5331]. Fast-protection refers to the ability to provide local repair 96 upon a failure in the order of tens of milliseconds, which is 97 comparable to MPLS fast-reroute [RFC 4090]. This is achieved by 98 establishing local protection as close to a failure as possible. 99 Compared with the existing global repair mechanisms that rely on 100 control plane convergence, these procedures can provide faster 101 restoration for PW traffic. However, they are intended to complement 102 the global repair mechanisms, rather than replacing them in any way. 104 The procedures are relevant to both LDP PWs and BGP based L2VPN. 106 2. Specification of Requirements 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119. 112 3. Reference Model and Failure Cases 114 This document refers to the following topology to describe the 115 solution and failure cases. 117 CE1 -- PE3.........PW2.........PE4 -- CE2 118 \ / 119 \ / 120 \ .........PW1......... / 121 PE1 PE2 122 / .........PW3......... \ 123 / \ 124 / \ 125 CE3 -- PE5.........PW4.........PE6 -- CE4 127 Figure 1 129 The MPLS network consists of PE-routers and P-routers (not shown). 130 It provides emulation of layer-2 services between CE1 and CE2, and 131 between CE3 and CE4. For the purpose of resiliency and fast 132 restoration, each CE is multi-homed to two PEs, and there are two 133 divergent paths between each pair of CEs. 135 o For layer-2 service emulation between CE1 and CE2, the first path 136 uses PW1 established between PE1 and PE2, connecting the AC CE1- 137 PE1 and the AC CE2-PE2; while the second path uses PW2 established 138 between PE3 and PE4, connecting the AC CE1-PE3 and the AC CE2-PE4. 140 o For layer-2 service emulation between CE3 and CE4, the first path 141 uses PW3 established between PE1 and PE2, connecting the AC CE3- 142 PE1 and the AC CE4-PE2; while the second path uses PW4 established 143 between PE5 and PE6, connecting the AC CE3-PE5 and the AC CE4-PE6. 145 At any given time, each CE sends traffic on only one AC and receives 146 traffic on only one AC. The two ACs MAY or MAY NOT be the same. The 147 AC used to send traffic is determined by the CE, and MAY rely on an 148 end-to-end OAM mechanism between the CE and its peer CE. The AC used 149 for the CE to receive traffic is determined by the MPLS network. 151 From the perspective of traffic towards a given a CE, the set of 152 associated PWs, PEs and ACs can be viewed to serve primary and backup 153 roles. When the MPLS network is in a stable condition, the PW that 154 is intended for carrying the traffic to the CE is referred to as a 155 primary PW. The PE at the egress endpoint of the primary PW is a 156 primary PE. The AC connecting the CE and the primary PE is a primary 157 AC. All the other PWs that may be used to carry the traffic to the 158 CE in the event of a network failure are referred to as backup PWs. 159 The PE at the egress endpoint of a backup PW is a backup PE. The AC 160 connecting the CE and a backup PE is a backup AC. 162 In Figure 1, the following primary and backup roles are assigned to 163 the PWs, PEs and ACs. 165 o For traffic that CE1 sends to CE2: 167 Primary PW: PW1 169 Primary PE: PE2 171 Primary AC: CE2-PE2 173 Backup PW: PW2 175 Backup PE: PE4 177 Backup AC: CE2-PE4 179 o For traffic that CE2 sends to CE1: 181 Primary PW: PW1 183 Primary PE: PE1 185 Primary AC: CE1-PE1 187 Backup PW: PW2 189 Backup PE: PE3 191 Backup AC: CE1-PE3 193 o For traffic that CE3 sends to CE4: 195 Primary PW: PW3 197 Primary PE: PE2 199 Primary AC: CE4-PE2 201 Backup PW: PW4 203 Backup PE: PE6 205 Backup AC: CE4-PE6 207 o For traffic that CE4 sends to CE3: 209 Primary PW: PW3 211 Primary PE: PE1 212 Primary AC: CE3-PE1 214 Backup PW: PW4 216 Backup PE: PE5 218 Backup AC: CE3-PE5 220 There are two types of PW endpoint failures, egress link failure and 221 egress node failure. 223 o An egress link failure refers to the failure of a primary AC. In 224 Figure 1, for traffic sent by CE1, an egress link failure is the 225 failure of the AC CE2-PE2. Similarly, for traffic sent by CE2, it 226 is the failure of the AC CE1-PE1. 228 o An egress node failure refers to the node failure of a primary PE. 229 In the above example, for traffic sent by CE1, it is the failure 230 of PE2, and for traffic sent by CE2, it is the failure of PE1. 232 4. Theory of Operation 234 The fast-protection mechanism in this document relies on local repair 235 to be performed at a PLR (point of local repair) that is as close to 236 a failure as possible. In case of an egress link failure, the PLR is 237 considered as the primary PE that is connected to the failed primary 238 AC. While in case of an egress node failure, the PLR is the node 239 that is the penultimate hop of the transport LSP of the primary PW 240 connecting the ingress PE to the primary PE that failed. In both 241 cases, the PLR MUST redirect traffic (i.e. PW packets) to a 242 "protector PE" (Section 4.2) that is protecting the failed AC or PE. 244 4.1. Segment and Context Identifier 246 Each multi-homed CE is said to connect to the PEs on a "segment". A 247 segment is the set of ACs, including one primary AC and one or more 248 backup ACs, that a multi-homed CE uses to connect to a primary PE and 249 one or more backup PEs for a given layer-2 service emulation. 251 A CE MAY have multiple segments connected to the same set of primary 252 PE and backup PEs. A given set of primary PE and backup PEs MAY have 253 multiple CEs connected to them on multiple segments. 255 Each segment is assigned with a context identifier on the primary PE. 256 The context identifier is an IP address that is either globally 257 unique or unique in the private address space of the VPN that the 258 segment belongs to. The granularity of a context identifier is 259 {Primary PE, segment} tuple. However, a given context identifier MAY 260 be assigned to one or multiple segments. For example, a primary PE 261 MAY have a single context identifier for all segments, which is the 262 coarsest granularity of a context identifier. Or, the primary PE MAY 263 have a unique context identifier for each segment, which is the 264 finest granularity of a context identifier. A given context 265 identifier MUST NOT be used by more than one primary PE. 267 In Figure 1, the following segments and context identifiers are 268 assigned for the topology. 270 o CE1 is dual-homed to PE1 (primary PE) and PE3 (backup PE) on 271 segment1 with context1. 273 o CE2 is dual-homed to PE2 (primary PE) and PE4 (backup PE) on 274 segment2 with context2. 276 o CE3 is dual-homed to PE1 (primary PE) and PE5 (backup PE) on 277 segment3 with context3. 279 o CE4 is dual-homed to PE2 (primary PE) and PE6 (backup PE) on 280 segment4 with context4. 282 4.2. Protector PE and Protection Models 284 A PE that protects one or more segments is referred to as a protector 285 PE. For a given segment, the protector PE MAY be a backup PE on the 286 segment, or an egress PE that is not directly connected to the 287 segment. Hence, there are two protection models based on the 288 location and role of a protector PE. 290 1. Co-located protector PE 292 In this model, the protector PE is a backup PE on the protected 293 segment. It is co-located with the primary PE on the segment, 294 and it has a direct connection to the CE via a backup AC. 296 In the event of an egress link or node failure, the protector PE 297 receives traffic from the PLR, and sends the traffic directly to 298 the CE via the backup AC. 300 In this model, the coarsest granularity of context identifier 301 assignment is per {primary PE, protector PE}. 303 In Figure 1, PE1 is a primary PE that has two segments, segment1 304 and segment3. PE3 is the protector PE for segment1, and PE5 is 305 the protector PE for segment3. PE3 and PE5 are directly 306 connected to the respective segments. When segment 1 fails, the 307 PLR sends traffic to PE3, and PE3 in turn sends the traffic to 308 CE1. Similarly, when segment3 fails, the PLR sends traffic to 309 PE5, and PE5 in turn sends the traffic to CE3. 311 2. Centralized protector PE 313 In this model, the protector PE is a PE that serves as a 314 centralized protector for multiple or all segments which it MAY 315 or MAY NOT have a direct connection to. 317 In the event of an egress link or node failure, for a directly 318 connected segment, the protector PE receives traffic from the PLR 319 and sends traffic to the CE via a backup AC. For a segment that 320 is not directly connected to, the protector PE MUST send the 321 traffic to a backup PE on that segment, which in turn sends the 322 traffic to the CE via a backup AC. 324 In this model, the coarsest granularity of context identifier 325 assignment is per primary PE. 327 In Figure 1, PE2 is a primary PE that has two segments, segment2 328 and segment4. Both segments are protected by PE4, which acts as 329 a centralized protector PE. PE4 has a direct connection only to 330 segment2, not to segment4. When segment2 fails, the PLR sends 331 traffic to PE4, and PE4 in turn sends the traffic to CE1. 332 However, when segment4 fails, the PLR sends traffic to PE4, and 333 PE4 MUST send the traffic to PE6 which in turn sends traffic to 334 CE4. 336 A network MAY use either protection model or a combination of both, 337 depending on requirements. 339 4.3. Context Identifier Advertisement by IGP 341 IGP MUST advertise context identifiers to allow computation of TE 342 paths for bypass LSPs and PW transport LSPs that are destined for 343 context identifiers. The details of these LSPs and the TE path 344 computation will be described later in Section 4.7, Section 4.8, and 345 Section 4.9. 347 A primary PE MUST advertise a context identifier as a stub link. it 348 MUST NOT advertise it in IGP TE. 350 A protector PE MUST also advertise the context identifier as a stub 351 link, but with a metric that is higher than the metric of the stub 352 link advertised by the primary PE. The protector PE MUST NOT 353 advertise the context identifier in IGP TE. 355 In Figure 1, PE1, i.e. the primary PE, advertises context1 and 356 context3 in IGP as stub links with metric X1 and X2, respectively. 357 Meanwhile, PE3 and PE5, i.e. the protector PEs, also advertise 358 context1 and context3 in IGP as stub links with metric Y1 and Y2, 359 respectively. It is required that metric X1 SHOULD be lower than Y1, 360 and metric X2 be lower than Y2. 362 4.4. Forwarding State on Protector PE 364 A protector PE MUST learn the forwarding state of all the segments 365 that it protects from the primary PEs, and maintain the forwarding 366 state in context-specific label spaces on a per primary PE basis. In 367 particular, the protector PE MUST learn the labels that the primary 368 PEs have assigned to the primary PWs on the segments, as well as the 369 context identifiers of the segments. For each PW label with an 370 associated context identifier, the protector PE MUST map the context 371 identifier to a context-specific label space [RFC 5331], and program 372 the PW label in that label space in forwarding plane. For a given 373 primary PE, the protector PE MAY maintain state for only a subset of 374 the segments or for all the segments. 376 In the centralized protection model, for each segment that is not 377 directly connected, a protector PE MUST also learn the forwarding 378 state from at least one backup PE of the segment. This is the backup 379 PE that the protector PE will forward traffic to upon a failure of 380 the segment. In particular, the protector PE MUST learn the PW label 381 that the backup PE has assigned to its backup PW. 383 In Figure 1, PE3 is a co-located protector PE protecting segment1 for 384 PE1, i.e. the primary PE. PE3 learns the label that PE1 has assigned 385 for PW1, and context1 that PE1 has assigned to segment1. PE3 386 maintains the PW label to segment1 binding in the context-specific 387 label space for PE1. This is the context-specific label space that 388 context1 is mapped to. 390 In Figure 1, PE4 is a centralized protector PE protecting both 391 segment2 and segment4 for PE2, i.e. the primary PE. PE4 learns the 392 labels that PE2 has assigned to PW1 and PW3, and context2 and 393 context4 that PE2 has assigned to the segments. PE4 maintains the PW 394 label to segment bindings in the context-specific label space for 395 PE2. This is the context-specific label space that both context2 and 396 context4 are mapped to. Since PE4 does not have a direct connection 397 to segment4, it also learns the label that PE6 has assigned to PW4. 398 When PE4 forwards packets to PE6, it swaps the PW label (assigned by 399 PE2) in the received packets to this PW label. 401 In Figure 1, if context1 is different from context3, PE3 and PE5 have 402 the entire forwarding state of PE1 for context1 and context3 403 respectively. In this case, PE3 and PE5 can protect against both 404 egress link and node failures for segment1 and segment3 respectively. 405 However, if context1 and context3 are the same, the centralized 406 protector PE model MUST be adopted, and one of PE3 and PE5 or some 407 other PE MUST act as a centralized protector PE. 409 4.5. PW Label Distribution from Primary PE to Protector PE 411 A primary PE MUST distribute PW label to segment bindings to the 412 protector PE that protects the segments. These PW labels are 413 considered as upstream assigned labels from the protector PE's 414 perspective. 416 For BGP signaled PWs, distribution of such labels from a primary PE 417 to a protector PE is relatively straightforward, as IBGP updates are 418 received by all PEs, and this provides the protector PE with the 419 necessary information. 421 For LDP signaled PWs, a primary PE MUST establish a targeted LDP 422 session with each protector PE that protects its segments. For each 423 segment, the primary PE MUST advertise a Protection FEC Element via 424 Label Mapping message. The Protection FEC Element is a new LDP FEC, 425 and its encoding is described below. A label is encoded in the 426 message using the Upstream-Assigned Label TLV defined in [LDP- 427 UPSTREAM]. This MUST be the same label that the primary PE has 428 assigned to the PW for the primary AC. The Protection FEC Element 429 and the PW label together represent the primary PE's forwarding state 430 for the segment. The Label Mapping message MUST also carry an IPv4 431 IF_ID TLV [LDP-UPSTREAM, RFC 3471] with an IPv4 address encoded with 432 the context identifier of the segment. The protector PE that 433 receives this Label Mapping message MUST program a forwarding state 434 for the PW label in the context-specific label space identified by 435 the context identifier. The next-hop of the forwarding state MUST 436 allow sending packets to the CE via a backup AC or to a backup PE. 438 Protection FEC Element 440 The Protection FEC Element has type 0x83, and it is defined as 441 follows: 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Type(0x83) | Reserved | Encoding Type | Length | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | | 449 | | 450 ~ PW Information ~ 451 | | 452 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Figure 2 458 - Encoding Type 460 Type of format that the PW Information field is encoded. 462 - Length 464 Length of the PW Information field in octets. 466 - PW Information 468 Field of variable length that specifies a PW of a protected 469 segment. 471 In this document, only Encoding Type 1 is defined to represent the 472 format of PWid FEC Element [RFC 4447]. In this case, a Protection 473 FEC element looks like below. 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type(0x83) | Reserved | Enc Type(1) | Length(16) | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Ingress PE Address | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Group ID | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | PW ID | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 |C| PW Type | Reserved | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 Figure 3 491 - Ingress PE Address 493 IP address of the ingress PE of the PW. 495 - Group ID 497 An arbitrary 32-bit value that represents a group of PWs that is 498 used to create groups in the PW space. 500 - PW ID 502 A non-zero 32-bit connection ID that, together with the PW type, 503 identifies a particular PW. 505 - Control word bit (C) 507 The bit (C) is used to flag the presence of a control word. If C 508 = 1, control word is present on this PW; If C = 0, no control word 509 is present on this PW. 511 - PW Type 513 A 15-bit quantity containing a value that represents the type of 514 PW. 516 4.6. PW Label Distribution from Backup PE to Protector PE 518 In the centralized protector PE model, if a protector PE does not 519 have a direct connection to a protected segment, the protector PE 520 MUST learn the PW label to segment binding from a backup PE on that 521 segment. 523 For BGP signaled PWs, such label distribution from a backup PE to a 524 protector PE can rely on normal IBGP updates, as they are received by 525 all PEs. 527 For LDP signaled PWs, a protector PE MUST establish a targeted LDP 528 session with a backup PE on each segment that the protector PE does 529 not have a direct connection to. The backup PE MUST advertise a 530 Protection FEC Element for the segment via Label Mapping message. 531 The content of this Protection FEC Element MUST be the same as the 532 Protection FEC Element that the primary PE sends to the protector PE 533 (Section 4.5). The Label Mapping message MUST also include a Generic 534 Label TLV encoded with the label that the backup PE has assigned to a 535 backup PW. No context identifier SHOULD be encoded in this message. 536 The Protection FEC Element and the PW label represent the backup PE's 537 forwarding state for the segment. The protector PE that receives 538 this Label Mapping message MUST associate the PW label with the PW 539 label learned from the primary PE, using the common Protection FEC 540 Element. It MUST program a forwarding state with label swap from the 541 primary PE's PW label to the backup PE's PW label, in the context- 542 specific label space indentified by the context identifier. The 543 next-hop of the forwarding state MUST allow sending packets to the 544 backup PE. 546 4.7. PW and Context Identifier Association at Ingress 548 The ingress PE of a primary PW MUST be able to associate the PW with 549 the primary PE, using a context identifier. This is the context 550 identifier that the primary PE has assigned to the segment that hosts 551 the remote egress AC. 553 For LDP PWs, the above information can be learned by the ingress PE 554 based on configuration. Alternatively, the primary PE can advertise 555 the context identifier in Label Mapping message as a "third party 556 next-hop" using the IPv4 IF_ID TLV [RFC 3471, RFC 3472] by encoding 557 the IPv4 context identifier as an IPv4 IF_ID TLV. 559 The ingress PE MUST also use the context identifier as a destination 560 address to resolve a transport LSP for the PW. If the transport LSP 561 is an RSVP-TE signaled LSP, the ingress PE MUST be able to compute a 562 TE path to the context identifier (Section 4.9). If the transport 563 LSP is an LDP signaled LSP, the primary PE MUST advertises the 564 context identifier as an LDP IPv4 FEC. 566 4.8. Bypass LSP 568 An LSP MUST be either manually or automatically provisioned on a PLR 569 to enable the PLR to send traffic to a protector PE, in the event of 570 an egress link or node failure. This LSP is referred to as a bypass 571 LSP. 573 The bypass LSP MUST be a LSP with ultimate hop popping (UHP) [RFC 574 3031]. That is, the protector PE MUST assign an un-reserved label to 575 the bypass LSP. When the protector PE receives PW packets on the 576 bypass LSP from a PLR, it MUST rely on the bypass LSP's UHP label to 577 determine the context-specific label space to forward the packets. 579 4.8.1. RSVP-TE Signaled Bypass LSP and Backup LSP 581 If a bypass LSP is an RSVP-TE signaled LSP, its destination MUST be 582 the context identifier of the protected segment. The path taken by 583 the bypass LSP MAY be statically configured or dynamically computed 584 by CSPF (Section 4.9). 586 In case of egress node protection, the signaling of the bypass LSP 587 MUST be triggered by the "local protection desired" and "node 588 protection desired" bits in SESSION_ATTRIBUTE of Path message of the 589 transport LSP [RFC 2205, RFC 3209, RFC 4090]. After the bypass LSP 590 is established, the PLR MUST set the "local protection available" and 591 "node protection" bits in RRO of Resv message of the transport LSP. 592 The PLR MUST also signal a backup LSP [RFC 4090] to the protector PE 593 through the bypass LSP before an egress node failure. The protector 594 PE MUST terminate the backup LSP as an egress. With this pre- 595 signaled backup LSP, the protector PE is ready to process LSP ping 596 and traceroute for the transport LSP immediately after an egress node 597 failure without delay. Once the local repair takes effect, the PLR 598 MUST set the "local protection in use" bit in RRO of Resv message of 599 the transport LSP. 601 4.8.2. LDP Signaled Bypass LSP 603 If a bypass LSP is a LDP signaled LSP, the LDP FEC for this LSP MUST 604 be the context identifier of the protected segment. 606 4.9. CSPF Computation for Path to Context Identifier 608 CSPF computation for path to a context identifier MAY be required for 609 an RSVP-TE signaled transport LSP at an ingress (Section 4.7), or for 610 an RSVP-TE signaled bypass LSP at a PLR (Section 4.8.1). 612 For a transport LSP, the mechanism relies on procedures that are 613 similar to how inter-domain RSVP-TE LSPs are computed. The router 614 first checks if the destination, i.e. the context identifier, is 615 reachable in the TE domain. In this case, it is not, as the context 616 identifier is not advertised in IGP TE. The router then checks to 617 see if there is an IGP route to that destination. In this case, 618 there is an IGP route, as the context identifier is advertised by 619 both the primary PE and the protector PE as a stub link in IGP. The 620 router then selects the PE that is advertising the context identifier 621 with the lowest metric, i.e. the primary PE, and runs CSPF to compute 622 a TE path to it. Finally, the router appends the context identifier 623 as a loose ERO hop to the computed TE path to form a final explicit 624 route. 626 For a bypass LSP, the mechanism is similar to the above, except that 627 it MUST exclude the primary PE when selecting an advertising router 628 of the context identifier. Hence, the protector PE SHOULD be 629 selected. The computed path SHOULD start from the PLR and end at the 630 protector PE, avoiding the primary PE. 632 5. Egress Link Failure 634 This section summarizes the procedures described in Section 4 for the 635 scenario where only egress link protection is desired. It is assumed 636 that ACs, PWs and transport LSPs have been provisioned. 638 5.1. Co-located Protector PE 640 A primary PE and a protector PE (i.e. backup PE) both advertise the 641 context identifier of a protected segment in IGP as a stub link, with 642 the primary PE advertising a lower metric than the protector PE. The 643 primary PE (i.e. PLR) establishes a bypass LSP to the protector PE. 644 The destination address of the bypass LSP is the context identifier. 645 If TE path computation is needed for the bypass LSP, the primary PE 646 MUST use the procedure described in Section 4.9. If RSVP is used to 647 signal the bypass LSP, the bypass LSP must be signal with non-PHP 648 bit, as specified in [RSVP-NON-PHP-OOB]. The protector PE learns the 649 PW label to segment binding and the context identifier from the 650 primary PE via targeted LDP or BGP. The protector PE programs 651 forwarding state in a way that packets received on the bypass LSP 652 will be forwarded based on PW label in the context-specific label 653 space of the primary PE that is indicated by the UHP label of the 654 bypass LSP, i.e. the context identifier. 656 When the primary PE receives a PW packet from the MPLS network, if 657 the egress AC is down, the primary PE tunnels the packet through the 658 bypass LSP to the protector PE. The protector PE identifies the 659 forwarding context of the primary PE based on the top label of the 660 packet which is the UHP label of the bypass LSP. The protector PE 661 then forwards the packet based on a second label lookup in the 662 primary PE's context label space. This second label is the PW label 663 that was assigned by the primary PE. This label lookup results in 664 forwarding the packet to the CE via a backup AC. 666 5.2. Centralized Protector PE 668 The scheme outlined in Section 5.1 requires a bypass LSP for each 669 context identifier where the granularity of a context identifier 670 allocation is {Primary PE, Protector PE}. There may be as many 671 protector PEs as the number of backup PEs. 673 It is desirable to support a scheme where a single protector PE is 674 used to protect all segments, irrespective of whether this protector 675 PE has direct connections to the segments or not. To achieve this, 676 only a single context identifier is assigned by a primary PE to all 677 protected segments. The primary PE then maintains a targeted LDP 678 session with the protector PE to distribute PW labels. For each 679 segment that is not directly connected to the protector PE, at least 680 one backup PE needs to maintain a targeted LDP session with the 681 protector PE to distribute its PW labels. 683 The primary PE and the protector PE both advertise the context 684 identifier in IGP as a stub link, with the primary PE advertising a 685 lower metric than the protector PE. The primary PE (i.e. PLR) 686 establishes a bypass LSP to the protector PE. The destination 687 address of the bypass LSP is the context identifier. If TE path 688 computation is needed for the bypass LSP, the primary PE MUST use the 689 procedure described in Section 4.9. If RSVP is used to signal the 690 bypass LSP, the bypass LSP must be signal with non-PHP bit, as 691 specified in [RSVP-NON-PHP-OOB]. The protector PE learns the PW 692 label to segment binding and the context identifier from the primary 693 PE via targeted LDP or BGP. The protector PE programs forwarding 694 state in a way that packets received on the bypass LSP will be 695 forwarded based on PW label in the context-specific label space of 696 the primary PE that is indicated by the UHP label of the bypass LSP, 697 i.e. the context identifier. 699 When the PLR receives a PW packet from the MPLS network, if the 700 egress AC is down, the PLR tunnels the packet through the bypass LSP 701 to the protector PE. The protector PE identifies forwarding context 702 of the primary PE based on the top label that is the UHP label of the 703 bypass LSP. It then forwards the packet based on a second MPLS label 704 lookup in the primary PE's context label space. This second MPLS 705 label is the PW label that was assigned by the primary PE. If the 706 protector PE has a direct connection to the protected segment, this 707 label lookup results in forwarding the packet to the CE via a backup 708 AC. Otherwise, the protector PE swaps the PW label in the received 709 packet to the PW label assigned by a backup PE, and then forwards the 710 packet to that backup PE. 712 6. Egress Node Failure 714 For egress node protection, the procedures for co-located protector 715 PE and centralized protector PE are similar to Section 5.1 and 716 Section 5.2 respectively, with a few differences outlined below. 718 o The PLR is the penultimate hop of the transport LSP. When it 719 receives a packet of the transport LSP, if the egress PE is down, 720 it tunnels the PW packet through a bypass LSP to the protector PE. 722 o If the bypass LSP is an RSVP-TE signaled LSP, its establishment 723 MUST be triggered by the node protection signaling of the 724 transport LSP. The PLR MUST also pre-signal a backup LSP through 725 a bypass LSP to the protector PE, before an egress node failure 726 occurs. 728 7. IANA Considerations 730 IANA maintains a registry of LDP FECs at the registry "Label 731 Distribution Protocol" in the sub-registry called "Forwarding 732 Equivalence Class (FEC) Type Name Space". 734 This document defines a new LDP Protection FEC Element in 735 Section 4.5. IANA has assigned the type value 0x83 to it. 737 8. Security Considerations 739 The security considerations discussed in RFC 5036, RFC 5331, RFC 740 3209, and RFC 4090 apply to this document. 742 9. Acknowledgements 744 This document leverages work done by Hannes Gredler, Yakov Rekhter 745 and several others on LSP tail-end protection. Thanks to Nischal 746 Sheth, Bhupesh Kothari, and Kevin Wang for their contribution. 748 10. References 750 10.1. Normative References 752 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 753 Label Assignment and Context-Specific Label Space", 754 RFC 5331, August 2008. 756 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 757 Specification", RFC 5036, October 2007. 759 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 760 Heron, "Pseudowire Setup and Maintenance Using the Label 761 Distribution Protocol (LDP)", RFC 4447, April 2006. 763 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 764 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 765 Functional Specification", RFC 2205, September 1997. 767 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 768 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 769 Tunnels", RFC 3209, December 2001. 771 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 772 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 773 May 2005. 775 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 776 (GMPLS) Signaling Functional Description", RFC 3471, 777 January 2003. 779 [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- 780 Protocol Label Switching (GMPLS) Signaling Constraint- 781 based Routed Label Distribution Protocol (CR-LDP) 782 Extensions", RFC 3472, January 2003. 784 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 785 Label Switching Architecture", RFC 3031, January 2001. 787 [LDP-UPSTREAM] 788 Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment 789 for LDP", draft-ietf-mpls-ldp-upstream (work in progress), 790 2011. 792 [RSVP-NON-PHP-OOB] 793 Ali, A., Swallow, Z., and R. Aggarwal, "Non PHP Behavior 794 and out-of-band mapping for RSVP-TE LSPs", 795 draft-ietf-mpls-rsvp-te-no-php-oob-mapping (work in 796 progress), 2011. 798 10.2. Informative References 800 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 801 Networks", RFC 5920, July 2010. 803 Authors' Addresses 805 Rahul Aggarwal 806 Juniper Networks 807 1194 N Mathilda Avenue 808 Sunnyvale, CA 94089 809 USA 811 Phone: +1 4089362720 812 Email: rahul@juniper.net 814 Yimin Shen (editor) 815 Juniper Networks 816 10 Technology Park Drive 817 Westford, MA 01886 818 USA 820 Phone: +1 9785890722 821 Email: yshen@juniper.net