idnits 2.17.1 draft-ietf-pwe3-redundancy-bit-06.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 8 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (February 27, 2012) is 4442 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4447 (ref. '2') (Obsoleted by RFC 8077) == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-06 == Outdated reference: A later version (-13) exists of draft-ietf-l2vpn-vpls-ldp-mac-opt-05 Summary: 2 errors (**), 0 flaws (~~), 3 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 Intended Status: Standards Track Alcatel-Lucent 4 Expires: August 27, 2012 6 February 27, 2012 8 Pseudowire Preferential Forwarding Status Bit 9 draft-ietf-pwe3-redundancy-bit-06.txt 11 Abstract 13 This document describes a mechanism for standby status signaling of 14 redundant pseudowires (PWs) between their termination points. A set 15 of redundant PWs is configured between provider edge (PE) nodes in 16 single-segment pseudowire (SS-PW) applications, or between 17 terminating provider edge (T-PE) nodes in multi-segment pseudowire 18 (MS-PW) applications. 20 In order for the PE/T-PE nodes to indicate the preferred PW to use 21 for forwarding PW packets to one another, a new status bit is needed 22 to indicate a preferential forwarding status of Active or Standby for 23 each PW in a redundant set. 25 In addition, a second status bit is defined to allow peer PE nodes to 26 coordinate a switchover operation of the PW. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 27, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC-2119 [1]. 66 Table of Contents 68 1. Introduction...................................................3 69 2. Motivation and Scope...........................................5 70 3. Terminology....................................................7 71 4. PE Architecture................................................8 72 5. Modes of Operation.............................................9 73 5.1. Independent Mode:.........................................9 74 5.2. Master/Slave Mode:.......................................11 75 6. PW State Transition Signaling Procedures......................13 76 6.1. PW Standby Notification Procedures in Independent mode...13 77 6.2. PW Standby notification procedures in Master/Slave mode..14 78 6.2.1. PW State Machine....................................15 79 6.3. Coordination of PW Switchover............................16 80 6.3.1. Procedures at the requesting endpoint...............18 81 6.3.2. Procedures at the receiving endpoint................19 82 7. Status Mapping................................................20 83 7.1. AC Defect State Entry/Exit...............................20 84 7.2. PW Defect State Entry/Exit...............................20 86 8. Applicability and Backward Compatibility......................21 87 9. Security Considerations.......................................21 88 10. MIB Considerations...........................................21 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............23 92 12. Major Contributing Authors...................................23 93 13. Acknowledgments..............................................24 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....................29 101 15.4. Multi-homed CE with MS-PW redundancy and S-PE protection30 102 15.5. Single Homed CE with MS-PW redundancy...................32 103 15.6. PW redundancy between H-VPLS MTU-s and PE-rs............33 104 Author's Addresses...............................................35 106 1. Introduction 108 In Virtual Private Wire Services (VPWS) or Virtual Private Local Area 109 network Services (VPLS) that use SS-PWs, protection for the PW is 110 provided by the packet switched network (PSN) layer. This may be a 111 Resource Reservation Protocol with Traffic Engineering (RSVP-TE) 112 label switched path (LSP) with a fast reroute (FRR) backup or an end- 113 to-end backup LSP. There are, however, applications where PSN 114 protection is insufficient to fully protect the PW-based service. 115 These include the following: 117 In a VPWS service where the Customer Edge (CE) node is dual homed to 118 a pair of PE nodes, PW redundancy mechanisms are required to ensure 119 that the correct PW is used for forwarding when attachment circuit 120 (AC) redundancy is used. PW redundancy mechanisms are also required 121 when multiple redundant MS-PWs are used between T-PEs, to ensure that 122 both T-PEs use the same MS-PW to forward to one another. 124 In a hierarchical VPLS (H-VPLS) service, PW redundancy mechanisms are 125 required to enable a multi-tenant unit switch (MTU-s) to be dual- 126 homed to two PE-rs devices. 128 In these cases, pseudowire redundancy mechanisms are required. These 129 scenarios are described in the PW redundancy and framework document 130 [5]. 132 Scenarios, such as those above, therefore rely on a set of two or 133 more pseudowires to protect a given VPWS or VPLS . Only one of these 134 pseudowires is used by the PEs to forward user traffic on at any 135 given time. This is the active PW. The other PWs in the set are 136 considered standby and are not used for forwarding unless they become 137 active. This provides a 1:1 or N:1 PW protection with the possibility 138 of multi-homing between the CE and the PEs. 140 In order to support AC or spoke PW redundancy, at least one of the 141 PEs on which a PW terminates must be different from that on which the 142 primary PW terminates, as described in [5]. Figure 1-1 illustrates an 143 application of active and standby PWs. 145 |<-------------- Emulated Service ---------------->| 146 | | 147 | |<------- Pseudowire ------->| | 148 | | | | 149 | | |<-- PSN Tunnels-->| | | 150 | V V V V | 151 V AC +----+ +----+ AC V 152 +-----+ | | PE1|==================| | | +-----+ 153 | |----------|....|...PW1.(active)...|....|----------| | 154 | | | |==================| | | CE2 | 155 | CE1 | +----+ |PE2 | | | 156 | | +----+ | | +-----+ 157 | | | |==================| | 158 | |----------|....|...PW2.(standby)..| | 159 +-----+ | | PE3|==================| | 160 AC +----+ +----+ 162 Figure 1-1: Reference Model for PW Redundancy 164 In MS-PW applications, PW redundancy is also required to protect the 165 service against failures of the switching PEs, which cannot be 166 protected by PSN mechanisms. In addition, PW redundancy is also 167 required if CEs are dual-homed to the PEs, as described above. In 168 this case, multiple MS-PWs are configured between a pair of T-PE 169 nodes, as described in Figure 2 of [5]. The paths of these MS-PWs are 170 diverse in that they are switched at different S-PE nodes. Only one 171 of these MS-PWs is active at any given time, while the others are 172 standby. 174 This document specifies a new PW status bit to indicate the 175 preferential forwarding status of the PW for the purpose of notifying 176 the remote PE of the preferential forwarding state of each PW in the 177 redundancy set i.e. Active or Standby. This status bit is different 178 from the PW status bits already defined in the PWE3 control protocol 179 [2]. In addition, a second status bit is defined to allow peer PE 180 nodes to coordinate a switchover operation of the PW from Active to 181 standby, or vice versa. 183 2. Motivation and Scope 185 The PWE3 control protocol [2] defines the following status codes in 186 the PW status TLV to indicate the state for an AC and a PW: 188 0x00000000 - Pseudowire forwarding (clear all failures) 190 0x00000001 - Pseudowire Not Forwarding 192 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 194 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 196 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 198 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 200 The scenarios defined in [5] allow the provisioning of a primary PW 201 and one or many secondary PWs in the same VPWS or VPLS service. 203 A PE node makes a selection of which PW to activate at any given time 204 for the purpose of forwarding user packets. This selection takes into 205 account the local state of the PW and AC, as well as the remote state 206 of the PW and AC as indicated in the PW status bits it received from 207 the peer PE node. 209 In the absence of faults, all PWs are UP both locally and remotely 210 and a PE node needs to select a single PW to forward user packets to. 211 This is referred to as the active PW. All other PWs will be in 212 standby and must not be used to forward user packets. 214 In order for both ends of the service to select the same PW for 215 forwarding user packets, this document defines a new status bit, the 216 'Preferential Forwarding' status bit, to allow a PE node to indicate 217 the preferential forwarding state of a PW to its peer PE node. 219 In addition, a second status bit is defined to allow peer PE nodes to 220 coordinate a switchover operation of the PW if required by the 221 application. This is known as the 'request switchover' status bit. 223 Together, the mechanisms described in this document achieve the 224 following PW protection capabilities: 226 a. A MANDATORY 1:1 PW protection with a single active PW and one 227 standby PW. An active PW can forward data traffic and control 228 plane traffic, such as Operations, Administration, and 229 Maintenance (OAM) packets. A standby PW does not carry data 230 traffic. 232 b. An OPTIONAL N:1 PW protection scheme with a single active PW 233 and N standby PWs. 235 c. An OPTIONAL mechanism to allow PW endpoints to coordinate the 236 switchover to a given PW by using an explicit 237 request/acknowledgment switchover procedure. This mechanism is 238 complementary to the Independent mode of operation and is 239 described in Section 6.3. . This mechanism can be invoked 240 manually by the user, effectively providing a manual 241 switchover capability. It can also be invoked automatically to 242 resolve a situation where the PW endpoints could not match the 243 two directions of the PW. 245 d. An OPTIONAL, locally configured precedence to govern the 246 selection of a PW when more than one PW qualify for the active 247 state, as defined in sections 5.1. and 5.2. The PW with the 248 lowest precedence value has the highest priority. Precedence 249 may be configured via, for example, a local configuration 250 parameter at the PW endpoint. 252 e. OPTIONALLY, implementations can designate by configuration one 253 PW in the 1:1 or N:1 set as a primary PW and the remaining as 254 secondary PWs. If more than one PW qualify for the active 255 state, as defined in sections 5.1. and 5.2. , a PE node 256 selects the primary PW in preference to a secondary PW. In 257 other words, the primary PW has implicitly the lowest 258 precedence value. Furthermore, a PE node reverts to the 259 primary PW immediately after it comes back up or after the 260 expiration of a delay. The PE node can use the PW precedence 261 to select a secondary PW among many that qualify for active 262 state. 264 These protection schemes are provided using the following operational 265 modes: 267 1. An independent mode of operation in which each PW endpoint 268 node uses its own local rule to select which PW it intends 269 to activate at any given time and advertises it to the 270 remote endpoints. Only a PW which is UP and which indicated 271 Active status bit locally and remotely is in the active 272 state and can be used to forward data packets. This is 273 described in Section 5.1. 275 2. A Master/Slave mode in which one PW endpoint, the Master 276 endpoint, selects and dictates to the other endpoint(s), 277 the Slave endpoint(s), which PW to activate. This is 278 described in Section 5.2. 280 The above mechanisms and operational modes allow the following: 282 a.Multi-homing of a CE device to two or more PE nodes. 284 b.Multi-homing of a PE node to two or more PE nodes. 286 More details of how these schemes are used can be found in 287 Informative Appendix A. 289 Note that this document specifies the mechanisms to support PW 290 redundancy where a set of redundant PWs terminate on either a PE (for 291 SS-PW) or a T-PE (for MS-PW). PW redundancy scenarios where the 292 redundant set of PW segments terminate on an S-PE are for further 293 study. 295 3. Terminology 297 UP PW: A PW which has been configured (label mapping exchanged 298 between PEs) and is not in any of the PW or AC defect 299 states specified in [2]. Such a PW is available for 300 forwarding traffic. 302 DOWN PW: A PW that has either not been fully configured, or has been 303 configured and is in any of the PW or AC defect states 304 specified in [2], such a PW is not available for forwarding 305 traffic. 307 Active PW: An UP PW used for forwarding user, OAM and control plane 308 traffic. 310 Standby PW: An UP PW that is not used for forwarding user traffic, 311 but may forward OAM and specific control plane traffic. 313 Primary PW: The PW which a PW endpoint activates in preference to any 314 other PW when more than one PW qualifies for active state. 315 When the primary PW comes back up after a failure and 316 qualifies for active state, the PW endpoint always reverts 317 to it. The designation of Primary is performed by local 318 configuration for the PW at the PE. 320 Secondary PW: When it qualifies for active state, a Secondary PW is 321 only selected if no Primary PW is configured or if the 322 configured primary PW does not qualify for active state 323 (e.g., is DOWN). By default, a PW in a redundancy PW set is 324 considered secondary. There is no Revertive mechanism among 325 secondary PWs. 327 PW Precedence: This is a configuration local to the PE that dictates 328 the order in which a forwarder chooses to use a PW when 329 multiple PWs all qualify for the active state. Note that a 330 PW which has been configured as Primary has implicitly the 331 lowest precedence value. 333 PW Endpoint: A PE where a PW terminates on a point where Native 334 Service Processing is performed, e.g., A SS-PW PE, an MS-PW 335 T-PE, or an H-VPLS MTU-s or PE-rs. 337 OAM: Operations, Administration, and Maintenance. 339 VCCV: Virtual Connection Connectivity Verification. 341 This document uses the term 'PE' to be synonymous with both PEs as 342 per RFC3985 and T-PEs as per RFC5659. 344 This document uses the term 'PW' to be synonymous with both PWs as 345 per RFC3985 and SS-PWs and MS-PWs as per RFC5659. 347 4. PE Architecture 349 Figure 4-1 shows the PE architecture for PW redundancy, when more 350 than one PW in a redundant set is associated with a single AC. This 351 is based on the architecture in Figure 4b of RFC3985 [6]. The 352 forwarder selects which of the redundant PWs to using the criteria 353 described in this document. 355 +----------------------------------------+ 356 | PE Device | 357 +----------------------------------------+ 358 Single | | Single | PW Instance 359 AC | + PW Instance X<===========> 360 | | | 361 | |----------------------| 362 <------>o | Single | PW Instance 363 | Forwarder + PW Instance X<===========> 364 | | | 365 | |----------------------| 366 | | Single | PW Instance 367 | + PW Instance X<===========> 368 | | | 369 +----------------------------------------+ 371 Figure 4-1 PE Architecure for PW redundancy 373 5. Modes of Operation 375 There are two modes of operation for the use of the PW Preferential 376 Forwarding status bits: 378 o Independent mode 380 o Master/Slave mode. 382 5.1. Independent Mode: 384 PW endpoint nodes independently select which PW they intend to make 385 active and which PWs they intend to make standby. They advertise the 386 corresponding Active/Standby preferential forwarding status for each 387 PW. Each PW endpoint compares local and remote status bits and uses 388 the PW that is UP at both endpoints and that advertised Active 389 preferential forwarding status at both the local and remote 390 endpoints. 392 In this mode of operation, the preferential forwarding status 393 indicates the preferred forwarding state of each endpoint but the 394 actual forwarding state of the PW is the result of the comparison of 395 the local and remote forwarding status bits. 397 If more than one PW qualifies for the Active state, each PW endpoint 398 MUST implement a common mechanism to choose the PW for forwarding. 399 The default mechanism MUST be supported by all implementations and 400 operates as follows: 402 1. For FEC128 PW, the PW with the lowest pw-id value is selected. 404 2. For FEC129 PW, each PW in a redundant set is uniquely identified 405 at each PE using the following triplet: AGI::SAII::TAII. The 406 unsigned integer form of the concatenated word can be used in the 407 comparison. However, the SAII and TAII values as seen on a PE 408 node are the mirror values of what the peer PE node sees. To have 409 both PE nodes compare the same value we propose that the PE with 410 the lowest system IP address use the unsigned integer form of 411 AGI::SAII::TAII while the PE with the highest system IP address 412 use the unsigned integer form of AGI::TAII::SAII. This way, both 413 PEs will compare the same values. The PW which corresponds to the 414 minimum of the compared values across all PWs in the redundant is 415 selected. 417 Note 1: in the case where the system IP address is not known, it 418 is recommended to implement the optional tie-breaking mechanism 419 described next. 421 Note 2: in the case of segmented PW, the operator needs to make 422 sure that the pw-id or AGI::SAII::TAII of the redundant PWs within 423 the first and last segment are ordered consistently such that the 424 same end-to-end MS-PW gets selected. Otherwise, it is recommended 425 to implement the optional tie-breaking mechanism described next. 427 The PW endpoints MAY also implement the following optional tie- 428 breaking mechanism. 430 1. If the PW endpoint is configured with the precedence parameter on 431 each PW in the redundant set, it must select the PW with the 432 lowest configured precedence value. 434 2. If the PW endpoint is configured with one PW as primary and one 435 or more PWs as secondary, it must select the primary PW in 436 preference to all secondary PWs. If a primary PW is not 437 available, it must use the secondary PW with the lowest 438 precedence value. If the primary PW becomes available, a PW 439 endpoint must revert to it immediately or after the expiration of 440 a configurable delay. 442 In steady state with consistent configuration, a PE will always find 443 an active PW. However, it is possible that such a PW is not found due 444 to a mis-configuration. In the event that an active PW is not found, 445 a management indication SHOULD be generated. If a management 446 indication for failure to find an active PW was generated and an 447 active PW is subsequently found, a management indication should be 448 generated, so clearing the previous failure indication. Additionally, 449 a PE may use the optional request switchover procedures described in 450 Section 6.3. to have both PE nodes switch to a common PW. 452 There may also be transient conditions where endpoints do not share a 453 common view of the Active/Standby state of the PWs. This could be 454 caused by propagation delay of the T-LDP status messages between 455 endpoints. In this case, the behavior of the receiving endpoint is 456 outside the scope of this document. 458 Thus, in this mode of operation, the following definition of Active 459 and Standby PW states apply: 461 o Active State 463 A PW is considered to be in Active state when the PW labels are 464 exchanged between its two endpoints and the status bits exchanged 465 between the endpoints indicate the PW is UP and its preferential 466 forwarding status is Active at both endpoints. In this state user 467 traffic can flow over the PW in both directions. As described in 468 Section 5.1. , the PE nodes must implement a common mechanism to 469 select one PW for forwarding in case multiple PWs qualify for the 470 Active state. 472 o Standby State 474 A PW is considered to be in Standby state when the PW labels are 475 exchanged between its two endpoints, but the Preferential Forwarding 476 status bits exchanged indicate the PW preferential forwarding status 477 is Standby at one or both endpoints. In this state the endpoints MUST 478 NOT forward data traffic over the PW but MAY allow PW OAM packets, 479 e.g., Virtual Connection Connectivity Verification (VCCV) packets 480 [10], to be sent and received in order to test the liveliness of 481 standby PWs. The endpoints of the PW may also allow the forwarding of 482 specific control plane packets of applications using the PW. The 483 specification of applications and the allowed control plane packets 484 is outside the scope of this document. If the PW is a spoke in H- 485 VPLS, any MAC addresses learned via the PW SHOULD be flushed when it 486 transitions to Standby state according to the procedures in RFC4762 487 [3] and [9]. 489 5.2. Master/Slave Mode: 491 One endpoint node of the redundant set of PWs is designated the 492 Master and is responsible for selecting which PW both endpoints must 493 use to forward user traffic. 495 The Master indicates the forwarding state in the PW Preferential 496 Forwarding status bit. The other endpoint node, the Slave, MUST 497 follow the decision of the Master node based on the received status 498 bits. In other words, the Preferential Forwarding status bit sent by 499 the Master node indicates the actual forwarding state of the PW at 500 the Master node. 502 There is a single PE Master PW endpoint node and one or many PE PW 503 endpoint Slave nodes. The assignment of Master/Slave roles to the PW 504 endpoints is performed by local configuration. Note that the behavior 505 described in this section assumes correct configuration of the Master 506 and Slave endpoints. This document does not define a mechanism to 507 detect errors in the configuration. 509 One endpoint of the PW, the Master, actively selects which PW to 510 activate and uses it for forwarding user traffic. This status is 511 indicated to the Slave node by setting the Preferential Forwarding 512 status bit in the status bit TLV to Active. It does not forward user 513 traffic to any other of the PW's in the redundancy set to the slave 514 node and indicates this by setting the Preferential Forwarding status 515 bit in the status bit TLV to Standby for those PWs. The master node 516 MUST ignore any PW Preferential Forwarding status bits received from 517 the Slave nodes. 519 If more than one PW qualify for the Active state, and the PW endpoint 520 is configured with one PW as primary, the Master endpoint must use 521 the primary PW in preference to all secondary PWs. If a primary PW is 522 not available, it must use the secondary PW with the lowest 523 precedence value. If the primary PW becomes available, a PW endpoint 524 must revert to it immediately or after the expiration of a 525 configurable delay. These primary/secondary procedures are optional. 527 The Slave endpoint(s) are required to act on the status bits received 528 from the Master. When the received status bit transitions from Active 529 to Standby, a Slave node MUST stop forwarding over the previously 530 active PW. When the received status bit transitions from Standby to 531 Active for a given PW, the Slave node MUST start forwarding user 532 traffic over this PW. 534 In this mode of operation, the following definition of Active and 535 Standby PW states apply: 537 o Active State 539 A PW is considered to be in Active state when the PW labels are 540 exchanged between its two endpoints, and the status bits exchanged 541 between the endpoints indicate the PW is UP at both endpoints, and 542 the preferential forwarding status at the Master endpoint is Active. 543 In this state user traffic can flow over the PW in both directions. 545 o Standby State 547 A PW is considered to be in Standby state when the PW labels are 548 exchanged between its two endpoints, and the status bits exchanged 549 between the endpoints indicate the preferential forwarding status at 550 the Master endpoint is Standby. In this state the endpoints MUST NOT 551 forward data traffic over the PW but MAY allow PW OAM packets, e.g., 552 VCCV, to be sent and received. The endpoints of the PW may also allow 553 the forwarding of specific control plane packets of applications 554 using the PW. The specification of applications and the allowed 555 control plane packets is outside the scope of this document. If the 556 PW is a spoke in H-VPLS, any MAC addresses learned via the PW SHOULD 557 be flushed when it transitions to standby state according to the 558 procedures in RFC4762 [3] and [9]. 560 6. PW State Transition Signaling Procedures 562 This section describes the extensions to PW status signaling and the 563 processing rules for these extensions. It defines a new "PW 564 Preferential Forwarding" bit Status Code that is to be used with the 565 PW Status TLV specified in RFC 4447 [2]. 567 The PW Preferential Forwarding bit, when set, is used to signal 568 either the Preferred or Actual Active/Standby forwarding state of the 569 PW by one PE to the far end PE. The actual semantics of the value 570 being signaled vary according to whether the PW is acting in a 571 Master/Slave or Independent mode. 573 6.1. PW Standby Notification Procedures in Independent mode 575 PEs that contain PW endpoints independently select which PW they 576 intend to use for forwarding, depending on the specific application 577 (example applications are described in [5]). They advertise the 578 corresponding preferred Active/Standby forwarding state for each PW. 579 An Active Preferential Forwarding state is indicated by clearing the 580 PW Preferential Forwarding status bit in the PW status TLV. A Standby 581 Preferential Forwarding State is indicated by setting the PW 582 Preferential Forwarding status bit in the PW status TLV. This 583 advertisement occurs in both the initial label mapping message and in 584 a subsequent notification message when the forwarding state 585 transitions as a result of a state change in the specific 586 application. 588 Each PW endpoint compares the updated local and remote status and 589 effectively activates the PW which is UP at both endpoints and which 590 shows both local Active and remote Active Preferential Forwarding 591 states. The PE nodes must implement a common mechanism to select one 592 PW for forwarding in case multiple PWs qualify for the Active state. 594 When a PW is in Active state, the PEs can forward user packets, OAM 595 packets, and other control plane packets over the PW. 597 When a PW is in Standby state, the PEs MUST NOT forward user packets 598 over the PW but MAY forward PW OAM packets and specific control plane 599 packets. 601 For MS-PWs, S-PEs MUST relay the PW status notification containing 602 both the existing status bits and the new Preferential Forwarding 603 status bits between ingress and egress PWs as per the procedures 604 defined in [4]. 606 6.2. PW Standby notification procedures in Master/Slave mode 608 Whenever the Master PW endpoint selects or deselects a PW for 609 forwarding user traffic at its end, it explicitly notifies the event 610 to the remote Slave endpoint. The slave endpoint carries out the 611 corresponding action on receiving the PW state change notification. 613 If the PW Preferential Forwarding bit in PW Status TLV received by 614 the slave is set, it indicates that the PW at the Master end is not 615 used for forwarding and is thus kept in the Standby state, the PW 616 MUST also not be used for forwarding at Slave endpoint. Clearing the 617 PW Preferential Forwarding bit in PW Status TLV indicates that the PW 618 at the Master endpoint is used for forwarding and is in Active state, 619 and the receiving Slave endpoint MUST activate the PW if it was 620 previously not used for forwarding. 622 When this mechanism is used, a common Group ID in the PWid FEC 623 element or a PW Grouping TLV in the Generalized PWid FEC Element as 624 defined in [2] MAY be used to signal PWs in groups in order to 625 minimize the number of LDP status messages that must be sent. When 626 PWs are provisioned with such grouping a termination point sends a 627 single "wildcard" Notification message to denote this change in 628 status for all affected PWs. This status message contains either the 629 PW FEC TLV with only the Group ID, or else it contains the PW 630 Generalized FEC TLV with only the PW Grouping ID TLV. As mentioned in 631 [2], the Group ID field of the PWid FEC Element, or the PW Grouping 632 TLV in the Generalized PWid FEC Element, can be used to send status 633 notification for an arbitrary set of PWs. 635 For MS-PWs, S-PEs MUST relay the PW status notification containing 636 both the existing and the new Preferential Forwarding status bits 637 between ingress and egress PW segments as per the procedures defined 638 in [4]. 640 6.2.1. PW State Machine 642 It is convenient to describe the PW state change behavior in terms of 643 a state machine (Table 1). The PW state machine is explained in 644 detail in the two defined states and the behavior is presented as a 645 state transition table. The same state machine is applicable to PW 646 Groups. 648 STATE EVENT NEW STATE 650 ACTIVE PW put in Standby (master) STANDBY 651 Action: Transmit PW preferential 652 forwarding bit set 654 Receive PW Preferential Forwarding STANDBY 655 bit set (slave) 656 Action: Stop forwarding over PW 658 Receive PW Preferential Forwarding ACTIVE 659 bit set but bit not supported 660 Action: None 662 Receive PW Preferential Forwarding ACTIVE 663 bit clear 664 Action: None. 666 STANDBY PW activated (master) ACTIVE 667 Action: Transmit PW preferential 668 forwarding bit clear 670 Receive PW Preferential Forwarding ACTIVE 671 bit clear (slave) 672 Action: Activate PW 674 Receive PW Preferential Forwarding STANDBY 675 bit clear but bit not supported 676 Action: None 678 Receive PW Preferential Forwarding STANDBY 679 bit set 680 Action: No action 682 Table 1 PW State Transition Table in Master/Slave Mode 684 6.3. Coordination of PW Switchover 686 There are PW redundancy applications which require that PE nodes 687 coordinate the switchover to a PW such that both endpoints will 688 forward over the same PW at any given time. One such application for 689 redundant MS-PW is identified in [5]. Multiple MS-PWs are configured 690 between a pair of T-PE nodes. The paths of these MS-PWs are diverse 691 and are switched at different S-PE nodes. Only one of these MS-PWs is 692 active at any given time. The others are put in standby. The 693 endpoints follow the Independent Mode procedures to use the PW which 694 is both UP and for which both endpoints advertise an Active 695 'Preferential Forwarding' status bit. 697 The trigger for sending a request to switchover of the MS-PW by one 698 endpoint can be an operational event, for example a failure, which 699 causes the endpoints to be unable to find a common PW for which both 700 endpoints advertise an Active 'Preferential Forwarding' status bit. 701 The other trigger is the execution of an administrative maintenance 702 operation by the network operator in order to move the traffic away 703 from the nodes or links currently used by the active PW. 705 Unlike the case of a Master/Slave mode of operation, the endpoint 706 requesting the switchover requires explicit acknowledgement from the 707 peer endpoint that the request can be honored before it switches to 708 another PW. Furthermore, any of the endpoints can make the request to 709 switchover. 711 This document specifies a second status bit that is used by a PE to 712 request that its peer PE switchover to use a different active PW. 713 This bit is referred to as the 'request PW switchover' status bit. 714 The 'Preferential Forwarding' status bit continues to be used by each 715 endpoint to indicate its current local settings of the Active/Standby 716 state of each PW in the redundancy set. In other words, as in the 717 Independent mode, it indicates to the far-end which of the PWs is 718 being used to forward packets and which is being put in standby. It 719 can thus be used as a way for the far-end to acknowledge the 720 requested switchover operation. 722 The request switchover bit is OPTIONAL and, if received by a PE, is 723 ignored if not understood. 725 If the request switchover bit is supported by both sending and 726 receiving PEs, the following procedures MUST be followed by both 727 endpoints of a PW to coordinate the switchover of the PW. 729 S-PEs nodes MUST relay the PW status notification containing the 730 existing status bits, as well as the new 'Preferential Forwarding' 731 and 'request switchover' status bits between ingress and egress PW 732 segments as per the procedures defined in [4]. 734 6.3.1. Procedures at the requesting endpoint 736 a. The requesting endpoint sends a Status TLV in the LDP 737 notification message with the 'request switchover' bit set on the 738 PW it desires to switch to. 740 b. The endpoint does not activate forwarding on that PW at this 741 point in time. It MAY, however, enable receiving on that PW. Thus 742 the 'Preferential Forwarding' status bit still reflects the 743 currently-used PW. 745 c. The requesting endpoint starts a timer while waiting the remote 746 endpoint to acknowledge the request. 748 d. If while waiting for the acknowledgment, the requesting endpoint 749 receives a request from its peer to switchover to the same or a 750 different PW, it must perform the following: 752 i. If its address is higher than that of the peer, this 753 endpoint ignores the request and continues to wait for 754 the acknowledgement from its peer. 756 ii. If its system IP address is lower than that of its peer, 757 it aborts the timer and immediately starts the 758 procedures of the receiving endpoint in Section 6.3.2. 760 e. If while waiting for the acknowledgment, the requesting 761 endpoint receives a status notification message from its peer 762 with the 'Preferential Forwarding' status bit cleared in the 763 requested PW, it must treat this as an explicit acknowledgment of 764 the request and must perform the following: 766 i. Abort the timer. 768 ii. Activate the PW. 770 iii. Send an update status notification message with the 771 'Preferential Forwarding' status bit and the 'request 772 switchover' bit clear on the newly active PW and send an 773 update status notification message with the 774 'Preferential Forwarding' status bit set in the 775 previously active PW. 777 f. If while waiting for the acknowledgment, the requesting endpoint 778 detects that the requested PW went into DOWN state locally, and 779 could use an alternate PW which is UP, it must perform the 780 following: 782 i. Abort the timer. 784 ii. Issue a new request to switchover to the alternate PW. 786 iii. Re-start the timer. 788 g. If, while waiting for the acknowledgment, the requesting endpoint 789 detects that the requested PW went into the DOWN state locally, 790 and could not use an alternate PW which is UP, it must perform 791 the following: 793 i. Abort the timer. 795 ii. Send an update status notification message with the 796 'Preferential Forwarding' status bit unchanged and the 797 'request switchover' bit reset for the requested PW. 799 h. If, while waiting for the acknowledgment, the timer expires, the 800 requesting endpoint MUST assume that the request was rejected and 801 MAY issue a new request. 803 i. If the requesting node receives the acknowledgment after the 804 request expired, it will treat it as if the remote endpoint 805 unilaterally switched between the PWs without issuing a request. 806 In that case, it may issue a new request and follow the 807 requesting endpoint procedures to synchronize which PW to use for 808 the transmit and receive directions of the emulated service. 810 6.3.2. Procedures at the receiving endpoint 812 a. Upon receiving a status notification message with the 'request 813 switchover' bit set on a PW different from the currently active 814 one, and the requested PW is UP, the receiving endpoint must 815 perform the following: 817 i. Activate the PW. 819 ii. Send an update status notification message with the 820 'Preferential Forwarding' status bit clear and the 821 'request switchover' bit reset on the newly active PW , 822 and send an update status notification message with the 823 'Preferential Forwarding' status bit set in the 824 previously active PW. 826 iii. Upon receiving a status notification message with the 827 'request switchover' bit set on a PW different from the 828 currently active one, and the requested PW is DOWN, the 829 receiving endpoint MUST ignore the request. 831 7. Status Mapping 833 The generation and processing of the PW Status TLV must follow the 834 procedures in RFC 4447 [2]. The PW status TLV is sent on the active 835 PW and standby PWs to make sure the remote AC and PW states are 836 always known to the local PE node. 838 The generation and processing of PW Status TLV by an S-PE node in a 839 MS-PW must follow the procedures in [4]. 841 The procedures for determining and mapping PW and AC states must 842 follow the rules in [7] with the following modifications. 844 7.1. AC Defect State Entry/Exit 846 A PE enters the AC receive (or transmit) defect state for a PW when 847 one or more of the conditions specified for this PW type in [7] are 848 met. 850 When a PE enters the AC receive (or transmit) defect state for a PW, 851 it must send a forward (reverse) defect indication to the remote 852 peers over all PWs in the redundancy set when required by the PW type 853 in [7]. 855 When a PE exits the AC receive (or transmit) defect state for a PW 856 service, it must clear the forward (or reverse) defect indication to 857 the remote peers over all PWs in the redundancy set when required by 858 the PW type in [7]. 860 7.2. PW Defect State Entry/Exit 862 A PE enters the PW receive (or transmit) defect state for a PW 863 service when one or more of the conditions specified in Section 8.2.1 864 (Section 8.2.2) in [7] are met for all PWs in the redundancy set. 866 When a PE enters the PW receive (or transmit) defect state for a PW 867 service, it must send a reverse (or forward) defect indication over 868 one or more of the PWs in the redundancy set if the PW failure was 869 detected by this PE without receiving a forward defect indication 870 from the remote PE [7]. 872 When a PE exits the PW receive (or transmit) defect state for a PW, 873 it must clear the reverse (or forward) defect indication over any PW 874 in the redundancy set if applicable. 876 8. Applicability and Backward Compatibility 878 The mechanisms defined in this document are applicable to 879 applications where standby state signaling of a PW or PW group is 880 required. Both PW FEC 128 and 129 are supported. All PWs which are 881 part of a redundant set must use the same FEC type. When the set uses 882 FEC 128 PWs, each PW is uniquely identified by its PW-ID. When the 883 redundant set uses FEC 129 PWs, each PW must have a unique identifier 884 which consists of the triplet AGI::SAII::TAII. 886 A PE implementation that uses the mechanisms described in this 887 document MUST negotiate the use of PW status TLV between its T-LDP 888 peers as per RFC 4447 [2]. If PW Status TLV is found to be not 889 supported by either of its endpoint after status negotiation 890 procedures, then the mechanisms specified in this document cannot be 891 used. 893 A PE implementation compliant to RFC 4447 [2], and which does not 894 support the generation or processing of the 'Preferential Forwarding' 895 status bit or of the 'request switchover' status bit, will ignore 896 these status bits if they are received from a peer PE. 898 9. Security Considerations 900 This document uses the LDP extensions that are needed for protecting 901 pseudowires. It will have the same security properties as in the PWE3 902 control protocol [2]. 904 10. MIB Considerations 906 This document makes the following update to the PwOperStatusTC 907 textual convention in RFC5542 [8]: 909 PwOperStatusTC ::= TEXTUAL-CONVENTION 910 STATUS current 911 DESCRIPTION 912 "Indicates the operational status of the PW. 914 - up(1): Ready to pass packets. 916 - down(2): PW signaling is not yet finished, or 917 indications available at the service 918 level indicate that the PW is not 919 passing packets. 921 - testing(3): AdminStatus at the PW level is set to 922 test. 924 - dormant(4): The PW is not in a condition to pass 925 packets but is in a 'pending' state, 926 waiting for some external event. For example, the 927 PW Preferential Forwarding status state machine as defined in 928 [RFCXXXX (this document)] is in state "STANDBY". 930 - notPresent(5): Some component is missing to accomplish 931 the setup of the PW. It can be 932 configuration error, incomplete 933 configuration, or a missing H/W component. 935 - lowerLayerDown(6): One or more of the lower-layer interfaces 936 responsible for running the underlying PSN 937 is not in OperStatus 'up' state." 939 SYNTAX INTEGER { 940 up(1), 941 down(2), 942 testing(3), 943 dormant(4), 944 notPresent(5), 945 lowerLayerDown(6) 946 } 948 11. IANA Considerations 950 This document defines the following PW status codes for the PW 951 redundancy application. IANA is requested to allocate these from the 952 PW Status Codes registry. 954 11.1. Status Code for PW Preferential Forwarding Status 956 0x00000020 When the bit is set, it indicates "PW forwarding 958 standby". 960 When the bit is cleared, it indicates "PW forwarding 961 active". 963 11.2. Status Code for PW Request Switchover Status 965 0x00000040 When the bit is set, it represents "Request switchover to 966 this PW". 968 When the bit is cleared, it represents no specific 969 action. 971 12. Major Contributing Authors 973 The editors would like to thank Matthew Bocci, Pranjal Kumar Dutta, 974 Giles Heron, Marc Lasserre, Luca Martini, Thomas Nadeau, Jonathan 975 Newton, Hamid Ould-Brahim, and Olen Stokes, who made a major 976 contribution to the development of this document. 978 Matthew Bocci 979 Alcatel-Lucent 980 Email: matthew.bocci@alcatel-lucent.com 982 Pranjal Kumar Dutta 983 Alcatel-Lucent 984 Email: pranjal.dutta@alcatel-lucent.com 986 Giles Heron 987 Cisco Systems, Inc. 988 giles.heron@gmail.com 990 Marc Lasserre 991 Alcatel-Lucent 992 Email: marc.lasserre@alcatel-lucent.com 994 Luca Martini 995 Cisco Systems, Inc. 996 Email: lmartini@cisco.com 998 Thomas Nadeau 999 CA Technologies 1000 thomas.nadeau@ca.com 1002 Jonathan Newton 1003 Cable & Wireless Worldwide 1004 Email: Jonathan.Newton@cw.com 1005 Hamid Ould-Brahim 1006 Nortel 1007 Email: hbrahim@nortel.com 1009 Olen Stokes 1010 Extreme Networks 1011 Email: ostokes@extremenetworks.com 1013 13. Acknowledgments 1015 The authors would like to thank the following individuals for their 1016 valuable comments and suggestions which improved the document both 1017 technically and editorially: 1019 Vach Kompella, Kendall Harvey, Tiberiu Grigoriu, John Rigby, 1020 Prashanth Ishwar, Neil Hart, Kajal Saha, Florin Balus, Philippe 1021 Niger, Dave McDysan, Roman Krzanowski, Italo Busi, Robert Rennison, 1022 Nicolai Leymann and Daniel Cohn. 1024 14. References 1026 14.1. Normative References 1028 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1029 Levels", BCP 14, RFC 2119, March 1997. 1031 [2] Martini, L., et al., "Pseudowire Setup and Maintenance using 1032 LDP", RFC 4447, April 2006. 1034 [3] Kompella,V., Lasserrre, M. , et al., "Virtual Private LAN 1035 Service (VPLS) Using LDP Signalling", RFC 4762, January 2007. 1037 14.2. Informative References 1039 [4] Martini, L., et al., "Segmented Pseudo Wire", RFC 6073, January 1040 2011. 1042 [5] Muley, P., et al., "Pseudowire (PW) Redundancy", draft-ietf- 1043 pwe3-redundancy-06.txt", February 2012. 1045 [6] Bryant, S., et al., "Pseudo Wire Emulation Edge-to-Edge (PWE3) 1046 Architecture", RFC 3985, March 2005 1048 [7] Aissaoui, M., et al., "Pseudo Wire (PW) OAM Message Mapping", 1049 RFC 6310, July 2011. 1051 [8] Nadeau, T., Zelig, D., Nicklass, O., "Definitions of Textual 1052 Conventions for Pseudowire (PW) Management", RFC5542, May 2009 1054 [9] Dutta, P., Lasserre, M., Stokes, O., "LDP Extensions for 1055 Optimized MAC Address Withdrawal in H-VPLS", draft-ietf-l2vpn- 1056 vpls-ldp-mac-opt-05.txt, October 2011 1058 [10] [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual 1059 Circuit Connectivity Verification (VCCV): A Control Channel for 1060 Pseudowires", RFC 5085, December 2007. 1062 15. Appendix A - Applications of PW Redundancy Procedures 1064 This section shows how the mechanisms described in this document are 1065 used to achieve the desired protection behavior for the scenarios 1066 described in the PW redundancy requirements and framework document 1067 [5]. 1069 15.1. One Multi-homed CE with single SS-PW redundancy 1071 The following figure illustrates an application of single segment 1072 pseudowire redundancy. 1074 |<-------------- Emulated Service ---------------->| 1075 | | 1076 | |<------- Pseudo Wire ------>| | 1077 | | | | 1078 | | |<-- PSN Tunnels-->| | | 1079 | V V V V | 1080 V AC +----+ +----+ AC V 1081 +-----+ | | PE1|==================| | | +-----+ 1082 | |----------|....|...PW1.(active)...|....|----------| | 1083 | | | |==================| | | CE2 | 1084 | CE1 | +----+ |PE2 | | | 1085 | | +----+ | | +-----+ 1086 | | | |==================| | 1087 | |----------|....|...PW2.(standby)..| | 1088 +-----+ | | PE3|==================| | 1089 AC +----+ +----+ 1091 Figure 15-1 Multi-homed CE with single SS-PW redundancy 1093 The application in Figure 15-1 makes use of the Independent mode of 1094 operation. 1096 CE1 is dual homed to PE1 and to PE3 by attachment circuits. The 1097 method for dual-homing of CE1 to PE1 and to PE3 nodes, and the 1098 protocols used, are outside the scope of this document (see [5]). 1100 In this example, the AC from CE1 to PE1 is active, while the AC from 1101 CE1 to PE3 is standby, as determined by the redundancy protocol 1102 running on the ACs. Thus, in normal operation, PE1 and PE3 will 1103 advertise "Active" and "Standby" 'Preferential Forwarding' status bit 1104 respectively to PE2, reflecting the forwarding state of the two ACs 1105 to CE1 as determined by the AC dual-homing protocol. PE2 advertises 1106 'Preferential Forwarding' status bit of "Active" on both PW1 and PW2 1107 since the AC to CE2 is single homed. As both the local and remote 1108 UP/DOWN status and preferential forwarding status for PW1 are UP and 1109 Active, traffic is forwarded over PW1 in both directions. 1111 On failure of the AC between CE1 and PE1, the forwarding state of the 1112 AC on PE3 transitions to Active. PE3 then announces the newly changed 1113 'Preferential Forwarding' status bit of "Active" to PE2. PE1 will 1114 advertise a PW status notification message indicating that the AC 1115 between CE1 and PE1 is DOWN. PE2 matches the local and remote 1116 preferential forwarding status of "Active" and status of "Pseudowire 1117 forwarding" and select PW2 as the new active pseudowire to send 1118 traffic to. 1120 On failure of PE1 node, PE3 will detect it and will transition the 1121 forwarding state of its AC to Active. The method by which PE3 detects 1122 that PE1 is down is outside the scope of this document. PE3 then 1123 announces the newly changed 'Preferential Forwarding' status bit of 1124 "Active" to PE2. PE3 and PE2 match the local and remote preferential 1125 forwarding status of "Active" and UP/DOWN status "Pseudowire 1126 forwarding" and select PW2 as the new active pseudowire to send 1127 traffic to. Note that PE2 may have detected that the PW to PE1 went 1128 down via T-LDP Hello timeout or via other means. However, it will not 1129 be able to forward user traffic until it receives the updated status 1130 bit from PE3. 1132 Note in this example, the receipt of the AC status on the CE1-PE1 1133 link is normally sufficient for PE2 to switch to PW2. However, the 1134 operator may want to trigger the switchover of the PW for 1135 administrative reasons, e.g., maintenance, and thus the use of the 1136 'Preferential Forwarding' status bit is required to notify PE2 to 1137 trigger the switchover. 1139 Note that the primary/secondary procedures do not apply in this case 1140 as the PW PW Preferential Forwarding status is driven by the AC 1141 forwarding state as determined by the AC dual-homing protocol used. 1143 15.2. Multiple Multi-homed CEs with single SS-PW redundancy 1145 |<-------------- Emulated Service ---------------->| 1146 | | 1147 | |<------- Pseudo Wire ------>| | 1148 | | | | 1149 | | |<-- PSN Tunnels-->| | | 1150 | V V (not shown) V V | 1151 V AC +----+ +----+ AC V 1152 +-----+ | |....|.......PW1........|....| | +-----+ 1153 | |----------| PE1|...... .........| PE3|----------| | 1154 | CE1 | +----+ \ / PW3 +----+ | CE2 | 1155 | | +----+ X +----+ | | 1156 | | | |....../ \..PW4....| | | | 1157 | |----------| PE2| | PE4|--------- | | 1158 +-----+ | |....|.....PW2..........|....| | +-----+ 1159 AC +----+ +----+ AC 1161 Figure 15-2 Multiple Multi-homed CEs with single SS-PW redundancy 1163 The application in Figure 15-2 makes use of the Independent mode of 1164 operation. 1166 CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed PE3 and PE4. The 1167 method for dual-homing and the used protocols are outside the scope 1168 of this document. Note that the PSN tunnels are not shown in this 1169 figure for clarity. However, it can be assumed that each of the PWs 1170 shown is encapsulated in a separate PSN tunnel. 1172 Assume that the AC from CE1 to PE1 is Active, from CE1 to PE2 is 1173 Standby; furthermore, assume that the AC from CE2 to PE3 is Standby 1174 and from CE2 to PE4 is Active. The method of deriving Active/Standby 1175 status of the AC is outside the scope of this document. 1177 PE1 advertises the preferential status "Active" and UP/DOWN status 1178 "Pseudowire forwarding" for pseudowires PW1 and PW4 connected to PE3 1179 and PE4. This status reflects the forwarding state of the AC 1180 attached to PE1. PE2 advertises preferential status "Standby" and 1181 UP/DOWN status "Pseudowire forwarding" for pseudowires PW2 and PW3 1182 to PE3 and PE4. PE3 advertises preferential status "Standby" and 1183 UP/DOWN status "Pseudowire forwarding" for pseudowires PW1 and PW3 1184 to PE1 and PE2. PE4 advertise the preferential status "Active" and 1185 UP/DOWN status "Pseudowire forwarding" for pseudowires PW2 and PW4 1186 to PE2 and PE1 respectively. Thus by matching the local and remote 1187 preferential forwarding status of "Active" and UP/DOWN status of 1188 "Pseudowire forwarding" of pseudowires, the PE nodes determine which 1189 PW should be in the Active state. In this case it is PW4 that will 1190 be selected. 1192 On failure of the AC between CE1 and PE1, the forwarding state of 1193 the AC on PE2 is changed to Active. PE2 then announces the newly 1194 changed 'Preferential Forwarding' status bit of "active" to PE3 and 1195 PE4. PE1 will advertise a PW status notification message indicating 1196 that the AC between CE1 and PE1 is down. PE2 and PE4 match the local 1197 and remote preferential forwarding status of "Active" and UP/DOWN 1198 status "Pseudowire forwarding" and select PW2 as the new active 1199 pseudowire to send traffic to. 1201 On failure of PE1 node, PE2 will detect it and will transition the 1202 forwarding state of its AC to Active. The method by which PE2 1203 detects that PE1 is down is outside the scope of this document. PE2 1204 then announces the newly changed 'Preferential Forwarding' status 1205 bit of "Active" to PE3 and PE4. PE2 and PE4 match the local and 1206 remote preferential forwarding status of "Active" and UP/DOWN status 1207 "Pseudowire forwarding" and select PW2 as the new active pseudowire 1208 to send traffic to. Note that PE3 and PE4 may have detected that the 1209 PW to PE1 went down via T-LDP Hello timeout or via other means. 1211 However, they will not be able to forward user traffic until they 1212 received the updated status bit from PE2. 1214 Because each dual-homing algorithm running on the two node sets, 1215 i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects the active AC 1216 independently, there is a need to signal the active status of the AC 1217 such that the PE nodes can select a common active PW for end-to-end 1218 forwarding between CE1 and CE2 as per the procedures in the 1219 independent mode. 1221 Note that any primary/secondary procedures, as defined in sections 1222 5.1. and 5.2. , do not apply in this use case as the Active/Standby 1223 status is driven by the AC forwarding state as determined by the AC 1224 dual-homing protocol used. 1226 15.3. Multi-homed CE with MS-PW redundancy 1228 The following figure illustrates an application of multi-segment 1229 pseudowire redundancy. 1231 Native |<-----------Pseudo Wire----------->| Native 1232 Service | | Service 1233 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 1234 | V V V V V V | 1235 | +-----+ +-----+ +-----+ 1236 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 1237 | |-------|......PW1-Seg1.......|PW1-Seg2.......|-------| | 1238 | | | |=========| |=========| | | | 1239 | CE1| +-----+ +-----+ +-----+ | | 1240 | | |.| +-----+ +-----+ | CE2| 1241 | | |.|===========| |=========| | | | 1242 | | |.....PW2-Seg1......|.PW2-Seg2......|-------| | 1243 +----+ |=============|S-PE2|=========|T-PE4| | +----+ 1244 +-----+ +-----+ AC 1246 Figure 15-3 Multi-homed CE with MS-PW redundancy 1248 The application in Figure 15-3 makes use of the Independent mode of 1249 operation. 1251 CE2 is dual-homed to T-PE2 and T-PE4. PW1 and PW2 are used to extend 1252 the resilient connectivity all the way to T-PE1. PW1 has two segments 1253 and is active pseudowire while PW2 has two segments and is a standby 1254 pseudowire. This application requires support for MS-PW with segments 1255 of the same type as described in [4]. 1257 The operation in this case is the same as in the case of SS-PW as 1258 described in Section 15.1. . The only difference is that the S-PE 1259 nodes need to relay the PW status notification containing both the 1260 UP/DOWN and forwarding status to the T-PE nodes. 1262 15.4. Multi-homed CE with MS-PW redundancy and S-PE protection 1264 The following figure illustrates an application of multi-segment 1265 pseudowire redundancy with 1:1 PW protection. 1267 Native |<-----------Pseudo Wire------------->| Native 1268 Service | | Service 1269 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 1270 | V V V V V V | 1271 | +-----+ | 1272 | |=============| |=============| | 1273 | |.....PW3-Seg1......|.PW3-Seg2....| | 1274 | |.|===========|S-PE3|===========|.| | 1275 | |.| +-----+ |.| | 1276 | +-----+ +-----+ +-----+ | 1277 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 1278 | |-------|......PW1-Seg1.......|PW1-Seg2.......|-------| | 1279 | | | |=========| |=========| | | | 1280 | CE1| +-----+ +-----+ +-----+ | | 1281 | | |.| |.| +-----+ +-----+ | CE2| 1282 | | |.| |.|=========| |=========| | | | 1283 | | |.| |...PW2-Seg1......|.PW2-Seg2......|-------| | 1284 +----+ |.| |===========|S-PE2|=========|T-PE4| | +----+ 1285 |.| +-----+ +-----+ AC 1286 |.| +-----+ |.| 1287 |.|=============| |===========|.| 1288 |.......PW4-Seg1......|.PW4-Seg2....| 1289 |===============|S-PE4|=============| 1290 +-----+ 1292 Figure 15-4 Multi-homed CE with MS-PW redundancy and protection 1294 The application in Figure Figure 15-4 makes use of the 1295 Independent mode of operation. 1297 CE2 is dual-homed to T-PE2 and T-PE4. The PW pairs {PW1,PW3} and 1298 {PW2, PW4} are used to extend the resilient connectivity all the 1299 way to T-PE1, like in the case in Section 15.3. , with the 1300 addition that this setup provides for S-PE node protection. 1302 CE1 is connected to T-PE1 while CE2 is dual-homed to T-PE2 and 1303 T-PE4. There are four segmented PWs. PW1 and PW2 are primary PWs 1304 and are used to support CE2 multi-homing. PW3 and PW4 are 1305 secondary PWs and are used to support 1:1 PW protection. PW1, 1306 PW2, PW3 and PW4 have two segments and they are switched at S- 1307 PE1, S-PE2, S-PE3 and S-PE4 respectively. 1309 It is possible that S-PE1 coincides with S-PE4 and/or SP-2 1310 coincides with S-PE3, in particular where the two PSN domains 1311 are interconnected via two nodes. However Figure 15-4 shows four 1312 separate S-PEs for clarity. 1314 The behavior of this setup is exactly the same as in the setup 1315 in Section 15.3. except that T-PE1 will always see a pair of 1316 PWs eligible for the active state, for example the pair 1317 {PW1,PW3} when the AC between CE2 and T-PE2 is in active state. 1318 Thus, it is important that both T-PE1 and T-PE2 implement a 1319 common mechanism to choose one the two PWs for forwarding as 1320 explained in Section 5.1. Similarly, T-PE1 and T-PE4 must use 1321 the same mechanism to select among the pair {PW2, PW4} when the 1322 AC between CE2 and T-PE4 is in active state. 1324 15.5. Single Homed CE with MS-PW redundancy 1326 The following is an application of the independent mode of operation 1327 along with the optional request switchover procedures in order to 1328 provide N:1 PW protection. A revertive behavior to a primary PW is 1329 shown as an example of configuring and using the primary/secondary 1330 procedures described in sections 5.1. and 5.2. . 1332 Native |<------------Pseudo Wire------------>| Native 1333 Service | | Service 1334 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 1335 | V V V V V V | 1336 | +-----+ +-----+ +-----+ | 1337 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 1338 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 1339 | CE1| | |=========| |=========| | | CE2| 1340 | | +-----+ +-----+ +-----+ | | 1341 +----+ |.||.| |.||.| +----+ 1342 |.||.| +-----+ |.||.| 1343 |.||.|=========| |========== .||.| 1344 |.||...PW2-Seg1......|.PW2-Seg2...||.| 1345 |.| ===========|S-PE2|============ |.| 1346 |.| +-----+ |.| 1347 |.|============+-----+============= .| 1348 |.....PW3-Seg1.| | PW3-Seg2......| 1349 ==============|S-PE3|=============== 1350 | | 1351 +-----+ 1353 Figure 15-5 Single homed CE with multi-segment pseudowire redundancy 1355 CE1 is connected to PE1 in provider Edge 1 and CE2 to PE2 in provider 1356 edge 2 respectively. There are three segmented PWs. A primary PW, 1357 PW1, is switched at S-PE1. A primary PW, PW1 has the lowest 1358 precedence value of zero. A secondary PW, PW2, which is switched at 1359 S-PE2 and has a precedence of 1. Finally, another secondary PW, PW3, 1360 is switched at S-PE3 and has a precedence of 2. The precedence is 1361 locally configured at the endpoints of the PW, i.e., T-PE1 and T-PE2. 1362 Lower the precedence value, higher the priority. 1364 T-PE1 and T-PE2 will select the PW they intend to activate based on 1365 their local and remote UP/DOWN state as well as the local precedence 1366 configuration. In this case, they will both advertise Preferential 1367 Forwarding' status bit of "Active" on PW1 and of "Standby" on PW2 and 1368 PW3 using priority derived from local precedence configuration. 1369 Assuming all PWs are UP, T-PE1 and T-PE2 will use PW1 to forward user 1370 packets. 1372 If PW1 fails, then the T-PE detecting the failure will send a status 1373 notification to the remote T-PE with a "Local PSN-facing PW (ingress) 1374 Receive Fault" bit set, or a "Local PSN-facing PW (egress) Transmit 1375 Fault" bit set, or a "Pseudowire Not Forwarding" bit set. In 1376 addition, it will set the 'Preferential Forwarding' status bit on PW1 1377 to "Standby". It will also advertise the 'Preferential Forwarding' 1378 status bit on PW2 as "Active" as it has the next lowest precedence 1379 value. T-PE2 will also perform the same steps as soon as it is 1380 informed of the failure of PW1. Both T-PE nodes will perform a match 1381 on the 'preferential forwarding' status of "Active" and UP/DOWN 1382 status of "Pseudowire forwarding" and will use PW2 to forward user 1383 packets. 1385 However this does not guarantee that the T-PEs will choose the same 1386 PW from the redundant set to forward on, for a given emulated 1387 service, at all times. This may be due to a mismatch of the 1388 configuration of the PW precedence in each T-PE. This may also be due 1389 to a failure which caused the endpoints to not be able to match the 1390 Active 'Preferential Forwarding' status bit and UP/DOWN status bits. 1391 In this case, T-PE1 and/or T-PE2 can invoke the optional request 1392 switchover/acknowledgement procedures to synchronize the choice of PW 1393 to forward on in both directions. 1395 The trigger for sending a request to switchover can also be the 1396 execution of an administrative maintenance operation by the network 1397 operator in order to move the traffic away from the T-PE/S-PE nodes 1398 /links to be serviced. 1400 In case the request switchover is sent by both endpoints 1401 simultaneously, both T-PEs send status notification with the newly 1402 selected PW with 'request switchover' bit set, waiting for response 1403 from the other endpoint. In such situation, the T-PE with greater 1404 system address request is given precedence. This helps in 1405 synchronizing PWs in event of mismatch of precedence configuration as 1406 well. 1408 On recovery of primary PW1, PW1 is selected to forward traffic 1409 and the secondary PW, PW2, is set to standby. 1411 15.6. PW redundancy between H-VPLS MTU-s and PE-rs 1413 Following figure illustrates the application of use of PW redundancy 1414 in H-VPLS for the purpose of dual-homing an MTU-s node to PE nodes 1415 using PW spokes. This application makes use of the Master/Slave mode 1416 of operation. 1418 |<-PSN1-->| |<-PSN2-->| 1419 V V V V 1420 +-----+ +--------+ 1421 |MTU-s|=========|PE1-rs |======== 1422 |..Active PW group.... | H-VPLS-core 1423 | |=========| |========= 1424 +-----+ +--------+ 1425 |.| 1426 |.| +--------+ 1427 |.|===========| |========== 1428 |...Standby PW group |.H-VPLS-core 1429 =============| PE2-rs|========== 1430 +--------+ 1432 Figure 15-6 Multi-homed MTU-s in H-VPLS core 1434 MTU-s is dual homed to PE1-rs and PE2-rs. The primary spoke PWs from 1435 MTU-s are connected to PE1-rs while the secondary PWs are connected 1436 to PE2. PE1-rs and PE2-rs are connected to H-VPLS core on the other 1437 side of network. MTU-s communicates to PE1-rs and PE2-rs the 1438 forwarding status of its member PWs for a set of VSIs having common 1439 status Active/Standby. It may be signaled using PW grouping with 1440 common group-id in PWid FEC Element or Grouping TLV in Generalized 1441 PWid FEC Element as defined in [2] to scale better. MTU-s derives 1442 the status of the PWs based on local policy configuration. In this 1443 example, the primary/secondary procedures, as defined in Section 5.2. 1444 , are used but this can be based on any other policy. 1446 Whenever MTU-s performs a switchover, it sends a wildcard 1447 Notification Message to PE2-rs for the previously standby PW group 1448 containing PW Status TLV with PW Preferential Forwarding bit cleared. 1449 On receiving the notification PE-2rs unblocks all member PWs 1450 identified by the PW group and state of PW group changes from Standby 1451 to Active. All procedures described in Section 6.2. are applicable. 1453 The use of the 'Preferential Forwarding' status bit in Master/Slave 1454 mode is similar to Topology Change Notification in RSTP controlled 1455 IEEE Ethernet Bridges but is restricted over a single hop. When these 1456 procedures are implemented, PE-rs devices are aware of switchovers at 1457 MTU-s and could generate MAC Withdraw Messages to trigger MAC 1458 flushing within the H-VPLS full mesh. By default, MTU-s devices 1459 should still trigger MAC Withdraw messages as currently defined in 1460 [6] to prevent two copies of MAC withdraws to be sent, one by MTU-s 1461 and another one by PE-rs nodes. Mechanisms to disable MAC Withdraw 1462 trigger in certain devices is out of the scope of this document 1464 Author's Addresses 1466 Praveen Muley 1467 Alcatel-lucent 1468 701 E. Middlefiled Road 1469 Mountain View, CA, USA 1470 Email: Praveen.muley@alcatel-lucent.com 1472 Mustapha Aissaoui 1473 Alcatel-lucent 1474 600 March Rd 1475 Kanata, ON, Canada K2K 2E6 1476 Email: mustapha.aissaoui@alcatel-lucent.com