idnits 2.17.1 draft-ietf-pwe3-redundancy-bit-09.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 : ---------------------------------------------------------------------------- ** There are 16 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 940 has weird spacing: '...are set by a ...' (Using the creation date from RFC4447, updated by this document, for RFC5378 checks: 2002-08-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 4, 2013) is 4123 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '10' is defined on line 1079, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (ref. '2') (Obsoleted by RFC 8077) == Outdated reference: A later version (-13) exists of draft-ietf-l2vpn-vpls-ldp-mac-opt-05 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Praveen Muley, Ed. 2 Internet Draft Mustapha Aissaoui, Ed. 3 Updates: RFC 4447 Alcatel-Lucent 4 Intended Status: Standards Track 5 Expires: July 4, 2013 January 4, 2013 7 Pseudowire Preferential Forwarding Status Bit 8 draft-ietf-pwe3-redundancy-bit-09.txt 10 Abstract 12 This document describes a mechanism for signaling the active and 13 standby status of redundant pseudowires (PWs) between their 14 termination points. A set of redundant PWs is configured between 15 provider edge (PE) nodes in single-segment pseudowire (SS-PW) 16 applications, or between terminating provider edge (T-PE) nodes in 17 multi-segment pseudowire (MS-PW) applications. 19 In order for the PE/T-PE nodes to indicate the preferred PW to use 20 for forwarding PW packets to one another, a new status bit is 21 defined. This bit indicates a preferential forwarding status with a 22 value of Active or Standby for each PW in a redundant set. 24 In addition, a second status bit is defined to allow peer PE nodes 25 to coordinate a switchover operation of the PW. 27 Finally, this document updates RFC 4447 by adding details to the 28 handling of the PW Status Code bits in the PW Status TLV. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other documents 42 at any time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 4, 2013. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Requirements Language 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC-2119 [1]. 67 Table of Contents 69 1. Introduction...................................................3 70 2. Motivation and Scope...........................................4 71 3. Terminology....................................................6 72 4. PE Architecture................................................8 73 5. Modes of Operation.............................................9 74 5.1. Independent Mode:.........................................9 75 5.2. Master/Slave Mode:.......................................12 76 6. PW State Transition Signaling Procedures......................14 77 6.1. PW Standby Notification Procedures in Independent mode...14 78 6.2. PW Standby notification procedures in Master/Slave mode..15 79 6.2.1. PW State Machine....................................15 80 6.3. Coordination of PW Switchover............................17 81 6.3.1. Procedures at the requesting endpoint...............18 82 6.3.2. Procedures at the receiving endpoint................19 83 7. Status Mapping................................................20 84 7.1. AC Defect State Entry/Exit...............................20 85 7.2. PW Defect State Entry/Exit...............................20 86 8. Applicability and Backward Compatibility......................21 87 9. Security Considerations.......................................21 88 10. MIB Considerations...........................................22 89 11. IANA Considerations..........................................22 90 11.1. Status Code for PW Preferential Forwarding Status.......22 91 11.2. Status Code for PW Request Switchover Status............22 92 12. Contributors.................................................22 93 13. Acknowledgments..............................................23 94 14. References...................................................24 95 14.1. Normative References....................................24 96 14.2. Informative References..................................24 97 15. Appendix A - Applications of PW Redundancy Procedures........25 98 15.1. One Multi-homed CE with single SS-PW redundancy.........25 99 15.2. Multiple Multi-homed CEs with single SS-PW redundancy...27 100 15.3. Multi-homed CE with MS-PW redundancy....................28 101 15.4. Multi-homed CE with MS-PW redundancy and S-PE protection29 102 15.5. Single Homed CE with MS-PW redundancy...................31 103 15.6. PW redundancy between H-VPLS MTU-s and PE-rs............33 104 Authors' Addresses...............................................34 106 1. Introduction 108 This document provides the extensions to the pseudowire (PW) control 109 plane to support the protection schemes of the PW redundancy 110 applications described in RFC6718 (PW Redundancy [8]). 112 It specifies a new PW status bit as well as the procedures provider 113 edge (PE) nodes follow to notify one another of the preferential 114 forwarding state of each PW in the redundant set i.e. active or 115 standby. This status bit is different from the PW status bits 116 already defined in RFC 4447, the pseudowire setup and maintenance 117 protocol [2]. In addition, this document specifies a second status 118 bit to allow peer PE nodes to coordinate a switchover operation of 119 the PW from active to standby, or vice versa. 121 As a result of the introduction of these new status bits, this 122 document updates RFC 4447 by clarifying the rules for processing 123 status bits not originally defined in RFC 4447. It also updates RFC 124 4447 by defining that status bit can indicate a status other than a 125 fault or can indicate an instruction to the peer PE. See more 126 details in Section 8. 128 Section 15. 15 shows in detail how the mechanisms described in this 129 document are used to achieve the desired protection schemes of the 130 applications described in [8]. 132 2. Motivation and Scope 134 The PW setup and maintenance protocol defines the following status 135 codes in the PW status TLV to indicate the state for an AC and a PW 136 [7]: 138 0x00000000 - Pseudowire forwarding (clear all failures) 140 0x00000001 - Pseudowire Not Forwarding 142 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 144 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 146 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 148 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 150 The applications defined in [8] allow the provisioning of a primary 151 PW and one or many secondary backup PWs in the same Virtual Private 152 Wire Service (VPWS) or Virtual Private LAN Service (VPLS). The 153 objective of PW redundancy is to maintain end-to-end connectivity 154 for the emulated service by activating the correct PW whenever an 155 AC, a PE, or a PW fails. The correct PW means the one which provides 156 the end-to-end connectivity from CE to CE such that packets continue 157 to flow. 159 A PE node makes a selection of which PW to activate at any given 160 time for the purpose of forwarding user packets. This selection 161 takes into account the local state of the PW and AC, as well as the 162 remote state of the PW and AC as indicated in the PW status bits it 163 received from the peer PE node. 165 In the absence of faults, all PWs are up both locally and remotely 166 and a PE node needs to select a single PW to forward user packets 167 to. This is referred to as the active PW. All other PWs will be in 168 standby and must not be used to forward user packets. 170 In order for both ends of the service to select the same PW for 171 forwarding user packets, this document defines a new status bit, the 172 Preferential Forwarding status bit, and the procedures the PE nodes 173 follow to indicate the preferential forwarding state of a PW to its 174 peer PE node. 176 In addition, a second status bit is defined to allow peer PE nodes 177 to coordinate a switchover operation of the PW if required by the 178 application. This is known as the 'request switchover' status bit. 180 Together, the mechanisms described in this document achieve the 181 following protection capabilities defined in [8]: 183 a. A 1:1 protection in which a specific subset of a path for an 184 emulated service, consisting of a standby PW and/or AC, 185 protects another specific subset of a path for the emulated 186 service, consisting of an active PW and/or AC. . An active PW 187 can forward data traffic and control plane traffic, such as 188 Operations, Administration, and Maintenance (OAM) packets. A 189 standby PW does not carry data traffic. 191 b. An N:1 protection scheme in which N specific subsets of a path 192 for an emulated service, consisting each of a standby PW 193 and/or AC, protects a specific subset of a path for the 194 emulated service, consisting of an active PW and/or AC. . 196 c. A mechanism to allow PW endpoints to coordinate the switchover 197 to a given PW by using an explicit request/acknowledgment 198 switchover procedure. This mechanism is complementary to the 199 Independent mode of operation and is described in Section 6.3. 200 6.3 . This mechanism can be invoked manually by the user, 201 effectively providing a manual switchover capability. It can 202 also be invoked automatically to resolve a situation where the 203 PW endpoints could not match the two directions of the PW. 205 d. A locally configured precedence to govern the selection of a 206 PW when more than one PW qualifies for the active state, as 207 defined in sections 5.1. 5.1 and 5.2. 5.2 . The PW with the 208 lowest precedence value has the highest priority. Precedence 209 may be configured via, for example, a local configuration 210 parameter at the PW endpoint. 212 e. Implementations can designate by configuration one PW in the 213 1:1 or N:1 protection as a primary PW and the remaining as 214 secondary PWs. If more than one PW qualify for the active 215 state, as defined in sections 5.1. 5.1 and 5.2. 5.2 , a PE 216 node selects the primary PW in preference to a secondary PW. 217 In other words, the primary PW has implicitly the lowest 218 precedence value. Furthermore, a PE node reverts to the 219 primary PW immediately after it comes back up or after the 220 expiration of a delay effectively achieving revertive 221 protection switching. 223 1+1 protection in which one specific subset of a path for an 224 emulated service, consisting of a standby PW and/or AC, protects 225 another specific subset of a path for the emulated service is not 226 supported. 228 The above protection schemes are provided using the following 229 operational modes: 231 1. An independent mode of operation in which each PW endpoint 232 node uses its own local rule to select which PW it intends 233 to activate at any given time and advertises it to the 234 remote endpoints. Only a PW which is up and which 235 indicated Active status bit locally and remotely is in the 236 active state and can be used to forward data packets. This 237 is described in Section 5.1. 239 2. A Master/Slave mode in which one PW endpoint, the Master 240 endpoint, selects and dictates to the other endpoint(s), 241 the Slave endpoint(s), which PW to activate. This is 242 described in Section 5.2. 244 Note that this document specifies the mechanisms to support PW 245 redundancy where a set of redundant PWs terminate on either a PE, in 246 the case of a single-segment pseudowire (SS-PW), or on a terminating 247 provider edge (T-PE)in the case of a multi-segment pseudowire (MS- 248 PW). PW redundancy scenarios where the redundant set of PW segments 249 terminates on an S-PE are for further study. 251 3. Terminology 253 Pseudowire (PW): A mechanism that carries the essential elements 254 of an emulated service from one PE to one or 255 more other PEs over a PSN [9]. 257 Single-Segment Pseudowire (SS-PW): A PW set up directly between 258 two T-PE devices. The PW label is unchanged between the 259 originating and terminating T-PEs [6]. 261 Multi-Segment Pseudowire (MS-PW): A static or dynamically 262 configured set of two or more contiguous PW segments that 263 behave and function as a single point-to-point PW. Each 264 end of an MS-PW, by definition, terminates on a T-PE [6]. 266 Up PW: A PW which has been configured (label mapping exchanged 267 between PEs) and is not in any of the PW or AC defect 268 states specified in [7]. Such a PW is available for 269 forwarding traffic [8]. 271 Down PW: A PW that has either not been fully configured, or has been 272 configured and is in any of the PW or AC defect states 273 specified in[7], such a PW is not available for forwarding 274 traffic [8]. 276 Active PW: An up PW used for forwarding user, OAM and control plane 277 traffic [8]. 279 Standby PW: An up PW that is not used for forwarding user traffic, 280 but may forward OAM and specific control plane traffic [8]. 282 Primary PW: The PW which a PW endpoint activates in preference to 283 any other PW when more than one PW qualifies for active 284 state. When the primary PW comes back up after a failure and 285 qualifies for active state, the PW endpoint always reverts 286 to it. The designation of Primary is performed by local 287 configuration for the PW at the PE and is only required when 288 revertive protection switching is used [8]. 290 Secondary PW: When it qualifies for active state, a secondary PW is 291 only selected if no primary PW is configured or if the 292 configured primary PW does not qualify for active state 293 (e.g., is down). By default, a PW in a redundancy PW set is 294 considered secondary. There is no revertive mechanism among 295 secondary PWs [8]. 297 PW Precedence: This is a configuration local to the PE that dictates 298 the order in which a forwarder chooses to use a PW when 299 multiple PWs all qualify for the active state. Note that a 300 PW which has been configured as Primary has implicitly the 301 lowest precedence value. 303 PW Endpoint: A PE where a PW terminates on a point where Native 304 Service Processing is performed, e.g., A SS-PW PE, an MS-PW 305 T-PE, or an H-VPLS MTU-s or PE-rs [8]. 307 Provider Edge (PE): A device that provides PWE3 to a CE [9]. 309 PW Terminating Provider Edge (T-PE): A PE where the customer- 310 facing attachment circuits (ACs) are bound to a PW 311 forwarder. A terminating PE is present in the first and 312 last segments of an MS-PW. This incorporates the 313 functionality of a PE as defined in RFC 3985 [6]. 315 PW Switching Provider Edge (S-PE): A PE capable of switching the 316 control and data planes of the preceding and succeeding PW 317 segments in an MS-PW. The S-PE terminates the PSN tunnels 318 of the preceding and succeeding segments of the MS-PW. It 319 therefore includes a PW switching point for an MS-PW. A PW 320 switching point is never the S-PE and the T-PE for the same 321 MS-PW. A PW switching point runs necessary protocols to set 322 up and manage PW segments with other PW switching points and 323 terminating PEs. An S-PE can exist anywhere a PW must be 324 processed or policy applied. It is therefore not 325 limited to the edge of a provider network [6]. 327 MTU-s: A hierarchical virtual private LAN service Multi-Tenant 328 Unit switch, as defined in RFC 4762 [3]. 330 PE-rs: A routing and bridging capable PE as defined in RFC 4762 [3]. 332 FEC: Forwarding Equivalence Class. 334 OAM: Operations, Administration, and Maintenance. 336 VCCV: Virtual Connection Connectivity Verification. 338 This document uses the term 'PE' to be synonymous with both PEs as 339 per RFC 3985 [9] and T-PEs as per RFC 5659 [6]. 341 This document uses the term 'PW' to be synonymous with both PWs as 342 per RFC 3985 [9] and SS-PWs, MS-PWs, and PW segments as per 343 RFC 5659 [6]. 345 4. PE Architecture 347 Figure 4-1 shows the PE architecture for PW redundancy, when more 348 than one PW in a redundant set is associated with a single AC. This 349 is based on the architecture in Figure 4b of RFC 3985 [9]. The 350 forwarder selects which of the redundant PWs to using the criteria 351 described in this document. 353 +----------------------------------------+ 354 | PE Device | 355 +----------------------------------------+ 356 Single | | Single | PW Instance 357 AC | + PW Instance X<===========> 358 | | | 359 | |----------------------| 360 <------>o | Single | PW Instance 361 | Forwarder + PW Instance X<===========> 362 | | | 363 | |----------------------| 364 | | Single | PW Instance 365 | + PW Instance X<===========> 366 | | | 367 +----------------------------------------+ 369 Figure 4-1 PE Architecture for PW redundancy 371 5. Modes of Operation 373 There are two modes of operation for the use of the PW Preferential 374 Forwarding status bits: 376 o Independent mode 378 o Master/Slave mode. 380 5.1. Independent Mode: 382 PW endpoint nodes independently select which PWs are eligible to 383 become active and which are not. They advertise the corresponding 384 Active or standby preferential forwarding status for each PW. Each 385 PW endpoint compares local and remote status bits and uses the PW 386 that is up at both endpoints and that advertised Active preferential 387 forwarding status at both the local and remote endpoints. 389 In this mode of operation, the preferential forwarding status 390 indicates the preferred forwarding state of each endpoint but the 391 actual forwarding state of the PW is the result of the comparison of 392 the local and remote forwarding status bits. 394 If more than one PW qualifies for the Active state, each PW endpoint 395 MUST implement a common mechanism to choose the PW for forwarding. 396 The default mechanism MUST be supported by all implementations and 397 operates as follows: 399 1. For a PW ID Forwarding Equivalence Class (PWid FEC) PW [2], the 400 PW with the lowest pw-id value is selected. 402 2. For a Generalized PWid FEC PW [2], each PW in a redundant set is 403 uniquely identified at each PE using the following triplet: 404 AGI::SAII::TAII. The unsigned integer form of the concatenated 405 word can be used in the comparison. However, the SAII and TAII 406 values as seen on a PE node are the mirror values of what the 407 peer PE node sees. So that both PE nodes compare the same value, 408 the PE with the lowest system IP address MUST use the unsigned 409 integer form of AGI::SAII::TAII while the PE with the highest 410 system IP address MUST use the unsigned integer form of 411 AGI::TAII::SAII. This way, both PE nodes will compare the same 412 values. The PW which corresponds to the minimum of the compared 413 values across all PWs in the redundant set is selected. 415 In the case where the system IP address is not known, it is 416 RECOMMENDED to implement the active PW selection mechanism 417 described next. 419 In the case of segmented PW, the operator needs to make sure that 420 the pw-id or AGI::SAII::TAII of the redundant PWs within the 421 first and last segment are ordered consistently such that the 422 same end-to-end MS-PW gets selected. Otherwise, it is RECOMMENDED 423 to implement the active PW selection mechanism described next. 425 The PW endpoints MAY also implement the following active PW 426 selection mechanism. 428 1. If the PW endpoint is configured with the precedence parameter on 429 each PW in the redundant set, it selects the PW with the lowest 430 configured precedence value. 432 2. If the PW endpoint is configured with one PW as primary and one 433 or more PWs as secondary, it selects the primary PW in preference 434 to all secondary PWs. If a primary PW is not available, it 435 selects the secondary PW with the lowest precedence value. If the 436 primary PW becomes available, a PW endpoint reverts to it 437 immediately or after the expiration of a configurable delay. 439 3. This active PW selection mechanism assumes the precedence 440 parameter values are configured consistently at both PW endpoints 441 and that unique values are assigned to the PWs in the same 442 redundant set to achieve tie-breaking using this mechanism. 444 There are scenarios with dual-homing of a CE to PE nodes where each 445 PE node needs to advertise Active preferential forwarding status on 446 more than one PW in the redundant set. However, a PE MUST always 447 select a single PW for forwarding using the above active PW 448 selection algorithm. An example of such a case is described in 15.2. 449 . 451 There are scenarios where each PE needs to advertize Active 452 preferential forwarding status on a single PW in the redundant set. 453 In order to ensure that both PE nodes make the same selection, they 454 MUST use the above active PW selection algorithm to determine the PW 455 eligible for active state. An example of such a case is described in 456 15.5. . 458 In steady state with consistent configuration, a PE will always find 459 an active PW. However, it is possible that such a PW is not found 460 due to a misconfiguration. In the event that an active PW is not 461 found, a management notification SHOULD be generated. If a 462 management notification for failure to find an active PW was 463 generated and an active PW is subsequently found, a management 464 notification SHOULD be generated, so clearing the previous failure 465 indication. Additionally, a PE MAY use the request switchover 466 procedures described in Section 6.3. 6.3 to have both PE nodes 467 switch to a common PW. 469 There may also be transient conditions where endpoints do not share 470 a common view of the Active/Standby state of the PWs. This could be 471 caused by propagation delay of the T-LDP status messages between 472 endpoints. In this case, the behavior of the receiving endpoint is 473 outside the scope of this document. 475 Thus, in this mode of operation, the following definition of Active 476 and Standby PW states apply: 478 o Active State 480 A PW is considered to be in Active state when the PW labels are 481 exchanged between its two endpoints and the status bits exchanged 482 between the endpoints indicate the PW is up and its preferential 483 forwarding status is Active at both endpoints. In this state user 484 traffic can flow over the PW in both directions. As described in 485 Section 5.1. 5.1 , the PE nodes MUST implement a common mechanism to 486 select one PW for forwarding in case multiple PWs qualify for the 487 Active state. 489 o Standby State 491 A PW is considered to be in Standby state when the PW labels are 492 exchanged between its two endpoints, but the Preferential Forwarding 493 status bits exchanged indicate the PW preferential forwarding status 494 is Standby at one or both endpoints. In this state the endpoints 495 MUST NOT forward data traffic over the PW but MAY allow PW OAM 496 packets, e.g., Virtual Connection Connectivity Verification (VCCV) 497 packets [12], to be sent and received in order to test the 498 liveliness of standby PWs. The endpoints of the PW MAY also allow 499 the forwarding of specific control plane packets of applications 500 using the PW. The specification of applications and the allowed 501 control plane packets is outside the scope of this document. If the 502 PW is a spoke in H-VPLS, any MAC addresses learned via the PW SHOULD 503 be flushed when it transitions to Standby state according to the 504 procedures in RFC 4762 [3] and in [11]. 506 5.2. Master/Slave Mode: 508 One endpoint node of the redundant set of PWs is designated the 509 Master and is responsible for selecting which PW both endpoints must 510 use to forward user traffic. 512 The Master indicates the forwarding state in the PW Preferential 513 Forwarding status bit. The other endpoint node, the Slave, MUST 514 follow the decision of the Master node based on the received status 515 bits. In other words, the Preferential Forwarding status bit sent by 516 the Master node indicates the actual forwarding state of the PW at 517 the Master node. 519 There is a single PE Master PW endpoint node and one or many PE PW 520 endpoint Slave nodes. The assignment of Master/Slave roles to the PW 521 endpoints is performed by local configuration. Note that the 522 behavior described in this section assumes correct configuration of 523 the Master and Slave endpoints. This document does not define a 524 mechanism to detect errors in the configuration, and 525 misconfiguration might lead to protection switchover failing to work 526 correctly. Furthermore, this document does not specify the 527 procedures for a backup Master node. In deployments where PE node 528 protection is required, it recommended to use the Independent Mode 529 of operation as in the application described in 15.2. 531 One endpoint of the PW, the Master, actively selects which PW to 532 activate and uses it for forwarding user traffic. This status is 533 indicated to the Slave node by setting the Preferential Forwarding 534 status bit in the status bit TLV to Active. It does not forward user 535 traffic to any other of the PW's in the redundant set to the slave 536 node and indicates this by setting the Preferential Forwarding 537 status bit in the status bit TLV to Standby for those PWs. The 538 master node MUST ignore any PW Preferential Forwarding status bits 539 received from the Slave nodes. 541 If more than one PW qualifies for the Active state, the Master PW 542 endpoint node selects one. There is no requirement to specify a 543 default active PW selection mechanism in this case but for 544 consistency across implementations, the Master PW endpoint SHOULD 545 implement the default active PW selection mechanism described in 546 Section 5.1. 548 If the Master PW endpoint implements the active PW selection 549 mechanism based on primary/secondary and precedence parameters, it 550 MUST follow the following behavior: 552 1. If the PW endpoint is configured with the precedence parameter on 553 each PW in the redundant set, it MUST select the PW with the 554 lowest configured precedence value. 556 2. If the PW endpoint is configured with one PW as primary and one 557 or more PWs as secondary, it MUST select the primary PW in 558 preference to all secondary PWs. If a primary PW is not 559 available, it MUST use the secondary PW with the lowest 560 precedence value. If the primary PW becomes available, a PW 561 endpoint MUST revert to it immediately or after the expiration of 562 a configurable delay. 564 The Slave endpoint(s) are required to act on the status bits 565 received from the Master. When the received status bit transitions 566 from Active to Standby, a Slave node MUST stop forwarding over the 567 previously active PW. When the received status bit transitions from 568 Standby to Active for a given PW, the Slave node MUST start 569 forwarding user traffic over this PW. 571 In this mode of operation, the following definition of Active and 572 Standby PW states apply: 574 o Active State 576 A PW is considered to be in Active state when the PW labels are 577 exchanged between its two endpoints, and the status bits exchanged 578 between the endpoints indicate the PW is up at both endpoints, and 579 the preferential forwarding status at the Master endpoint is Active. 580 In this state user traffic can flow over the PW in both directions. 582 o Standby State 584 A PW is considered to be in Standby state when the PW labels are 585 exchanged between its two endpoints, and the status bits exchanged 586 between the endpoints indicate the preferential forwarding status at 587 the Master endpoint is Standby. In this state the endpoints MUST NOT 588 forward data traffic over the PW but MAY allow PW OAM packets, e.g., 589 VCCV, to be sent and received. The endpoints of the PW MAY also 590 allow the forwarding of specific control plane packets of 591 applications using the PW. The specification of applications and the 592 allowed control plane packets is outside the scope of this document. 593 If the PW is a spoke in H-VPLS, any MAC addresses learned via the PW 594 SHOULD be flushed when it transitions to standby state according to 595 the procedures in RFC 4762 [3] and [11]. 597 6. PW State Transition Signaling Procedures 599 This section describes the extensions to PW status signaling and the 600 processing rules for these extensions. It defines a new "PW 601 Preferential Forwarding" bit Status Code that is to be used with the 602 PW Status TLV specified in RFC 4447 [2]. 604 The PW Preferential Forwarding bit, when set, is used to signal 605 either the Preferred or Actual Active/Standby forwarding state of 606 the PW by one PE to the far end PE. The actual semantics of the 607 value being signaled vary according to whether the PW is acting in a 608 Master/Slave or Independent mode. 610 6.1. PW Standby Notification Procedures in Independent mode 612 PEs that contain PW endpoints independently select which PW they 613 intend to use for forwarding, depending on the specific application 614 (example applications are described in [8]). They advertise the 615 corresponding preferred Active/Standby forwarding state for each PW. 616 An Active Preferential Forwarding state is indicated by clearing the 617 PW Preferential Forwarding status bit in the PW status TLV. A 618 Standby Preferential Forwarding State is indicated by setting the PW 619 Preferential Forwarding status bit in the PW status TLV. This 620 advertisement occurs in both the initial label mapping message and 621 in a subsequent notification message when the forwarding state 622 transitions as a result of a state change in the specific 623 application. 625 Each PW endpoint compares the updated local and remote status and 626 effectively activates the PW which is up at both endpoints and which 627 shows both local Active and remote Active Preferential Forwarding 628 states. The PE nodes MUST implement a common mechanism to select one 629 PW for forwarding in case multiple PWs qualify for the Active state 630 as explained in Section 5.1. 5.1 . 632 When a PW is in Active state, the PEs can forward user packets, OAM 633 packets, and other control plane packets over the PW. 635 When a PW is in Standby state, the PEs MUST NOT forward user packets 636 over the PW but MAY forward PW OAM packets and specific control 637 plane packets. 639 For MS-PWs, S-PEs MUST relay the PW status notification containing 640 both the existing status bits and the new Preferential Forwarding 641 status bits between ingress and egress PWs as per the procedures 642 defined in[4]. 644 6.2. PW Standby notification procedures in Master/Slave mode 646 Whenever the Master PW endpoint selects or deselects a PW for 647 forwarding user traffic at its end, it explicitly notifies the event 648 to the remote Slave endpoint. The slave endpoint carries out the 649 corresponding action on receiving the PW state change notification. 651 If the PW Preferential Forwarding bit in PW Status TLV received by 652 the slave is set, it indicates that the PW at the Master end is not 653 used for forwarding and is thus kept in the Standby state. The PW 654 MUST NOT be used for forwarding at Slave endpoint. Clearing the PW 655 Preferential Forwarding bit in PW Status TLV indicates that the PW 656 at the Master endpoint is used for forwarding and is in Active 657 state, and the receiving Slave endpoint MUST activate the PW if it 658 was previously not used for forwarding. 660 When this mechanism is used, a common Group ID in the PWid FEC 661 element or a PW Grouping TLV in the Generalized PWid FEC element as 662 defined in [2] MAY be used to signal PWs in groups in order to 663 minimize the number of LDP status messages that MUST be sent. When 664 PWs are provisioned with such grouping a termination point sends a 665 single "wildcard" Notification message to denote this change in 666 status for all affected PWs. This status message contains either the 667 PWid FEC TLV with only the Group ID, or else it contains the 668 Generalized PWid FEC TLV with only the PW Grouping ID TLV. As 669 mentioned in [2], the Group ID field of the PWid FEC element, or the 670 PW Grouping TLV in the Generalized PWid FEC element, can be used to 671 send status notification for an arbitrary set of PWs. 673 For MS-PWs, S-PEs MUST relay the PW status notification containing 674 both the existing and the new Preferential Forwarding status bits 675 between ingress and egress PW segments as per the procedures defined 676 in [4]. 678 6.2.1. PW State Machine 680 It is convenient to describe the PW state change behavior in terms 681 of a state machine (Table 1). The PW state machine is explained in 682 detail in the two defined states and the behavior is presented as a 683 state transition table. The same state machine is applicable to PW 684 Groups. 686 STATE EVENT NEW 687 STATE 689 ACTIVE PW put in Standby (master) STANDBY 690 Action: Transmit PW preferential 691 forwarding bit set 693 Receive PW Preferential Forwarding STANDBY 694 bit set (slave) 695 Action: Stop forwarding over PW 697 Receive PW Preferential Forwarding ACTIVE 698 bit set but bit not supported 699 Action: None 701 Receive PW Preferential Forwarding ACTIVE 702 bit clear 703 Action: None. 705 STANDBY PW activated (master) ACTIVE 706 Action: Transmit PW preferential 707 forwarding bit clear 709 Receive PW Preferential Forwarding ACTIVE 710 bit clear (slave) 711 Action: Activate PW 713 Receive PW Preferential Forwarding STANDBY 714 bit clear but bit not supported 715 Action: None 717 Receive PW Preferential Forwarding STANDBY 718 bit set 719 Action: None 721 Table 1 PW State Transition Table in Master/Slave Mode 723 6.3. Coordination of PW Switchover 725 There are PW redundancy applications which require that PE nodes 726 coordinate the switchover to a PW such that both endpoints will 727 forward over the same PW at any given time. One such application for 728 redundant MS-PW is identified in [8]. Multiple MS-PWs are configured 729 between a pair of T-PE nodes. The paths of these MS-PWs are diverse 730 and are switched at different S-PE nodes. Only one of these MS-PWs 731 is active at any given time. The others are put in standby. The 732 endpoints follow the Independent Mode procedures to use the PW which 733 is both up and for which both endpoints advertise an Active 734 Preferential Forwarding status bit. 736 The trigger for sending a request to switchover of the MS-PW by one 737 endpoint can be an operational event, for example a failure, which 738 causes the endpoints to be unable to find a common PW for which both 739 endpoints advertise an Active Preferential Forwarding status bit. 740 The other trigger is the execution of an administrative maintenance 741 operation by the network operator in order to move the traffic away 742 from the nodes or links currently used by the active PW. 744 Unlike the case of a Master/Slave mode of operation, the endpoint 745 requesting the switchover requires explicit acknowledgement from the 746 peer endpoint that the request can be honored before it switches to 747 another PW. Furthermore, any of the endpoints can make the request 748 to switchover. 750 This document specifies a second status bit that is used by a PE to 751 request that its peer PE switchover to use a different active PW. 752 This bit is referred to as the 'request switchover' status bit. The 753 Preferential Forwarding status bit continues to be used by each 754 endpoint to indicate its current local settings of the 755 Active/Standby state of each PW in the redundant set. In other 756 words, as in the Independent mode, it indicates to the far-end which 757 of the PWs is being used to forward packets and which is being put 758 in standby. It can thus be used as a way for the far-end to 759 acknowledge the requested switchover operation. 761 A PE MAY support the 'request switchover' bit. A PE which receives 762 the 'request switchover' bit and which does not support it will 763 ignore it. 765 If the 'request switchover' bit is supported by both sending and 766 receiving PEs, the following procedures MUST be followed by both 767 endpoints of a PW to coordinate the switchover of the PW. 769 S-PEs nodes MUST relay the PW status notification containing the 770 existing status bits, as well as the new Preferential Forwarding and 771 'request switchover' status bits between ingress and egress PW 772 segments as per the procedures defined in [4]. 774 6.3.1. Procedures at the requesting endpoint 776 a. The requesting endpoint sends a Status TLV in the LDP 777 notification message with the 'request switchover' bit set on the 778 PW it desires to switch to. 780 b. The endpoint does not activate forwarding on that PW at this 781 point in time. It MAY, however, enable receiving on that PW. Thus 782 the Preferential Forwarding status bit still reflects the 783 currently-used PW. 785 c. The requesting endpoint starts a timer while waiting the remote 786 endpoint to acknowledge the request. This timer SHOULD be 787 configurable with a default value of 3 seconds. 789 d. If while waiting for the acknowledgment, the requesting endpoint 790 receives a request from its peer to switchover to the same or a 791 different PW, it MUST perform the following: 793 i. If its address is higher than that of the peer, this 794 endpoint ignores the request and continues to wait for 795 the acknowledgement from its peer. 797 ii. If its system IP address is lower than that of its peer, 798 it aborts the timer and immediately starts the 799 procedures of the receiving endpoint in Section 6.3.2. 801 e. If while waiting for the acknowledgment, the requesting endpoint 802 receives a status notification message from its peer with the 803 'Preferential Forwarding' status bit cleared in the requested PW, 804 it MUST treat this as an explicit acknowledgment of the request 805 and MUST perform the following: 807 i. Abort the timer. 809 ii. Activate the PW. 811 iii. Send an update status notification message with the 812 'Preferential Forwarding' status bit and the 'request 813 switchover' bit clear on the newly active PW and send an 814 update status notification message with the 815 'Preferential Forwarding' status bit set in the 816 previously active PW. 818 f. If while waiting for the acknowledgment, the requesting endpoint 819 detects that the requested PW went into down state locally, and 820 could use an alternate PW which is up, it MUST perform the 821 following: 823 i. Abort the timer. 825 ii. Issue a new request to switchover to the alternate PW. 827 iii. Re-start the timer. 829 g. If, while waiting for the acknowledgment, the requesting endpoint 830 detects that the requested PW went into the down state locally, 831 and could not use an alternate PW which is up, it MUST perform 832 the following: 834 i. Abort the timer. 836 ii. Send an update status notification message with the 837 Preferential Forwarding status bit unchanged and the 838 'request switchover' bit reset for the requested PW. 840 h. If, while waiting for the acknowledgment, the timer expires, the 841 requesting endpoint MUST assume that the request was rejected and 842 MAY issue a new request. 844 i. If the requesting node receives the acknowledgment after the 845 request expired, it will treat it as if the remote endpoint 846 unilaterally switched between the PWs without issuing a request. 847 In that case, it MAY issue a new request and follow the 848 requesting endpoint procedures to synchronize which PW to use for 849 the transmit and receive directions of the emulated service. 851 6.3.2. Procedures at the receiving endpoint 853 a. Upon receiving a status notification message with the 'request 854 switchover' bit set on a PW different from the currently active 855 one, and the requested PW is up, the receiving endpoint MUST 856 perform the following: 858 i. Activate the PW. 860 ii. Send an update status notification message with the 861 'Preferential Forwarding' status bit clear and the 862 'request switchover' bit reset on the newly active PW , 863 and send an update status notification message with the 864 Preferential Forwarding status bit set in the previously 865 active PW. 867 iii. Upon receiving a status notification message with the 868 'request switchover' bit set on a PW different from the 869 currently active one, and the requested PW is down, the 870 receiving endpoint MUST ignore the request. 872 7. Status Mapping 874 The generation and processing of the PW Status TLV MUST follow the 875 procedures in RFC 4447 [2]. The PW status TLV is sent on the active 876 PW and standby PWs to make sure the remote AC and PW states are 877 always known to the local PE node. 879 The generation and processing of PW Status TLV by an S-PE node in a 880 MS-PW MUST follow the procedures in [4]. 882 The procedures for determining and mapping PW and AC states MUST 883 follow the rules in [5] with the following modifications. 885 7.1. AC Defect State Entry/Exit 887 A PE enters the AC receive (or transmit) defect state for a PW 888 service when one or more of the conditions specified for this PW 889 service in [5] are met. 891 When a PE enters the AC receive (or transmit) defect state for a PW, 892 it MUST send a forward (reverse) defect indication to the remote 893 peers over all PWs in the redundant set which are associated with 894 this AC. 896 When a PE exits the AC receive (or transmit) defect state for a PW 897 service, it MUST clear the forward (or reverse) defect indication to 898 the remote peers over all PWs in the redundant set which are 899 associated with this AC. 901 7.2. PW Defect State Entry/Exit 903 A PE enters the PW receive (or transmit) defect state for a PW 904 service when one or more of the conditions specified in Section 905 8.2.1 (Section 8.2.2) in [5] are met for each of the PWs in the 906 redundant set. 908 When a PE enters the PW receive (or transmit) defect state for a PW 909 service associated with an AC, it MUST send a reverse (or forward) 910 defect indication over one or more of the PWs in the redundant set 911 associated with the same AC if the PW failure was detected by this 912 PE without receiving a forward defect indication from the remote 913 PE [5]. 915 When a PE exits the PW receive (or transmit) defect state for a PW, 916 it MUST clear the reverse (or forward) defect indication over any PW 917 in the redundant associated with the same AC set if applicable. 919 8. Applicability and Backward Compatibility 921 The mechanisms defined in this document are to be used in 922 applications where standby state signaling of a PW or PW group is 923 required. Both PWid FEC and Generalized PWid FEC are supported. All 924 PWs which are part of a redundant set MUST use the same FEC type. 925 When the set uses PWid FEC element, each PW is uniquely identified 926 by its PW ID. When the redundant set uses Generalized PWid FEC 927 element, each PW MUST have a unique identifier which consists of the 928 triplet AGI::SAII::TAII. 930 A PE implementation that uses the mechanisms described in this 931 document MUST negotiate the use of PW status TLV between its T-LDP 932 peers as per RFC 4447 [2]. If PW Status TLV is found to be not 933 supported by either of its endpoint after status negotiation 934 procedures, then the mechanisms specified in this document cannot be 935 used. 937 A PE implementation compliant to RFC 4447 [2], and which does not 938 support the generation or processing of the Preferential Forwarding 939 status bit or of the 'request switchover' status bit, MUST ignore 940 these status bits if they are set by a peer PE. This document in 941 fact updates RFC 4447 by prescribing the same behavior for any 942 status bit not originally defined in RFC 4447. 944 Finally this document updates RFC 4447 by defining that status bit 945 can indicate a status other than a fault or can indicate an 946 instruction to the peer PE. As a result, a PE implementation 947 compliant to RFC 4447 MUST process each status bit it supports when 948 set according to the rules specific to that status bit. 950 9. Security Considerations 952 LDP extensions/options that protect pseudowires must be 953 implemented because the status bits defined in this document have 954 the same security considerations as the pseudowire setup and 955 maintenance protocol defined in RFC4447 [2]. It should be noted that 956 the security of a PW redundant set is only as good as the weakest 957 security on any of its members. 959 10. MIB Considerations 961 New MIB objects for the support of PW redundancy will be defined in 962 a separate document. 964 11. IANA Considerations 966 This document defines the following PW status codes for the PW 967 redundancy application. IANA is requested to allocate these from the 968 PW Status Codes registry. 970 11.1. Status Code for PW Preferential Forwarding Status 972 0x00000020 When the bit is set, it indicates "PW forwarding 974 standby". 976 When the bit is cleared, it indicates "PW forwarding 978 active". 980 11.2. Status Code for PW Request Switchover Status 982 0x00000040 When the bit is set, it represents "Request switchover" 984 to this PW. 986 When the bit is cleared, it represents no specific 987 action. 989 12. Contributors 991 The editors would like to thank Matthew Bocci, Pranjal Kumar Dutta, 992 Giles Heron, Marc Lasserre, Luca Martini, Thomas Nadeau, Jonathan 993 Newton, Hamid Ould-Brahim, Olen Stokes, and Daniel Cohn who made a 994 contribution to the development of this document. 996 Matthew Bocci 997 Alcatel-Lucent 998 Email: matthew.bocci@alcatel-lucent.com 999 Pranjal Kumar Dutta 1000 Alcatel-Lucent 1001 Email: pranjal.dutta@alcatel-lucent.com 1003 Giles Heron 1004 Cisco Systems, Inc. 1005 giles.heron@gmail.com 1007 Marc Lasserre 1008 Alcatel-Lucent 1009 Email: marc.lasserre@alcatel-lucent.com 1011 Luca Martini 1012 Cisco Systems, Inc. 1013 Email: lmartini@cisco.com 1015 Thomas Nadeau 1016 Juniper Networks 1017 Email: tnadeau@lucidvision.com 1019 Jonathan Newton 1020 Cable & Wireless Worldwide 1021 Email: Jonathan.Newton@cw.com 1023 Hamid Ould-Brahim 1024 Email: ouldh@yahoo.com 1026 Olen Stokes 1027 Extreme Networks 1028 Email: ostokes@extremenetworks.com 1030 Daniel Cohn 1031 Orckit 1032 daniel.cohn.ietf@gmail.com. 1034 13. Acknowledgments 1036 The authors would like to thank the following individuals for their 1037 valuable comments and suggestions which improved the document both 1038 technically and editorially: 1040 Vach Kompella, Kendall Harvey, Tiberiu Grigoriu, John Rigby, 1041 Prashanth Ishwar, Neil Hart, Kajal Saha, Florin Balus, Philippe 1042 Niger, Dave McDysan, Roman Krzanowski, Italo Busi, Robert Rennison, 1043 and Nicolai Leymann. 1045 14. References 1047 14.1. Normative References 1049 [1] Bradner, S., "Key words for use in RFCs to Indicate 1050 Requirement Levels", BCP 14, RFC 2119, March 1997. 1052 [2] Martini, L., et al., "Pseudowire Setup and Maintenance using 1053 LDP", RFC 4447, April 2006. 1055 [3] Kompella,V., Lasserrre, M. , et al., "Virtual Private LAN 1056 Service (VPLS) Using LDP Signalling", RFC 4762, January 2007. 1058 [4] Martini, L., et al., "Segmented Pseudowire", RFC 6073, January 1059 2011. 1061 [5] Aissaoui, M., et al., "Pseudowire (PW) OAM Message Mapping", 1062 RFC 6310, July 2011. 1064 14.2. Informative References 1066 [6] Bocci, M., Bryant, S., et al., "An Architecture for Multi- 1067 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 1068 2009. 1070 [7] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1071 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 1073 [8] Muley, P., et al., "Pseudowire (PW) Redundancy", RFC 6718, 1074 August 2012. 1076 [9] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge (PWE3) 1077 Architecture", RFC 3985, March 2005 1079 [10] Nadeau, T., Zelig, D., Nicklass, O., "Definitions of Textual 1080 Conventions for Pseudowire (PW) Management", RFC 5542, May 1081 2009 1083 [11] Dutta, P., Lasserre, M., Stokes, O., "LDP Extensions for 1084 Optimized MAC Address Withdrawal in H-VPLS", draft-ietf-l2vpn- 1085 vpls-ldp-mac-opt-05.txt, October 2011 1087 [12] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 1088 Connectivity Verification (VCCV): A Control Channel for 1089 Pseudowires", RFC 5085, December 2007. 1091 15. Appendix A - Applications of PW Redundancy Procedures 1093 This section shows how the mechanisms described in this document are 1094 used to achieve the desired protection behavior for some of the 1095 applications described in the PW Redundancy [8]. 1097 15.1. One Multi-homed CE with single SS-PW redundancy 1099 The following figure illustrates an application of single segment 1100 pseudowire redundancy. 1102 |<-------------- Emulated Service ---------------->| 1103 | | 1104 | |<------- Pseudowire ------>| | 1105 | | | | 1106 | | |<-- PSN Tunnels-->| | | 1107 | V V V V | 1108 V AC +----+ +----+ AC V 1109 +-----+ | | PE1|==================| | | +-----+ 1110 | |----------|....|...PW1.(active)...|....|----------| | 1111 | | | |==================| | | CE2 | 1112 | CE1 | +----+ |PE2 | | | 1113 | | +----+ | | +-----+ 1114 | | | |==================| | 1115 | |----------|....|...PW2.(standby)..| | 1116 +-----+ | | PE3|==================| | 1117 AC +----+ +----+ 1119 Figure 15-1 Multi-homed CE with single SS-PW redundancy 1121 The application in Figure 15-1 makes use of the Independent mode of 1122 operation. 1124 CE1 is dual homed to PE1 and to PE3 by attachment circuits. The 1125 method for dual-homing of CE1 to PE1 and to PE3 nodes and the 1126 protocols used are outside the scope of this document (see [8]). 1128 In this example, the AC from CE1 to PE1 is active, while the AC from 1129 CE1 to PE3 is standby, as determined by the redundancy protocol 1130 running on the ACs. Thus, in normal operation, PE1 and PE3 will 1131 advertise Active and Standby Preferential Forwarding status bit 1132 respectively to PE2, reflecting the forwarding state of the two ACs 1133 to CE1 as determined by the AC dual-homing protocol. PE2 advertises 1134 Preferential Forwarding status bit of Active on both PW1 and PW2 1135 since the AC to CE2 is single homed. As both the local and remote 1136 UP/DOWN status and preferential forwarding status for PW1 are up and 1137 Active, traffic is forwarded over PW1 in both directions. 1139 On failure of the AC between CE1 and PE1, the forwarding state of 1140 the AC on PE3 transitions to Active. PE3 then announces the newly 1141 changed Preferential Forwarding status bit of Active to PE2. PE1 1142 will advertise a PW status notification message indicating that the 1143 AC between CE1 and PE1 is down. PE2 matches the local and remote 1144 preferential forwarding status of Active and status of "Pseudowire 1145 forwarding" and select PW2 as the new active pseudowire to send 1146 traffic to. 1148 On failure of PE1 node, PE3 will detect it and will transition the 1149 forwarding state of its AC to Active. The method by which PE3 1150 detects that PE1 is down is outside the scope of this document. PE3 1151 then announces the newly changed Preferential Forwarding status bit 1152 of Active to PE2. PE3 and PE2 match the local and remote 1153 preferential forwarding status of Active and UP/DOWN status 1154 "Pseudowire forwarding" and select PW2 as the new active pseudowire 1155 to send traffic to. Note that PE2 may have detected that the PW to 1156 PE1 went down via T-LDP Hello timeout or via other means. However, 1157 it will not be able to forward user traffic until it receives the 1158 updated status bit from PE3. 1160 Note in this example, the receipt of the AC status on the CE1-PE1 1161 link is normally sufficient for PE2 to switch to PW2. However, the 1162 operator may want to trigger the switchover of the PW for 1163 administrative reasons, e.g., maintenance, and thus the use of the 1164 Preferential Forwarding status bit is required to notify PE2 to 1165 trigger the switchover. 1167 Note that the primary/secondary procedures do not apply in this case 1168 as the PW Preferential Forwarding status is driven by the AC 1169 forwarding state as determined by the AC dual-homing protocol used. 1171 15.2. Multiple Multi-homed CEs with single SS-PW redundancy 1173 |<-------------- Emulated Service ---------------->| 1174 | | 1175 | |<------- Pseudowire ------>| | 1176 | | | | 1177 | | |<-- PSN Tunnels-->| | | 1178 | V V (not shown) V V | 1179 V AC +----+ +----+ AC V 1180 +-----+ | |....|.......PW1........|....| | +-----+ 1181 | |----------| PE1|...... .........| PE3|----------| | 1182 | CE1 | +----+ \ / PW3 +----+ | CE2 | 1183 | | +----+ X +----+ | | 1184 | | | |....../ \..PW4....| | | | 1185 | |----------| PE2| | PE4|--------- | | 1186 +-----+ | |....|.....PW2..........|....| | +-----+ 1187 AC +----+ +----+ AC 1189 Figure 15-2 Multiple Multi-homed CEs with single SS-PW redundancy 1191 The application in Figure 15-2 makes use of the Independent mode of 1192 operation. 1194 CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed PE3 and PE4. The 1195 method for dual-homing and the used protocols are outside the scope 1196 of this document. Note that the PSN tunnels are not shown in this 1197 figure for clarity. However, it can be assumed that each of the PWs 1198 shown is encapsulated in a separate PSN tunnel. 1200 Assume that the AC from CE1 to PE1 is Active, from CE1 to PE2 is 1201 Standby; furthermore, assume that the AC from CE2 to PE3 is Standby 1202 and from CE2 to PE4 is Active. The method of deriving Active/Standby 1203 status of the AC is outside the scope of this document. 1205 PE1 advertises the preferential status Active and UP/DOWN status 1206 "Pseudowire forwarding" for pseudowires PW1 and PW4 connected to PE3 1207 and PE4. This status reflects the forwarding state of the AC 1208 attached to PE1. PE2 advertises preferential status Standby and 1209 UP/DOWN status "Pseudowire forwarding" for pseudowires PW2 and PW3 1210 to PE3 and PE4. PE3 advertises preferential status Standby and 1211 UP/DOWN status "Pseudowire forwarding" for pseudowires PW1 and PW3 1212 to PE1 and PE2. PE4 advertise the preferential status Active and 1213 UP/DOWN status "Pseudowire forwarding" for pseudowires PW2 and PW4 1214 to PE2 and PE1 respectively. Thus by matching the local and remote 1215 preferential forwarding status of Active and UP/DOWN status of 1216 "Pseudowire forwarding" of pseudowires, the PE nodes determine which 1217 PW should be in the Active state. In this case it is PW4 that will 1218 be selected. 1220 On failure of the AC between CE1 and PE1, the forwarding state of 1221 the AC on PE2 is changed to Active. PE2 then announces the newly 1222 changed Preferential Forwarding status bit of Active to PE3 and PE4. 1223 PE1 will advertise a PW status notification message indicating that 1224 the AC between CE1 and PE1 is down. PE2 and PE4 match the local and 1225 remote preferential forwarding status of Active and UP/DOWN status 1226 "Pseudowire forwarding" and select PW2 as the new active pseudowire 1227 to send traffic to. 1229 On failure of PE1 node, PE2 will detect it and will transition the 1230 forwarding state of its AC to Active. The method by which PE2 1231 detects that PE1 is down is outside the scope of this document. PE2 1232 then announces the newly changed Preferential Forwarding status bit 1233 of Active to PE3 and PE4. PE2 and PE4 match the local and remote 1234 preferential forwarding status of Active and UP/DOWN status 1235 "Pseudowire forwarding" and select PW2 as the new active pseudowire 1236 to send traffic to. Note that PE3 and PE4 may have detected that the 1237 PW to PE1 went down via T-LDP Hello timeout or via other means. 1238 However, they will not be able to forward user traffic until they 1239 received the updated status bit from PE2. 1241 Because each dual-homing algorithm running on the two node sets, 1242 i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects the active AC 1243 independently, there is a need to signal the active status of the AC 1244 such that the PE nodes can select a common active PW for end-to-end 1245 forwarding between CE1 and CE2 as per the procedures in the 1246 independent mode. 1248 Note that any primary/secondary procedures, as defined in sections 1249 5.1. 5.1 and 5.2. 5.2 , do not apply in this use case as the 1250 Active/Standby status is driven by the AC forwarding state as 1251 determined by the AC dual-homing protocol used. 1253 15.3. Multi-homed CE with MS-PW redundancy 1255 The following figure illustrates an application of multi-segment 1256 pseudowire redundancy. 1258 Native |<-----------Pseudowire ------------->| Native 1259 Service | | Service 1260 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 1261 | V V V V V V | 1262 | +-----+ +-----+ +-----+ | 1263 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 1264 | |-------|......PW1-Seg1.......|PW1-Seg2.......|-------| | 1265 | | | |=========| |=========| | | | 1266 | CE1| +-----+ +-----+ +-----+ | | 1267 | | |.| +-----+ +-----+ | CE2| 1268 | | |.|===========| |=========| | | | 1269 | | |.....PW2-Seg1......|.PW2-Seg2......|-------| | 1270 +----+ |=============|S-PE2|=========|T-PE4| | +----+ 1271 +-----+ +-----+ AC 1273 Figure 15-3 Multi-homed CE with MS-PW redundancy 1275 The application in Figure 15-3 makes use of the Independent mode of 1276 operation. It extends the application described in Section 15.1. 1277 15.1 of this document and in [8] by adding a pair of S-PE nodes to 1278 switch the segments of PW1 and PW2. 1280 CE2 is dual-homed to T-PE2 and T-PE4. PW1 and PW2 are used to extend 1281 the resilient connectivity all the way to T-PE1. PW1 has two 1282 segments and is active pseudowire while PW2 has two segments and is 1283 a standby pseudowire. This application requires support for MS-PW 1284 with segments of the same type as described in [4]. 1286 The operation in this case is the same as in the case of SS-PW as 1287 described in Section 15.1. 15.1 . The only difference is that the S- 1288 PE nodes need to relay the PW status notification containing both 1289 the UP/DOWN and forwarding status to the T-PE nodes. 1291 15.4. Multi-homed CE with MS-PW redundancy and S-PE protection 1293 The following figure illustrates an application of multi-segment 1294 pseudowire redundancy with 1:1 PW protection. 1296 Native |<-----------Pseudowire ------------->| Native 1297 Service | | Service 1298 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 1299 | V V V V V V | 1300 | +-----+ | 1301 | |=============| |=============| | 1302 | |.....PW3-Seg1......|.PW3-Seg2....| | 1303 | |.|===========|S-PE3|===========|.| | 1304 | |.| +-----+ |.| | 1305 | +-----+ +-----+ +-----+ | 1306 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 1307 | |-------|......PW1-Seg1.......|PW1-Seg2.......|-------| | 1308 | | | |=========| |=========| | | | 1309 | CE1| +-----+ +-----+ +-----+ | | 1310 | | |.| |.| +-----+ +-----+ | CE2| 1311 | | |.| |.|=========| |=========| | | | 1312 | | |.| |...PW2-Seg1......|.PW2-Seg2......|-------| | 1313 +----+ |.| |===========|S-PE2|=========|T-PE4| | +----+ 1314 |.| +-----+ +-----+ AC 1315 |.| +-----+ |.| 1316 |.|=============| |===========|.| 1317 |.......PW4-Seg1......|.PW4-Seg2....| 1318 |===============|S-PE4|=============| 1319 +-----+ 1321 Figure 15-4 Multi-homed CE with MS-PW redundancy and protection 1323 The application in Figure 15-4 makes use of the Independent mode 1324 of operation. 1326 CE2 is dual-homed to T-PE2 and T-PE4. The PW pairs {PW1,PW3} and 1327 {PW2, PW4} are used to extend the resilient connectivity all the 1328 way to T-PE1, like in the case in Section 15.3. 15.3 , with the 1329 addition that this setup provides for S-PE node protection. 1331 CE1 is connected to T-PE1 while CE2 is dual-homed to T-PE2 and 1332 T-PE4. There are four segmented PWs. PW1 and PW2 are primary PWs 1333 and are used to support CE2 multi-homing. PW3 and PW4 are 1334 secondary PWs and are used to support 1:1 PW protection. PW1, 1335 PW2, PW3 and PW4 have two segments and they are switched at S- 1336 PE1, S-PE2, S-PE3 and S-PE4 respectively. 1338 It is possible that S-PE1 coincides with S-PE4 and/or SP-2 1339 coincides with S-PE3, in particular where the two PSN domains 1340 are interconnected via two nodes. However Figure 15-4 shows four 1341 separate S-PE nodes for clarity. 1343 The behavior of this setup is exactly the same as in the setup 1344 in Section 15.3. 15.3 except that T-PE1 will always see a pair 1345 of PWs eligible for the active state, for example the pair 1346 {PW1,PW3} when the AC between CE2 and T-PE2 is in active state. 1347 Thus, it is important that both T-PE1 and T-PE2 implement a 1348 common mechanism to choose one the two PWs for forwarding as 1349 explained in Section 5.1. Similarly, T-PE1 and T-PE4 must use 1350 the same mechanism to select among the pair {PW2, PW4} when the 1351 AC between CE2 and T-PE4 is in active state. 1353 15.5. Single Homed CE with MS-PW redundancy 1355 The following is an application of the independent mode of operation 1356 along with the request switchover procedures in order to provide N:1 1357 PW protection. A revertive behavior to a primary PW is shown as an 1358 example of configuring and using the primary/secondary procedures 1359 described in sections 5.1. 5.1 and 5.2. 5.2 . 1361 Native |<------------Pseudowire ------------>| Native 1362 Service | | Service 1363 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 1364 | V V V V V V | 1365 | +-----+ +-----+ +-----+ | 1366 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 1367 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 1368 | CE1| | |=========| |=========| | | CE2| 1369 | | +-----+ +-----+ +-----+ | | 1370 +----+ |.||.| |.||.| +----+ 1371 |.||.| +-----+ |.||.| 1372 |.||.|=========| |========== .||.| 1373 |.||...PW2-Seg1......|.PW2-Seg2...||.| 1374 |.| ===========|S-PE2|============ |.| 1375 |.| +-----+ |.| 1376 |.|============+-----+============= .| 1377 |.....PW3-Seg1.| | PW3-Seg2......| 1378 ==============|S-PE3|=============== 1379 | | 1380 +-----+ 1382 Figure 15-5 Single homed CE with multi-segment pseudowire redundancy 1384 CE1 is connected to PE1 in provider Edge 1 and CE2 to PE2 in 1385 provider edge 2 respectively. There are three segmented PWs. A 1386 primary PW, PW1, is switched at S-PE1. A primary PW, PW1 has the 1387 lowest precedence value of zero. A secondary PW, PW2, which is 1388 switched at S-PE2 and has a precedence of 1. Finally, another 1389 secondary PW, PW3, is switched at S-PE3 and has a precedence of 2. 1391 The precedence is locally configured at the endpoints of the PW, 1392 i.e., T-PE1 and T-PE2. Lower the precedence value, higher the 1393 priority. 1395 T-PE1 and T-PE2 will select the PW they intend to activate based on 1396 their local and remote UP/DOWN state as well as the local precedence 1397 configuration. In this case, they will both advertise Preferential 1398 Forwarding' status bit of Active on PW1 and of Standby on PW2 and 1399 PW3 using priority derived from local precedence configuration. 1400 Assuming all PWs are up, T-PE1 and T-PE2 will use PW1 to forward 1401 user packets. 1403 If PW1 fails, then the T-PE detecting the failure will send a status 1404 notification to the remote T-PE with a "Local PSN-facing PW 1405 (ingress) Receive Fault" bit set, or a "Local PSN-facing PW (egress) 1406 Transmit Fault" bit set, or a "Pseudowire Not Forwarding" bit set. 1407 In addition, it will set the Preferential Forwarding status bit on 1408 PW1 to Standby. It will also advertise the Preferential Forwarding 1409 status bit on PW2 as Active as it has the next lowest precedence 1410 value. T-PE2 will also perform the same steps as soon as it is 1411 informed of the failure of PW1. Both T-PE nodes will perform a match 1412 on the 'preferential forwarding' status of Active and UP/DOWN status 1413 of "Pseudowire forwarding" and will use PW2 to forward user packets. 1415 However this does not guarantee that the T-PEs will choose the same 1416 PW from the redundant set to forward on, for a given emulated 1417 service, at all times. This may be due to a mismatch of the 1418 configuration of the PW precedence in each T-PE. This may also be 1419 due to a failure which caused the endpoints to not be able to match 1420 the Active Preferential Forwarding status bit and UP/DOWN status 1421 bits. In this case, T-PE1 and/or T-PE2 can invoke the request 1422 switchover/acknowledgement procedures to synchronize the choice of 1423 PW to forward on in both directions. 1425 The trigger for sending a request to switchover can also be the 1426 execution of an administrative maintenance operation by the network 1427 operator in order to move the traffic away from the T-PE/S-PE nodes 1428 /links to be serviced. 1430 In case the 'request switchover' is sent by both endpoints 1431 simultaneously, both T-PEs send status notification with the newly 1432 selected PW with 'request switchover' bit set, waiting for response 1433 from the other endpoint. In such situation, the T-PE with greater 1434 system address request is given precedence. This helps in 1435 synchronizing PWs in event of mismatch of precedence configuration 1436 as well. 1438 On recovery of primary PW1, PW1 is selected to forward traffic and 1439 the secondary PW, PW2, is set to standby. 1441 15.6. PW redundancy between H-VPLS MTU-s and PE-rs 1443 Following figure illustrates the application of use of PW redundancy 1444 in H-VPLS for the purpose of dual-homing an MTU-s node to PE nodes 1445 using PW spokes. This application makes use of the Master/Slave mode 1446 of operation. 1448 PE1-rs 1449 +--------+ 1450 | VSI | 1451 Active PW | -- | 1452 Group..........|../ \..|. 1453 CE-1 . | \ / | . 1454 \ . | -- | . 1455 \ . +--------+ . 1456 \ MTU-s . . . PE3-rs 1457 +--------+ . . . +--------+ 1458 | VSI | . . H-VPlS .| VSI | 1459 | -- ..|.. . Core |.. -- | 1460 | / \ | . PWs | / \ | 1461 | \ /..|.. . | \ / | 1462 | -- | . . .|.. -- | 1463 +--------+ . . . +--------+ 1464 / . . . 1465 / . +--------+ . 1466 / . | VSI | . 1467 CE-2 . | -- | . 1468 ..........|../ \..|. 1469 Standby PW | \ / | 1470 Group | -- | 1471 +--------+ 1472 PE2-rs 1474 Figure 15-6 Multi-homed MTU-s in H-VPLS core 1476 MTU-s is dual homed to PE1-rs and PE2-rs. The primary spoke PWs from 1477 MTU-s are connected to PE1-rs while the secondary PWs are connected 1478 to PE2. PE1-rs and PE2-rs are connected to H-VPLS core on the other 1479 side of network. MTU-s communicates to PE1-rs and PE2-rs the 1480 forwarding status of its member PWs for a set of VSIs having common 1481 status Active/Standby. It may be signaled using PW grouping with 1482 common group-id in PWid FEC element or Grouping TLV in Generalized 1483 PWid FEC element as defined in [2] to scale better. MTU-s derives 1484 the status of the PWs based on local policy configuration. In this 1485 example, the primary/secondary procedures as defined in Section 5.2. 1486 5.2 are used but this can be based on any other policy. 1488 Whenever MTU-s performs a switchover, it sends a wildcard 1489 Notification Message to PE2-rs for the previously standby PW group 1490 containing PW Status TLV with PW Preferential Forwarding bit 1491 cleared. On receiving the notification PE-2rs unblocks all member 1492 PWs identified by the PW group and state of PW group changes from 1493 Standby to Active. All procedures described in Section 6.2. 6.2 are 1494 applicable. 1496 The use of the Preferential Forwarding status bit in Master/Slave 1497 mode is similar to Topology Change Notification in RSTP controlled 1498 IEEE Ethernet Bridges but is restricted over a single hop. When 1499 these procedures are implemented, PE-rs devices are aware of 1500 switchovers at MTU-s and could generate MAC Withdraw Messages to 1501 trigger MAC flushing within the H-VPLS full mesh. By default, MTU-s 1502 devices should still trigger MAC Withdraw messages as currently 1503 defined in [3] to prevent two copies of MAC withdraws to be sent, 1504 one by MTU-s and another one by PE-rs nodes. Mechanisms to disable 1505 MAC Withdraw trigger in certain devices is out of the scope of this 1506 document 1508 Authors' Addresses 1510 Praveen Muley 1511 Alcatel-lucent 1512 701 E. Middlefield Road 1513 Mountain View, CA, USA 1514 Email: praveen.muley@alcatel-lucent.com 1516 Mustapha Aissaoui 1517 Alcatel-lucent 1518 600 March Rd 1519 Kanata, ON, Canada K2K 2E6 1520 Email: mustapha.aissaoui@alcatel-lucent.com