idnits 2.17.1 draft-ietf-pwe3-redundancy-bit-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 670 has weird spacing: '... of the reque...' == Line 800 has weird spacing: '...t or of the '...' -- 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 (October 24, 2009) is 5291 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: '3' is defined on line 851, 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 (-18) exists of draft-ietf-pwe3-segmented-pw-13 == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-02 == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-11 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Praveen Muley 2 Internet Draft Mustapha Aissaoui 3 Intended Status: Standards Track Matthew Bocci 4 Expires: April 2010 Pranjal Kumar Dutta 5 Marc Lasserre 6 Alcatel-Lucent 8 Jonathan Newton 9 Cable & Wireless 11 Olen Stokes 12 Extreme Networks 14 Hamid Ould-Brahim 15 Nortel 17 Luca Martini 18 Cisco Systems Inc. 20 Giles Heron 21 Thomas Nadeau 22 BT 24 October 24, 2009 26 Preferential Forwarding Status bit definition 27 draft-ietf-pwe3-redundancy-bit-02.txt 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on April 24, 2010. 52 Copyright and License Notice 54 Copyright (c) 2009 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 Abstract 69 This document describes a mechanism for standby status signaling of 70 redundant PWs between their termination points. A set of redundant 71 PWs is configured between PE nodes in SS-PW applications, or between 72 T-PE nodes in MS-PW applications. 74 In order for the PE/T-PE nodes to indicate the preferred PW path to 75 forward to one another, a new status bit is needed to indicate a 76 preferential forwarding status of active or standby for each PW in 77 the redundancy set. 79 In addition, a second status bit is defined to allow peer PE/T-PE 80 nodes to coordinate a switchover operation of the PW/MS-PW path. 82 Conventions used in this document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC-2119 [1]. 88 Table of Contents 90 1. Introduction...................................................3 91 2. Motivation and Scope...........................................5 92 3. Terminology....................................................7 93 4. Modes of Operation.............................................8 94 4.1. Independent Mode:.........................................8 95 4.2. Master/Slave Mode:........................................9 96 5. Signaling procedures of PW State Transition...................11 97 5.1. PW Standby notification procedures in Independent mode...11 98 5.2. PW Standby notification procedures in Master/Slave mode..12 99 5.2.1. PW State Machine....................................12 100 5.3. Coordination of PW Path Switchover.......................14 101 5.3.1. Procedures at the requesting endpoint...............15 102 5.3.2. Procedures at the receiving endpoint................17 103 6. Operational Status Mapping....................................17 104 6.1. AC Defect State Entry/Exit...............................18 105 6.2. PW Defect State Entry/Exit...............................18 106 7. Applicability and Backward Compatibility......................18 107 8. Security Considerations.......................................19 108 9. IANA Considerations...........................................19 109 9.1. Status Code for PW Preferential Forwarding Status........19 110 9.2. Status Code for PW Request Switchover Status.............19 111 10. Acknowledgments..............................................19 112 11. References...................................................20 113 11.1. Normative References....................................20 114 11.2. Informative References..................................20 115 12. Appendix A - Applications of PW Redundancy Procedures........20 116 12.1. One Multi-homed CE with single SS-PW redundancy.........20 117 12.2. Multiple Multi-homed CEs with single SS-PW redundancy...22 118 12.3. Multi-homed CE with MS-PW redundancy....................24 119 12.4. Single Homed CE with MS-PW redundancy...................25 120 12.5. PW redundancy between H-VPLS MTU-s and PE-rs............26 121 Author's Addresses...............................................28 123 1. Introduction 125 In single-segment PW (SS-PW) services such as VPWS and VPLS, 126 protection for the PW is provided by the PSN layer. This may be an 127 RSVP-TE LSP with a FRR backup and/or an end-to-end backup LSP. There 128 are however applications where PSN protection is insufficient to 129 fully protect the PWE3 service and pseudowire redundancy is required. 130 These scenarios are described in the PW redundancy and framework 131 document [5]. 133 In a VPWS service, this is used to provide access AC redundancy to a 134 CE device which is dual-homed to target PE nodes. In a HVPLS service, 135 this is used to provide access PW redundancy to the MTU device which 136 is dual-homed to two PE-r devices. PSN protection mechanisms cannot 137 protect against failure of the target PE node or the failure of the 138 remote AC. These scenarios rely on a set of two or more pseudowires 139 to protect a given PWE3 service. Only one of these pseudowires is 140 used by the PEs to forward user traffic on at any given time. This is 141 the active PW. The other PWs in the set are considered standby and 142 are not used for forwarding unless they become active. In essence, 143 this provides a 1:1 or N:1 PW protection with the possibility of 144 multi-homing. 146 In order to support access AC or access PW redundancy, at least one 147 of the PEs on which a PW terminates must be different from that on 148 which the primary PW terminates, as described in [5]. Figure 1 149 illustrates an application of Active and Standby PWs. 151 |<-------------- Emulated Service ---------------->| 152 | | 153 | |<------- Pseudo Wire ------>| | 154 | | | | 155 | | |<-- PSN Tunnels-->| | | 156 | V V V V | 157 V AC +----+ +----+ AC V 158 +-----+ | | PE1|==================| | | +-----+ 159 | |----------|....|...PW1.(active)...|....|----------| | 160 | | | |==================| | | CE2 | 161 | CE1 | +----+ |PE2 | | | 162 | | +----+ | | +-----+ 163 | | | |==================| | 164 | |----------|....|...PW2.(standby)..| | 165 +-----+ | | PE3|==================| | 166 AC +----+ +----+ 168 Figure 1: Reference Model for PW Redundancy 170 In multi-segment PW (MS-PW) applications, multiple MS-PWs are 171 configured between a pair of T-PE nodes. The paths of these MS-PWs 172 are diverse and are switched at different S-PE nodes. Only one of 173 these MS-PWs is active at any given time. The others are put in 174 standby. In these applications, 1:1 or N:1 PW redundancy is important 175 to provide resilience in the event of failure of S-PE node since PSN 176 protection mechanisms cannot, and the desire is that MS-PW based 177 services have resiliency similar to that of SS-PW based services. 179 This document specifies a new PW status bit to indicate the 180 preferential forwarding status of the PW for the purpose of notifying 181 the remote PE of the active/standby state of each PW in the 182 redundancy set. This status bit is different from the operational 183 status bits already defined in the PWE3 control protocol [2]. In 184 addition, a second status bit is defined to allow peer PE/T-PE nodes 185 to coordinate a switchover operation of the PW/MS-PW path. 187 2. Motivation and Scope 189 The PWE3 control protocol [2] defines the following status codes in 190 PW the status TLV to indicate the operational state for an AC and a 191 PW: 193 0x00000000 - Pseudowire forwarding (clear all failures) 195 0x00000001 - Pseudowire Not Forwarding 197 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 199 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 201 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 203 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 205 The scenarios defined in [5] allow the provisioning of a primary PW 206 and one or many secondary PWs in the same VPWS or VPLS service. 208 A PE node makes a selection of which PW to activate at any given time 209 for the purpose of forwarding user packets. This selection takes into 210 account the local operational state of the PW as well as the remote 211 operational state of the PW as indicated in the status bits of the PW 212 it received from the peer PE node. 214 In the absence of faults, all PWs are operationally UP both locally 215 and remotely and a PE node needs to select a single PW to forward 216 user packets to. This is referred to as the active PW. All other PWs 217 will be in standby and must not be used to forward user packets. 219 In order for both ends of the service to select the same PW for 220 forwarding user packets, it is proposed that a PE node communicates a 221 new status bit to indicate the forwarding state of a PW to its peer 222 PE node. 224 In addition, a second status bit is defined to allow peer PE/T-PE 225 nodes to coordinate a switchover operation of the PW/MS-PW path if 226 required by the application. 228 Together, the mechanisms described in this document achieve the 229 following PW protection capabilities: 231 a. A mandatory 1:1 PW protection with a single active PW and one 232 standby PW. An active PW can forward data traffic and control 233 plane traffic, such as OAM packets. A standby PW does not 234 carry data traffic. 236 b. An optional N:1 PW protection scheme with a single active PW 237 and N standby PWs. 239 c. An independent mode of operation in which each PW endpoint 240 node uses its own local rule to select which PW it intends to 241 activate at any given time and advertises it to the remote 242 endpoints. Only a PW which is operationally UP and which 243 indicated Active status bit locally and remotely is in the 244 Active state and can be used to forward data packets. This is 245 described in Section 4.1. . 247 d. An optional mechanism to allow PW endpoints to coordinate the 248 switchover to a given PW path by using an explicit 249 request/acknowledgment switchover procedure. This mechanism is 250 complementary to the Independent mode of operation and is 251 described in Section 5.3. . This mechanism can be invoked 252 manually by the user, effectively providing a manual 253 switchover capability. It can also be invoked automatically to 254 resolve a situation where the PW endpoints could not match the 255 two directions of the PW. 257 e. A Master/Slave mode in which one PW endpoint, the Master 258 endpoint, selects and dictates to the other endpoint(s), the 259 Slave endpoint(s), which PW to activate. This is described in 260 Section 4.2. . 262 f. Multi-homing of a CE device to two or more PE/T-PE nodes. 264 g. Multi-homing of a PE/T-PE node to two or more PE/T-PE nodes. 266 h. Optionally, implementations can add support for precedence 267 parameter to govern the selection of a PW when more than one 268 PW qualify for the active state, as defined in sections 4.1. 269 and 4.2. The PW with the lowest precedence value has the 270 highest priority. This is a local configuration parameter to 271 the PW endpoint. 273 i. Optionally, implementations can designate by configuration one 274 PW in the 1:1 or N:1 set as a primary PW and the remaining as 275 secondary PWs. If more than one PW qualify for the active 276 state, as defined in sections 4.1. and 4.2. , a PE/T-PE node 277 selects the primary PW in preference to a secondary PW. In 278 other words, the primary PW has implicitly the lowest 279 precedence value. Furthermore, implementations can provide the 280 option to revert to the primary PW immediately after it comes 281 back up or after the expiration of a delay. The PE/T-PE node 282 can use the PW precedence parameter to select a secondary PW 283 among many that qualify for active state. 285 Appendix A shows how the mechanisms described in this document are 286 used to achieve the desired protection behavior for the scenarios 287 described in the PW redundancy and framework document [5]. 289 3. Terminology 291 UP PW: A PW which has been configured (label mapping exchanged 292 between PEs) and is not in any of the PW defect states 293 specified in [2]. Such a PW is available for forwarding 294 traffic. 296 DOWN PW: A PW that has either not been fully configured or has been 297 and is in any of the PW defect states specified in [2]. 298 Such a PW is not available for forwarding traffic. 300 Active PW: An UP PW used for forwarding user and OAM traffic. 302 Standby PW: An UP PW that is not used for forwarding user traffic, 303 but may forward OAM traffic. 305 Primary PW: the PW which a PW endpoint activates in preference to any 306 other PW when more than one PW qualify for active state. 307 When the primary PW comes back up after a failure and 308 qualifies for active state, the PW endpoint always reverts 309 to it. The designation of Primary is performed by local 310 configuration at the PW endpoint. 312 Secondary PW: when it qualifies for active state, a Secondary PW is 313 only selected if no Primary PW is configured or if the 314 configured primary PW does not qualify for active state 315 (e.g., is operationally Down). By default, a PW in a 316 redundancy PW set is considered secondary. There is no 317 Revertive mechanism among secondary PWs. 319 PW Precedence: this is a configuration parameter that dictates the 320 order in which a PW endpoint activates a PW among multiple 321 PWs which qualify for active state. The lowest the 322 precedence value, the highest is the priority of selecting 323 the PW. 325 PW Endpoint: A PE where a PW terminates on an NSP, e.g., A SS-PW PE, 326 an MS-PW T-PE, or a VPLS MTU or PE-r. 328 4. Modes of Operation 330 There are two modes of operation for the use of the PW preferential 331 forwarding status bits: 333 o Independent mode 335 o Master/Slave mode. 337 4.1. Independent Mode: 339 PW endpoint nodes independently select which PW they intend to make 340 active and which PWs they intend to make standby. They advertise the 341 corresponding Active/Standby forwarding state for each PW. Each PW 342 endpoint compares local and remote status and uses the PW that is 343 operationally UP at both endpoints and that shows Active states at 344 both the local and remote endpoint. 346 If more than one PW qualify for the Active state, and the PW endpoint 347 implements the precedence parameter, it must use the PW with the 348 lowest precedence value. The precedence parameter is optional. 350 If more than one PW qualify for the Active state, and the PW endpoint 351 implements the primary/secondary procedures, it must use the primary 352 PW in preference to all secondary PWs. If a primary PW is not 353 available, it must use the secondary PW with the lowest precedence 354 value. If the primary PW becomes available, a PW endpoint may revert 355 to it immediately or after the expiration of a configurable delay. 356 These primary/secondary procedures are optional. 358 In steady state with consistent configuration, a PE will always find 359 an Active PW. However, it is possible that due to a misconfiguration, 360 such a PW is not found. In the event that an active PW is not found, 361 a management indication should be generated. If a management 362 indication for failure to find an active PW was generated and an 363 active PW is subsequently found, a management indication should be 364 generated, effectively clearing the previous failure indication. 365 Additionally, a PE may use the optional request switchover procedures 366 described in Section 5.3. to have both PE nodes switch to a common PW 367 path. 369 There may also be transient conditions where endpoints do not share a 370 common view of the active/standby state of the PWs. This could be 371 caused by propagation delay of the T-LDP status messages between 372 endpoints. In this case, the behavior of the receiving endpoint is 373 outside the scope of this document. 375 Thus, in this mode of operation, the following definition of Active 376 and Standby PW states apply: 378 o Active State 380 A PW is considered to be in Active state when the PW labels are 381 exchanged between its two endpoints in control plane, and the status 382 bits exchanged between the endpoints indicate the PW is UP and Active 383 at both endpoints. In this state user traffic can flow over the PW in 384 both directions. 386 o Standby State 388 A PW is considered to be in Standby state when the PW labels are 389 exchanged between its two endpoints in the control plane, but the 390 status bits exchanged indicate the PW is in Standby state at one or 391 both endpoints. In this state the endpoints MUST NOT forward data 392 traffic over the PW but MAY allow PW OAM packets, e.g., VCCV, to be 393 sent and received in order to test the liveliness of standby PWs. If 394 the PW is a spoke in H-VPLS, any MAC addresses learned via the PW 395 should be flushed when it transitions to Standby state. 397 4.2. Master/Slave Mode: 399 One endpoint node of the redundant set of PWs is designated the 400 Master and is responsible for selecting which PW both endpoints must 401 use to forward user traffic. 403 The Master indicates the forwarding state in the Active/Standby 404 status bit. The other endpoint node, the Slave, MUST follow the 405 decision of the Master node based on the received status bits. 407 One endpoint of the PW, the Master, actively selects which PW to 408 activate and uses it for forwarding user traffic. This status is 409 indicated to the Slave node by setting the preferential forwarding 410 status bit in the status bit TLV to Active. It does not forward user 411 traffic to any other of the PW's in the redundancy set to the slave 412 node and indicates this by setting the preferential forwarding status 413 bit in the status bit TLV to Standby for those PWs. The master node 414 MUST ignore any Active/Standby status bits received from the Slave 415 nodes. 417 If more than one PW qualify for the Active state, and the PW endpoint 418 implements the precedence parameter, it must use the PW with the 419 lowest precedence value. The precedence parameter is optional. 421 If more than one PW qualify for the Active state, and the PW endpoint 422 implements the primary/secondary procedures, it must use the primary 423 PW in preference to all secondary PWs. If a primary PW is not 424 available, it must use the secondary PW with the lowest precedence 425 value. If the primary PW becomes available, a PW endpoint may revert 426 to it immediately or after the expiration of a configurable delay. 427 These primary/secondary procedures are optional. The Slave 428 endpoint(s) are required to act on the status bits received from the 429 Master. When the received status bit transitions from Active to 430 Standby, a Slave node MUST stop forwarding over the previously active 431 PW. When the received status bit transitions from Standby to Active 432 for a given PW, the Slave node MUST start forwarding user traffic 433 over this PW. 435 There is a single PE/T-PE Master PW endpoint node and one or many 436 PE/T-PE PW endpoint Slave nodes. The assignment of Master/Slave roles 437 to the PW endpoints is performed by local configuration. Note that 438 the above behavior assumes correct configuration of the Master and 439 Slave endpoints. This document does not define a mechanism to detect 440 errors in the configuration. 442 In this mode of operation, the following definition of Active and 443 Standby PW states apply: 445 o Active State 447 A PW is considered to be in Active state when the PW labels are 448 exchanged between its two endpoints in control plane, and the status 449 bits exchanged between the endpoints indicate the PW is UP at both 450 endpoints, and the forwarding status sent by the Master endpoint 451 indicates Active state. In this state user traffic can flow over the 452 PW in both directions. 454 o Standby State 455 A PW is considered to be in Standby state when the PW labels are 456 exchanged between its two endpoints in the control plane, but the 457 status bits sent by the Master endpoint indicate the PW is in Standby 458 state. In this state the endpoints MUST NOT forward data traffic over 459 the PW but MAY allow PW OAM packets, e.g., VCCV, to be sent and 460 received. If the PW is a spoke in H-VPLS, any MAC addresses learned 461 via the PW should be flushed when it transitions to Standby state. 463 5. Signaling procedures of PW State Transition 465 This section describes the extensions proposed and the processing 466 rules for the extensions. It defines a new "PW preferential 467 forwarding" bit in Status Code that is to be used with PW Status TLV 468 proposed in RFC 4447 [2]. The PW preferential forwarding bit when set 469 is used to signal Standby state of PW by one terminating point to the 470 other end. 472 5.1. PW Standby notification procedures in Independent mode 474 PW endpoint nodes independently select which PW they intend to use 475 for forwarding, and which PWs they do not, based on the specific 476 application. They advertise the corresponding Active/Standby 477 forwarding state for each PW. An active forwarding state is indicated 478 by clearing the Active/Standby status bit in the PW status TLV. A 479 standby forwarding state is indicated by setting the Active/Standby 480 status bit in the PW status TLV. This advertisement occurs in both 481 the initial label mapping message and in a subsequent notification 482 message when the forwarding state transitions as a result of a state 483 change in the specific application. 485 Each endpoint compares the updated local and remote status and 486 effectively activates the PW which is operationally UP at both 487 endpoints and which shows both local Active and remote Active states. 489 When a PW is in active state, the endpoints can forward both user 490 packets and OAM packets. 492 When a PW is in standby state, the endpoints MUST NOT forward user 493 packets over the PW but MAY forward PW OAM packets. 495 For MS-PWs, S-PEs MUST relay the PW status notification containing 496 both the operational and preferential forwarding status bits between 497 ingress and egress PWs. 499 5.2. PW Standby notification procedures in Master/Slave mode 501 Whenever the Master PW endpoint "actively" selects or deselects a PW 502 for forwarding user traffic at its end, it explicitly notifies the 503 event to the remote Slave endpoint. The slave endpoint carries out 504 the corresponding action on receiving the PW state change 505 notification. 507 If the PW preferential forwarding bit in PW Status TLV received by 508 the slave is set, it indicates that the PW at the Master end is not 509 used for forwarding and is thus kept in the Standby state, the PW 510 MUST also not be used for forwarding at Slave endpoint. Clearance of 511 the PW Preferential Forwarding bit in PW Status TLV indicates that 512 the PW at the Master endpoint is used for forwarding and is in Active 513 state, and the receiving Slave endpoint MUST activate the PW if it 514 was previously not used for forwarding. 516 This mechanism is RECOMMENDED to be used with PWs signaled in groups 517 with common group-id in PWid FEC Element or Grouping TLV in 518 Generalized PWid FEC Element defined in [2]. When PWs are provisioned 519 with such grouping a termination point sends a single "wildcard" 520 Notification message using a PW FEC TLV with only the group ID set, 521 to denote this change in status for all affected PW connections. This 522 status message contains either the PW FEC TLV with only the Group ID 523 set, or else it contains the PW Generalized FEC TLV with only the PW 524 Grouping ID TLV. As mentioned in [2], the Group ID field of the PWid 525 FEC Element, or the PW Grouping TLV used with the Generalized ID FEC 526 Element, can be used to send status notification for all arbitrary 527 set of PWs. For example, Group-ID in PWiD may be used to send 528 wildcard status notification message for a group of PWs when PWid FEC 529 element is used for PW state signaling. When Generalized PWiD FEC 530 Element defined is used in PW state signaling, PW Grouping TLV may be 531 used for wildcard status notification for a group of PWs. 533 For MS-PWs, S-PEs MUST relay the PW status notification containing 534 both the operational and preferential forwarding status bits between 535 ingress and egress PW segments. 537 5.2.1. PW State Machine 539 It is convenient to describe the PW state change behavior in terms of 540 a state machine. The PW state machine is explained in detail in the 541 two defined states and the behavior is presented as a state 542 transition table. The same state machine is seamlessly applicable to 543 PW Groups. 545 PW State Transition State Table 547 STATE EVENT NEW STATE 549 ACTIVE PW put in Standby (master) STANDBY 551 Action: Transmit PW preferential forwarding bit set 553 Receive PW preferential forwarding STANDBY 555 bit set 557 Action: Stop forwarding over PW 559 Receive PW preferential forwarding ACTIVE 561 bit set but bit not supported 563 Action: None 565 Receive PW preferential forwarding ACTIVE 567 bit clear 569 Action: None. 571 STANDBY PW activated (master) ACTIVE 573 Action: Transmit PW preferential forwarding bit 574 clear 575 Receive PW preferential forwarding ACTIVE 577 bit clear 579 Action: Activate PW 581 Receive PW preferential forwarding STANDBY 583 bit clear but bit not supported 585 Action: None 587 Receive PW preferential forwarding STANDBY 589 bit set 591 Action: No action 593 5.3. Coordination of PW Path Switchover 595 There are PW redundancy applications which require that PE/T-PE nodes 596 coordinate the switchover to a PW/MS-PW path such that both endpoints 597 will be forwarding over the same path at any given time. One such 598 application of redundant MS-PW paths is identified in [5]. Multiple 599 MS-PWs are configured between a pair of T-PE nodes. The paths of 600 these MS-PWs are diverse and are switched at different S-PE nodes. 601 Only one of these MS-PWs is active at any given time. The others are 602 put in standby. The endpoints follow the Independent Mode procedures 603 to activate the PW which is UP and advertised Active 'preferential 604 forwarding' status bit by both endpoints. 606 The trigger for sending a request to switchover of the path of the 607 MS-PW by one endpoint can be due to an operational event, example a 608 failure, which caused the endpoints to not be able to match the 609 Active 'preferential forwarding' status bit. The other trigger is the 610 execution of an administrative maintenance operation by the network 611 operator in order to move the traffic away from the node/links to be 612 serviced. 614 Unlike the case of a Master/Slave mode of operation, the endpoint 615 requesting the switchover requires explicit acknowledgement from the 616 peer endpoint that the request is honored before it switches the path 617 of the PW. Furthermore, any of the endpoints can make the request to 618 switchover. 620 A new status bit is proposed to have a PE/T-PE node request the 621 switchover to its peer. This bit will be referred to as 'request PW 622 switchover' status bit. The 'preferential forwarding' status bit 623 continues to be used by each endpoint to indicate its current local 624 settings of the active/standby state of each PW in the redundancy 625 set. In other words, like in the Independent mode, it indicates to 626 the far-end which of the PWs is being used to forward packets and 627 which is being put in standby. It can thus be used as a way for the 628 far-end to acknowledge the requested switchover operation. 630 The following procedures must be followed by both endpoints of a 631 PW/MS-PW to coordinate the switchover of the PW/MS-PW path. These 632 procedures are enabled only when the user configured the use of the 633 'request switchover' status bit at both endpoints. 635 S-PEs nodes MUST relay the PW status notification containing the 636 operational status bits, as well as the 'preferential forwarding' and 637 'request switchover' status bits between ingress and egress PW 638 segments. 640 5.3.1. Procedures at the requesting endpoint 642 a. The requesting endpoint sends a Status TLV in the LDP 643 notification message with the 'request switchover' bit set on the 644 PW it desires to switch to. 646 b. The endpoint does not activate forwarding on that PW/MS-PW at 647 this point in time. It may however enable receiving on that 648 PW/MS-PW. Thus the 'preferential forwarding' status bit still 649 reflects the currently used PW path. 651 c. The requesting endpoint starts a timer while waiting the remote 652 endpoint to acknowledge the request. 654 d. If while waiting for the acknowledgment, the requesting endpoint 655 receives a request from its peer to switchover to the same or a 656 different PW path, it must perform the following: 658 i. If its system IP address is higher than that of the peer, 659 this endpoint ignores the request and continues to wait 660 for the acknowledgement from its peer. 662 ii. If its system IP address is lower than that of its peer, 663 it aborts the timer and immediately starts the 664 procedures of the receiving endpoint in Section 5.3.2. 666 e. If while waiting for the acknowledgment, the requesting 667 endpoint receives a status notification message from its peer 668 with the 'preferential forwarding' status bit cleared in the 669 requested PW and set in all other PWs, it must treat this as an 670 explicit acknowledgment of the request and must perform the 671 following: 673 i. Abort the timer. 675 ii. Activate the PW path. 677 iii. Send an update status notification message with the 678 'preferential forwarding' status bit clear on the newly 679 active PW and set in all other PWs in the redundancy 680 set, and the 'request switchover' bit reset in all PWs 681 in the redundancy set. 683 f. If while waiting for the acknowledgment, the requesting endpoint 684 detects that the requested PW went into operational Down state 685 locally, and could use an alternate PW which is operationally UP, 686 it must perform the following: 688 i. Abort the timer. 690 ii. Issue a new request to switchover to the alternate PW. 692 iii. Re-start the timer. 694 g. If while waiting for the acknowledgment, the requesting endpoint 695 detects that the requested PW went into operational Down state 696 locally, and could not use an alternate PW which is operationally 697 UP, it must perform the following: 699 i. Abort the timer. 701 ii. Send an update status notification message with the 702 'preferential forwarding' status bit unchanged and the 703 'request switchover' bit reset in all PWs in the 704 redundancy set. 706 h. If while waiting for the acknowledgment, the timer expired, the 707 requesting endpoint assumes the request is rejected and will 708 either issue a new request or do nothing. 710 i. If the requesting node receives the acknowledgment after the 711 request expired, it will treat it as if the remote endpoint 712 unilaterally switched the path of the PW without issuing a 713 request. In that case, it may issue a new request and follow the 714 requesting endpoint procedures to synchronize transmit and 715 receive paths of the PW. 717 5.3.2. Procedures at the receiving endpoint 719 a. Upon receiving a status notification message with the 'request 720 switchover' bit set on a PW different from the currently active 721 one, and the requested PW is operationally UP, the receiving 722 endpoint must perform the following: 724 i. Activate the PW. 726 ii. Send an update status notification message with the 727 'preferential forwarding' status bit clear on the newly 728 active PW and set in all other PWs in the redudancy set, 729 and the 'request switchover' bit reset in all PWs in the 730 redundancy set. 732 b. Upon receiving a status notification message with the 'request 733 switchover' bit set on a PW different from the currently active 734 one, and the requested PW is operationally Down, the receiving 735 endpoint must perform the following: 737 i. Ignore the request and do nothing. 739 6. Operational Status Mapping 741 The generation and processing of the PW Status TLV must follow the 742 procedures in RFC 4447 [2]. The PW status TLV is sent on the active 743 PW and standby PWs to make sure the remote AC and remote PW states 744 are always known to the local PE/T-PE node. 746 The generation and processing of PW Status TLV by an S-PE node in a 747 MS-PW must follow the procedures in [4]. 749 The procedures for mapping the operational status between a PW and an 750 AC in a PW service must follow the rules in [7] with the following 751 modifications. 753 6.1. AC Defect State Entry/Exit 755 A PE/T-PE node enters the AC receive (transmit) defect state for a PW 756 service when one or more of the conditions specified for this PW 757 service type in [7] are met. 759 When a PE/T-PE node enters the AC receive (transmit) defect state for 760 a PW service, it must send a forward (reverse) defect indication to 761 the remote peers over all PWs in the redundancy set when required by 762 the PW service type in [7]. 764 When a PE/T-PE node exits the AC receive (transmit) defect state for 765 a PW service, it must clear the forward (reverse) defect indication 766 to the remote peers over all PWs in the redundancy set when required 767 by the PW service type in [7]. 769 6.2. PW Defect State Entry/Exit 771 A PE/T-PE node enters the PW receive (transmit) defect state for a PW 772 service when one or more of the conditions specified in Section 8.2.1 773 (Section 8.2.2) in [7] are met for all PWs in the redundancy set. 775 When a PE/T-PE node enters the PW receive (transmit) defect state for 776 a PW service, it must send a reverse (forward) defect indication over 777 one or more of the PWs in the redundancy set if the PW failure was 778 detected by this PE/T-PE without receiving a forward defect 779 indication from the remote PE [7]. 781 When a PE/T-PE node exits the PW receive (transmit) defect state for 782 a PW service, it must clear the reverse (forward) defect indication 783 over any PW in the redundancy set if applicable. 785 7. Applicability and Backward Compatibility 787 The mechanism defined in this document is OPTIONAL and is applicable 788 to PWE3 applications where standby state signaling of PW or PW group 789 is required. 791 A PE implementation that uses the mechanisms described in this 792 document MUST negotiate the use of PW status TLV between its T-LDP 793 peers as per RFC 4447 [2]. If PW Status TLV is found to be not 794 supported by either of its endpoint after status negotiation 795 procedures, then the mechanisms specified in this document cannot be 796 used. 798 A PE implementation compliant to RFC 4447 [2], and which does not 799 support the generation or processing of the 'preferential forwarding' 800 status bit or of the 'request switchover'status bit, will not set 801 these bits in the status bits transmitted to a peer PE and will not 802 examine them in the received status bits from a peer PE. The 803 mechanisms specified in this document cannot be used. 805 8. Security Considerations 807 This document uses the LDP extensions that are needed for protecting 808 pseudo-wires. It will have the same security properties as in the 809 PWE3 control protocol [2]. 811 9. IANA Considerations 813 We have defined the following codes for the pseudo-wire redundancy 814 application. 816 9.1. Status Code for PW Preferential Forwarding Status 818 0x00000020 When the bit is set, it indicates "PW forwarding 820 standby". 822 When the bit is cleared, it indicates "PW forwarding 824 active". 826 9.2. Status Code for PW Request Switchover Status 828 0x00000040 When the bit is set, it represents "Request switchover to 829 this PW". 831 When the bit is cleared, it represents no specific 832 action. 834 10. Acknowledgments 836 The authors would like to thank Vach Kompella, Kendall Harvey, 837 Tiberiu Grigoriu, John Rigby, Prashanth Ishwar, Neil Hart, Kajal 838 Saha, Florin Balus, Philippe Niger, Dave McDysan, and Roman 839 Krzanowski for their valuable comments and suggestions. 841 11. References 843 11.1. Normative References 845 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 846 Levels", BCP 14, RFC 2119, March 1997. 848 [2] Martini, L., et al., "Pseudowire Setup and Maintenance using 849 LDP", RFC 4447, April 2006. 851 [3] Kompella,V., Lasserrre, M. , et al., "Virtual Private LAN 852 Service (VPLS) Using LDP Signalling", RFC 4762, January 2007. 854 11.2. Informative References 856 [4] Martini, L., et al., "Segmented Pseudo Wire", draft-ietf-pwe3- 857 segmented-pw-13.txt, August 2009. 859 [5] Muley, P., et al., "Pseudowire (PW) Redundancy", draft-ietf- 860 pwe3-redundancy-02.txt", October 2009. 862 [6] Bryant, S., et al., "Pseudo Wire Emulation Edge-to-Edge (PWE3) 863 Architecture", RFC 3985, March 2005 865 [7] Aissaoui, M., et al., "Pseudo Wire (PW) OAM Message Mapping", 866 draft-ietf-pwe3-oam-msg-map-11.txt, June 2009. 868 12. Appendix A - Applications of PW Redundancy Procedures 870 This section shows how the mechanisms described in this document are 871 used to achieve the desired protection behavior for the scenarios 872 described in the PW redundancy requirements and framework document 873 [5]. 875 12.1. One Multi-homed CE with single SS-PW redundancy 877 The following figure illustrates an application of single segment 878 pseudo-wire redundancy. 880 |<-------------- Emulated Service ---------------->| 881 | | 882 | |<------- Pseudo Wire ------>| | 883 | | | | 884 | | |<-- PSN Tunnels-->| | | 885 | V V V V | 886 V AC +----+ +----+ AC V 887 +-----+ | | PE1|==================| | | +-----+ 888 | |----------|....|...PW1.(active)...|....|----------| | 889 | | | |==================| | | CE2 | 890 | CE1 | +----+ |PE2 | | | 891 | | +----+ | | +-----+ 892 | | | |==================| | 893 | |----------|....|...PW2.(standby)..| | 894 +-----+ | | PE3|==================| | 895 AC +----+ +----+ 897 Figure 2 Multi-homed CE with single SS-PW redundancy 899 The application in Figure 2 makes use of the Independent mode of 900 operation. 902 CE1 is dual homed to PE1 and to PE3 by attachment circuits. The 903 method for dual-homing of CE1 to PE1 and to PE3 nodes, and the used 904 protocols such as Multi-chassis Link Aggregation Group (MC-LAG), is 905 outside the scope of this document. 907 In normal operation, PE1 and PE3 will advertise "Active" and 908 "Standby" 'preferential forwarding' status bit respectively to PE2. 909 This status reflects the forwarding state of the two AC's to CE1 as 910 determined by the AC dual-homing protocol used. PE2 advertises 911 'preferential forwarding' status bit of "Active" on both PW1 and PW2 912 since the AC to CE2 is single homed. As both the local and remote 913 operational and preferential forwarding status for PW1 are UP and 914 Active, traffic is forwarded over PW1 in both directions. 916 On failure of the AC between CE1 and PE1, the forwarding state of the 917 AC on PE3 transitions to Active. For example the MC-LAG control 918 protocol changes the link state on PE3 to active. PE3 then announces 919 the newly changed 'preferential forwarding' status bit of "active" to 920 PE2. PE1 will advertise a PW status notification message indicating 921 that the AC between CE1 and PE1 is operationally down. PE2 matches 922 the local and remote preferential forwarding status of "active" and 923 operational status "Up" and select PW2 as the new active pseudo-wire 924 to send traffic to. 926 On failure of PE1 node, PE3 will detect it and will transition the 927 forwarding state of its AC to Active. The method by which PE3 detects 928 that PE1 is down is outside the scope of this document. PE3 then 929 announces the newly changed 'preferential forwarding' status bit of 930 "active" to PE2. PE3 and PE2 match the local and remote preferential 931 forwarding status of "active" and operational status "Up" and select 932 PW2 as the new active pseudo-wire to send traffic to. Note that PE2 933 may have detected that the PW to PE1 went down via T-LDP Hello 934 timeout or via other means. However, it will not be able to forward 935 user traffic until it received the updated status bit from PE3. 937 Note in this example, the receipt of the operational status of the AC 938 on the CE1-PE1 link is normally sufficient to have PE2 switch the 939 path to PW2. However, the operator may want to trigger the switchover 940 of the path of the PW for administrative reasons, i.e., maintenance, 941 and thus the use of the 'preferential forwarding' status bit is 942 required to notify PE2 to trigger the switchover. 944 Note that the primary/secondary procedures do not apply in this case 945 as the PW Active/Standby status is driven by the AC forwarding state 946 as determined by the AC dual-homing protocol used. 948 12.2. Multiple Multi-homed CEs with single SS-PW redundancy 950 |<-------------- Emulated Service ---------------->| 951 | | 952 | |<------- Pseudo Wire ------>| | 953 | | | | 954 | | |<-- PSN Tunnels-->| | | 955 | V V V V | 956 V AC +----+ +----+ AC V 957 +-----+ | |....|.......PW1........|....| | +-----+ 958 | |----------| PE1|...... .........| PE3|----------| | 959 | CE1 | +----+ \ / PW3 +----+ | CE2 | 960 | | +----+ X +----+ | | 961 | | | |....../ \..PW4....| | | | 962 | |----------| PE2| | PE4|--------- | | 963 +-----+ | |....|.....PW2..........|....| | +-----+ 964 AC +----+ +----+ AC 966 Figure 3 Multiple Multi-homed CEs with single SS-PW redundancy 968 The application in Figure 3 makes use of the Independent mode of 969 operation. 971 CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed PE3 and PE4. The 972 method for dual-homing and the used protocols such as Multi-chassis 973 Link Aggregation Group (MC-LAG) are outside the scope of this 974 document. Note that the PSN tunnels are not shown in this figure for 975 clarity. However, it can be assumed that each of the PWs shown is 976 encapsulated in a separate PSN tunnel. 978 PE1 advertises the preferential status "active" and operational 979 status "UP" for pseudo-wires PW1 and PW4 connected to PE3 and PE4. 980 This status reflects the forwarding state of the AC attached to PE1. 981 PE2 advertises preferential status "standby" where as operational 982 status "UP" for pseudo-wires PW2 and PW3 to PE3 and PE4. PE3 983 advertises preferential status "standby" where as operational status 984 "UP" for pseudo-wires PW1 and PW3 to PE1 and PE2. PE4 advertise the 985 preferential status "active" and operational status "UP" for pseudo- 986 wires PW2 and PW4 to PE2 and PE1 respectively. The method of 987 deriving Active/Standby status of the AC is outside the scope of 988 this document. In case of MC-LAG it is derived by the Link 989 Aggregation Control protocol (LACP) negotiation. Thus by matching 990 the local and remote preferential forwarding status of "active" and 991 operational status "Up" of pseudo-wire, the PE nodes determine which 992 PW should be in the Active state. In this case it is PW4 that will 993 be selected. 995 On failure of the AC between CE1 and PE1, the forwarding state of 996 the AC on PE2 is changed to Active. For example the MC-LAG control 997 protocol changes the link state on PE2 to active. PE2 then announces 998 the newly changed 'preferential forwarding' status bit of "active" 999 to PE3 and PE4. PE1 will advertise a PW status notification message 1000 indicating that the AC between CE1 and PE1 is operationally down. 1001 PE2 and PE4 match the local and remote preferential forwarding 1002 status of "active" and operational status "Up" and select PW2 as the 1003 new active pseudo-wire to send traffic to. 1005 On failure of PE1 node, PE2 will detect it and will transition the 1006 forwarding state of its AC to Active. The method by which PE2 1007 detects that PE1 is down is outside the scope of this document. PE2 1008 then announces the newly changed 'preferential forwarding' status 1009 bit of "active" to PE3 and PE4. PE2 and PE4 match the local and 1010 remote preferential forwarding status of "active" and operational 1011 status "Up" and select PW2 as the new active pseudo-wire to send 1012 traffic to. Note that PE3 and PE4 may have detected that the PW to 1013 PE1 went down via T-LDP Hello timeout or via other means. However, 1014 they will not be able to forward user traffic until they received 1015 the updated status bit from PE2. 1017 Because each dual-homing algorithm running on the two node sets, 1018 i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects the active AC 1019 independently, there is a need to signal the active status of the AC 1020 such that the PE nodes can select a common active PW path for end-to- 1021 end forwarding between CE1 and CE2 as per the procedures in the 1022 independent mode. 1024 Note that the primary/secondary procedures do not apply in this use 1025 case as the Active/Standby status is driven by the AC forwarding 1026 state as determined by the AC dual-homing protocol used. 1028 12.3. Multi-homed CE with MS-PW redundancy 1030 The following figure illustrates an application of multi-segment 1031 pseudo-wire redundancy. 1033 Native |<-----------Pseudo Wire----------->| Native 1034 Service | | Service 1035 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 1036 | V V V V V V | 1037 | +-----+ +-----+ +-----+ 1038 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 1039 | |-------|......PW1-Seg1.......|PW1-Seg2.......|-------| | 1040 | | | |=========| |=========| | | | 1041 | CE1| +-----+ +-----+ +-----+ | | 1042 | | |.| +-----+ +-----+ | CE2| 1043 | | |.|===========| |=========| | | | 1044 | | |.....PW2-Seg1......|.PW2-Seg2......|-------| | 1045 +----+ |=============|S-PE2|=========|T-PE4| | +----+ 1046 +-----+ +-----+ AC 1048 Figure 4 Multi-homed CE with MS-PW redundancy 1050 The application in Figure 4 makes use of the Independent mode of 1051 operation. 1053 CE2 is dual-homed to T-PE2 and T-PE4. PW1 and PW2 are used to extend 1054 the resilient connectivity all the way to T-PE1. PW1 has two segments 1055 and is active pseudo-wire while PW2 has two segments and is a standby 1056 pseudo-wire. This application requires support for MS-PW with 1057 segments of the same type as described in [4]. 1059 The operation in this case is the same as in the case of SS-PW as 1060 described in Section 12.1. . The only difference is that the S-PE 1061 nodes need to relay the PW status notification containing both the 1062 operational and forwarding status to the T-PE nodes. 1064 12.4. Single Homed CE with MS-PW redundancy 1066 The following is an application of the independent mode of operation 1067 along with the optional request switchover procedures in order to 1068 provide N:1 PW protection. A revertive behavior to a primary PW is 1069 shown as an example of configuring and using the primary/secondary 1070 procedures. 1072 Native |<------------Pseudo Wire------------>| Native 1073 Service | | Service 1074 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 1075 | V V V V V V | 1076 | +-----+ +-----+ +-----+ | 1077 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 1078 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 1079 | CE1| | |=========| |=========| | | CE2| 1080 | | +-----+ +-----+ +-----+ | | 1081 +----+ |.||.| |.||.| +----+ 1082 |.||.| +-----+ |.||.| 1083 |.||.|=========| |========== .||.| 1084 |.||...PW2-Seg1......|.PW2-Seg2...||.| 1085 |.| ===========|S-PE2|============ |.| 1086 |.| +-----+ |.| 1087 |.|============+-----+============= .| 1088 |.....PW3-Seg1.| | PW3-Seg2......| 1089 ==============|S-PE3|=============== 1090 | | 1091 +-----+ 1093 Figure 5 Single homed CE with multi-segment pseudo-wire redundancy 1095 CE1 is connected to PE1 in provider Edge 1 and CE2 to PE2 in provider 1096 edge 2 respectively. There are three segmented PWs. A primary PW, 1097 PW1, is switched at S-PE1. A primary PW has the highest precedence. A 1098 secondary PW, PW2, which is switched at S-PE2 and has a precedence of 1099 1. Finally, another secondary PW, PW3, is switched at S-PE3 and has a 1100 precedence of 2. The precedence is locally configured at the 1101 endpoints of the PW, i.e., T-PE1 and T-PE2. 1103 T-PE1 and T-PE2 will select the PW they intend to activate based on 1104 their local and remote operational state as well as the local 1105 primary/precedence configuration. In this case, they will both 1106 advertise preferential forwarding' status bit of "active" on PW1 and 1107 of "standby" on PW2 and PW3. Assuming all PWs are operationally UP, 1108 T-PE1 and T-PE2 will use PW1 to forward user packets. 1110 If PW1 fails, then the T-PE detecting the failure will send a status 1111 notification to the remote T-PE with a "PW Down" bit set as well as 1112 the 'preferential forwarding' status bit set on PW1. It will also 1113 clear 'preferential forwarding' status bit on PW2 as it is the next 1114 it has the next lowest precedence value. T-PE2 will also perform the 1115 same steps as soon as it is informed of the failure of PW1. Both T-PE 1116 nodes will perform a match on the 'preferential forwarding' status 1117 of "active" and operational status of "Up" and will use PW2 to 1118 forward user packets. 1120 However this does not guarantee that paths of the PW are synchronized 1121 at all times. This may be due to a mismatch of the configuration of 1122 the PW priority in each T-PE. This may also be due to a failure which 1123 caused the endpoints to not be able to match the Active 'preferential 1124 forwarding' status bit and operational status bits. In this case, T- 1125 PE1 and/or T-PE2 can invoke the optional request 1126 switchover/acknowledgement procedures to synchronize the PW paths in 1127 both directions. 1129 The trigger for sending a request to switchover can also be the 1130 execution of an administrative maintenance operation by the network 1131 operator in order to move the traffic away from the T-PE/S-PE nodes 1132 /links to be serviced. 1134 In case the request switchover is sent by both endpoints 1135 simultaneously, both T-PEs send status notification with the newly 1136 selected PW with 'request switchover' bit set, waiting for response 1137 from the other endpoint. In such situation, the T-PE with greater 1138 system address request is given precedence. This helps in 1139 synchronizing paths in event of mismatch of priority configuration as 1140 well. 1142 12.5. PW redundancy between H-VPLS MTU-s and PE-rs 1144 Following figure illustrates the application of use of PW redundancy 1145 in H-VPLS for the purpose of dual-homing an MTU-s node to PE nodes 1146 using PW spokes. This application makes use of the Master/Slave mode 1147 of operation. 1149 |<-PSN1-->| |<-PSN2-->| 1150 V V V V 1151 +-----+ +--------+ 1152 |MTU-s|=========|PE1-rs |======== 1153 |..Active PW group.... | H-VPLS-core 1154 | |=========| |========= 1155 +-----+ +--------+ 1156 |.| 1157 |.| +--------+ 1158 |.|===========| |========== 1159 |...Standby PW group |.H-VPLS-core 1160 =============| PE2-rs|========== 1161 +--------+ 1163 Figure 6 Multi-homed MTU-s in H-VPLS core 1165 MTU-s is dual homed to PE1-rs and PE2-rs. The primary spoke PWs from 1166 MTU-s are connected to PE1-rs while the secondary PWs are connected 1167 to PE2. PE1-rs and PE2-rs are connected to H-VPLS core on the other 1168 side of network. MTU-s communicates to PE1-rs and PE2-rs the 1169 forwarding status of its member PWs for a set of VSIs having common 1170 status Active/Standby. It may be signaled using PW grouping with 1171 common group-id in PWid FEC Element or Grouping TLV in Generalized 1172 PWid FEC Element as defined in [2] to scale better. MTU-s derives 1173 the status of the PWs based on local policy configuration. In this 1174 example, the primary/secondary procedures are used but this can be 1175 based on any other policy. 1177 Whenever MTU-s performs a switchover, it sends a wildcard 1178 Notification Message to PE2-rs for the Standby PW group containing PW 1179 Status TLV with PW Standby bit cleared. On receiving the notification 1180 PE-2rs unblocks all member PWs identified by the PW group and state 1181 of PW group changes from Standby to Active. All procedures described 1182 in Section 5.2. are applicable. 1184 The use of the 'preferential forwarding' status bit in Master/Slave 1185 mode is similar to Topology Change Notification in RSTP controlled 1186 IEEE Ethernet Bridges but is restricted over a single hop. When these 1187 procedures are implemented, PE-rs devices are aware of switchovers at 1188 MTU-s and could generate MAC Withdraw Messages to trigger MAC 1189 flushing within the H-VPLS full mesh. By default, MTU-s devices 1190 should still trigger MAC Withdraw messages as currently defined in 1191 [6] to prevent two copies of MAC withdraws to be sent, one by MTU-s 1192 and another one by PE-rs nodes. Mechanisms to disable MAC Withdraw 1193 trigger in certain devices is out of the scope of this document 1195 Author's Addresses 1197 Praveen Muley 1198 Alcatel-lucent 1199 701 E. Middlefiled Road 1200 Mountain View, CA, USA 1201 Email: Praveen.muley@alcatel-lucent.com 1203 Mustapha Aissaoui 1204 Alcatel-lucent 1205 600 March Rd 1206 Kanata, ON, Canada K2K 2E6 1207 Email: mustapha.aissaoui@alcatel-lucent.com 1209 Matthew Bocci 1210 Alcatel-Lucent 1211 Voyager Place, Shoppenhangers Rd 1212 Maidenhead, Berks, UK SL6 2PJ 1213 Email: matthew.bocci@alcatel-lucent.co.uk 1215 Pranjal Kumar Dutta 1216 Alcatel-Lucent 1217 Email: pdutta@alcatel-lucent.com 1219 Marc Lasserre 1220 Alcatel-Lucent 1221 Email: mlasserre@alcatel-lucent.com 1223 Jonathan Newton 1224 Cable & Wireless 1225 Email: Jonathan.Newton@cw.com 1227 Olen Stokes 1228 Extreme Networks 1229 Email: ostokes@extremenetworks.com 1231 Hamid Ould-Brahim 1232 Nortel 1233 Email: hbrahim@nortel.com 1235 Luca Martini 1236 Cisco Systems, Inc. 1237 9155 East Nichols Avenue, Suite 400 1238 Englewood, CO, 80112 1239 Email: lmartini@cisco.com 1241 Thomas Nadeau 1242 BT 1243 tom.nadeau@bt.com 1245 Giles Heron 1246 BT 1247 giles.heron@gmail.com