idnits 2.17.1 draft-ietf-pwe3-redundancy-bit-03.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 2 instances of too long lines in the document, the longest one being 17 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 835 has weird spacing: '...t or of the '...' == Line 1063 has weird spacing: '... switch to PW...' -- 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 (May 14, 2010) is 5096 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 (-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 == Outdated reference: A later version (-13) exists of draft-ietf-l2vpn-vpls-ldp-mac-opt-00 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Praveen Muley, Ed. 2 Internet Draft Mustapha Aissaoui, Ed. 3 Updates: RFC5542 (if approved) Alcatel-Lucent 4 Intended Status: Standards Track 5 Expires: November 14, 2010 7 May 14, 2010 9 Pseudowire Preferential Forwarding Status Bit 10 draft-ietf-pwe3-redundancy-bit-03.txt 12 Abstract 14 This document describes a mechanism for standby status signaling of 15 redundant pseudowires (PWs) between their termination points. A set 16 of redundant PWs is configured between provider edge (PE) nodes in 17 single-segment pseudowire (SS-PW) applications, or between 18 terminating provider edge (T-PE) nodes in multi-segment pseudowire 19 (MS-PW) applications. 21 In order for the PE/T-PE nodes to indicate the preferred PW to use 22 for forwarding PW packets to one another, a new status bit is needed 23 to indicate a preferential forwarding status of active or standby for 24 each PW in a redundant set. 26 In addition, a second status bit is defined to allow peer PE nodes to 27 coordinate a switchover operation of the PW. 29 Status of this Memo 31 This Internet-Draft is submitted 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). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on November 14, 2010. 46 Copyright Notice 47 Copyright (c) 2010 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:......................................10 75 6. PW State Transition Signaling Procedures.....................12 76 6.1. PW Standby Notification Procedures in Independent mode..12 77 6.2. PW Standby notification procedures in Master/Slave mode.12 78 6.2.1. PW State Machine...................................13 79 6.3. Coordination of PW Switchover...........................14 80 6.3.1. Procedures at the requesting endpoint..............16 81 6.3.2. Procedures at the receiving endpoint...............17 82 7. Operational Status Mapping...................................18 83 7.1. AC Defect State Entry/Exit..............................18 84 7.2. PW Defect State Entry/Exit..............................18 85 8. Applicability and Backward Compatibility.....................19 86 9. Security Considerations......................................19 87 10. MIB Considerations..........................................19 88 11. IANA Considerations.........................................20 89 11.1. Status Code for PW Preferential Forwarding Status......20 90 11.2. Status Code for PW Request Switchover Status...........21 91 12. Major Contributing Authors..................................21 92 13. Acknowledgments.............................................22 93 14. References..................................................22 94 14.1. Normative References...................................22 95 14.2. Informative References.................................22 96 15. Appendix A - Applications of PW Redundancy Procedures.......23 97 15.1. One Multi-homed CE with single SS-PW redundancy........23 98 15.2. Multiple Multi-homed CEs with single SS-PW redundancy..25 99 15.3. Multi-homed CE with MS-PW redundancy...................26 100 15.4. Single Homed CE with MS-PW redundancy..................28 101 15.5. PW redundancy between H-VPLS MTU-s and PE-rs...........29 102 Author's Addresses..............................................31 104 1. Introduction 106 In Virtual Private Wire Services (VPWS) or Virtual Private Local Area 107 network Services (VPLS) that use SS-PWs, protection for the PW is 108 provided by the packet switched network (PSN) layer. This may be a 109 Resource Reservation Protocol with Traffic Engineering (RSVP-TE) 110 label switched path (LSP) with a fast reroute (FRR) backup or an end- 111 to-end backup LSP. There are, however, applications where PSN 112 protection is insufficient to fully protect the PW-based service. 113 These include the following: 115 In a VPWS service where the Customer Edge (CE) node is dual homed to 116 a pair of PE nodes, PW redundancy mechanisms are required to ensure 117 that the correct PW is used for forwarding when attachment circuit 118 (AC) redundancy is used. PW redundancy mechanisms are also required 119 when multiple redundant MS-PWs are used between T-PEs, to ensure that 120 both T-PEs use the same MS-PW to forward to one another. 122 In a hierarchical VPLS (H-VPLS) service, PW redundancy mechanisms are 123 required to enable a multi-tenant unit switch (MTU-s) to be dual- 124 homed to two PE-rs devices. 126 In these cases, pseudowire redundancy mechanisms are required. These 127 scenarios are described in the PW redundancy and framework document 128 [5]. 130 Scenarios, such as those above, therefore rely on a set of two or 131 more pseudowires to protect a given VPWS or VPLS . Only one of these 132 pseudowires is used by the PEs to forward user traffic on at any 133 given time. This is the active PW. The other PWs in the set are 134 considered standby and are not used for forwarding unless they become 135 active. This provides a 1:1 or N:1 PW protection with the possibility 136 of multi-homing between the CE and the PEs. 138 In order to support AC or spoke PW redundancy, at least one of the 139 PEs on which a PW terminates must be different from that on which the 140 primary PW terminates, as described in [5]. Figure 1-1 illustrates an 141 application of Active and Standby PWs. 143 |<-------------- Emulated Service ---------------->| 144 | | 145 | |<------- Pseudowire ------->| | 146 | | | | 147 | | |<-- PSN Tunnels-->| | | 148 | V V V V | 149 V AC +----+ +----+ AC V 150 +-----+ | | PE1|==================| | | +-----+ 151 | |----------|....|...PW1.(active)...|....|----------| | 152 | | | |==================| | | CE2 | 153 | CE1 | +----+ |PE2 | | | 154 | | +----+ | | +-----+ 155 | | | |==================| | 156 | |----------|....|...PW2.(standby)..| | 157 +-----+ | | PE3|==================| | 158 AC +----+ +----+ 160 Figure 1-1: Reference Model for PW Redundancy 162 In MS-PW applications, PW redundancy is also required to protect the 163 service against failures of the switching PEs, which cannot be 164 protected by PSN mechanisms. In addition, PW redundancy is also 165 required if CEs are dual-homed to the PEs, as described above. In 166 this case, multiple MS-PWs are configured between a pair of T-PE 167 nodes, as described in Figure 2 of [5]. The paths of these MS-PWs are 168 diverse in that they are switched at different S-PE nodes. Only one 169 of these MS-PWs is active at any given time, while the others are 170 standby. 172 This document specifies a new PW status bit to indicate the 173 preferential forwarding status of the PW for the purpose of notifying 174 the remote PE of the preferential forwarding state of each PW in the 175 redundancy set i.e. active or standby. This status bit is different 176 from the operational status bits already defined in the PWE3 control 177 protocol [2]. In addition, a second status bit is defined to allow 178 peer PE nodes to coordinate a switchover operation of the PW from 179 active to standby, or vice versa. 181 2. Motivation and Scope 183 The PWE3 control protocol [2] defines the following status codes in 184 PW the status TLV to indicate the operational state for an AC and a 185 PW: 187 0x00000000 - Pseudowire forwarding (clear all failures) 189 0x00000001 - Pseudowire Not Forwarding 191 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 193 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 195 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 197 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 199 The scenarios defined in [5] allow the provisioning of a primary PW 200 and one or many secondary PWs in the same VPWS or VPLS service. 202 A PE node makes a selection of which PW to activate at any given time 203 for the purpose of forwarding user packets. This selection takes into 204 account the local operational state of the PW as well as the remote 205 operational state of the PW as indicated in the status bits of the PW 206 it received from the peer PE node. 208 In the absence of faults, all PWs are operationally UP both locally 209 and remotely and a PE node needs to select a single PW to forward 210 user packets to. This is referred to as the active PW. All other PWs 211 will be in standby and must not be used to forward user packets. 213 In order for both ends of the service to select the same PW for 214 forwarding user packets, this document defines a new status bit, the 215 'preferential forwarding' status bit, to allow a PE node to indicate 216 the preferential forwarding state of a PW to its peer PE node. 218 In addition, a second status bit is defined to allow peer PE nodes to 219 coordinate a switchover operation of the PW if required by the 220 application. This is known as the 'request switchover' status bit. 222 Together, the mechanisms described in this document achieve the 223 following PW protection capabilities: 225 a. A MANDATORY 1:1 PW protection with a single active PW and one 226 standby PW. An active PW can forward data traffic and control 227 plane traffic, such as OAM packets. A standby PW does not 228 carry data traffic. 230 b. An OPTIONAL N:1 PW protection scheme with a single active PW 231 and N standby PWs. 233 c. An OPTIONAL mechanism to allow PW endpoints to coordinate the 234 switchover to a given PW by using an explicit 235 request/acknowledgment switchover procedure. This mechanism is 236 complementary to the Independent mode of operation and is 237 described in Section 6.3. . This mechanism can be invoked 238 manually by the user, effectively providing a manual 239 switchover capability. It can also be invoked automatically to 240 resolve a situation where the PW endpoints could not match the 241 two directions of the PW. 243 d. An OPTIONAL, locally configured precedence to govern the 244 selection of a PW when more than one PW qualify for the active 245 state, as defined in sections 5.1. and 5.2. The PW with the 246 lowest precedence value has the highest priority. Precedence 247 may be configured via, for example, a local configuration 248 parameter at the PW endpoint. 250 e. OPTIONALLY, implementations can designate by configuration one 251 PW in the 1:1 or N:1 set as a primary PW and the remaining as 252 secondary PWs. If more than one PW qualify for the active 253 state, as defined in sections 5.1. and 5.2. , a PE node 254 selects the primary PW in preference to a secondary PW. In 255 other words, the primary PW has implicitly the lowest 256 precedence value. Furthermore, a PE node reverts to the 257 primary PW immediately after it comes back up or after the 258 expiration of a delay. The PE node can use the PW precedence 259 to select a secondary PW among many that qualify for active 260 state. 262 These protection schemes are provided using the following operational 263 modes: 265 1. An independent mode of operation in which each PW endpoint 266 node uses its own local rule to select which PW it intends 267 to activate at any given time and advertises it to the 268 remote endpoints. Only a PW which is operationally UP and 269 which indicated Active status bit locally and remotely is 270 in the Active state and can be used to forward data 271 packets. This is described in Section 5.1. 273 2. A Master/Slave mode in which one PW endpoint, the Master 274 endpoint, selects and dictates to the other endpoint(s), 275 the Slave endpoint(s), which PW to activate. This is 276 described in Section 5.2. 278 The above mechanisms and operational modes allow the following: 280 a.Multi-homing of a CE device to two or more PE nodes. 282 b.Multi-homing of a PE node to two or more PE nodes. 284 More details of how these schemes are used can be found in 285 Informative Appendix A. 287 Note that this document specifies the mechanisms to support PW 288 redundancy where a set of redundant PWs terminate on either a PE (for 289 SS-PW) or a T-PE (for MS-PW). PW redundancy scenarios where the 290 redundant set of PW segments terminate on an S-PE are for further 291 study. 293 3. Terminology 295 UP PW: A PW which has been configured (label mapping exchanged 296 between PEs) and is not in any of the PW defect states 297 specified in [2]. Such a PW is available for forwarding 298 traffic. 300 DOWN PW: A PW that has either not been fully configured, or has been 301 configured and is in any of the PW defect states specified 302 in [2], such a PW is not available for forwarding traffic. 304 Active PW: An UP PW used for forwarding user and OAM traffic. 306 Standby PW: An UP PW that is not used for forwarding user traffic, 307 but may forward OAM traffic. 309 Primary PW: the PW which a PW endpoint activates in preference to any 310 other PW when more than one PW qualify for active state. 311 When the primary PW comes back up after a failure and 312 qualifies for active state, the PW endpoint always reverts 313 to it. The designation of Primary is performed by local 314 configuration for the PW at the PE. 316 Secondary PW: when it qualifies for active state, a Secondary PW is 317 only selected if no Primary PW is configured or if the 318 configured primary PW does not qualify for active state 319 (e.g., is DOWN). By default, a PW in a redundancy PW set is 320 considered secondary. There is no Revertive mechanism among 321 secondary PWs. 323 PW Precedence: this is a configuration local to the PE that dictates 324 the order in which a forwarder chooses to use a PW when 325 multiple PWs all qualify for the active state. Note that a 326 PW which has been configured as Primary has implicitly the 327 lowest precedence value. 329 PW Endpoint: A PE where a PW terminates on a point where Native 330 Service Processing is performed, e.g., A SS-PW PE, an MS-PW 331 T-PE, or an H-VPLS MTU-s or PE-rs. 333 This document uses the term 'PE' to be synonymous with both PEs as 334 per RFC3985 and T-PEs as per RFC5659. 336 This document uses the term 'PW' to be synonymous with both PWs as 337 per RFC3985 and SS-PWs and MS-PWs as per RFC5659. 339 4. PE Architecture 341 Figure 4-1 shows the PE architecture for PW redundancy, when more 342 than one PW in a redundant set is associated with a single AC. This 343 is based on the architecture in Figure 4b of RFC3985 [6]. The 344 forwarder selects which of the redundant PWs to using the criteria 345 described in this document. 347 +----------------------------------------+ 348 | PE Device | 349 +----------------------------------------+ 350 Single | | Single | PW Instance 351 AC | + PW Instance X<===========> 352 | | | 353 | |----------------------| 354 <------>o | Single | PW Instance 355 | Forwarder + PW Instance X<===========> 356 | | | 357 | |----------------------| 358 | | Single | PW Instance 359 | + PW Instance X<===========> 360 | | | 361 +----------------------------------------+ 363 Figure 4-1 PE Architecure for PW redundancy 365 5. Modes of Operation 367 There are two modes of operation for the use of the PW preferential 368 forwarding status bits: 370 o Independent mode 372 o Master/Slave mode. 374 5.1. Independent Mode: 376 PW endpoint nodes independently select which PW they intend to make 377 active and which PWs they intend to make standby. They advertise the 378 corresponding Active/Standby forwarding state for each PW. Each PW 379 endpoint compares local and remote status and uses the PW that is 380 operationally UP at both endpoints and that shows Active states at 381 both the local and remote endpoint. 383 If more than one PW qualify for the Active state, each PW endpoint 384 MUST implement a common mechanism to choose the PW for forwarding. If 385 this mechanism uses a precedence value for the PW, it must use the PW 386 with the lowest configured precedence value. The precedence parameter 387 is optional. 389 If more than one PW qualify for the Active state, and the PW endpoint 390 is configured with one PW as primary, it must use the primary PW in 391 preference to all secondary PWs. If a primary PW is not available, it 392 must use the secondary PW with the lowest precedence value. If the 393 primary PW becomes available, a PW endpoint must revert to it 394 immediately or after the expiration of a configurable delay. These 395 primary/secondary procedures are optional. 397 In steady state with consistent configuration, a PE will always find 398 an Active PW. However, it is possible that due to a misconfiguration, 399 such a PW is not found. In the event that an active PW is not found, 400 a management indication SHOULD be generated. If a management 401 indication for failure to find an active PW was generated and an 402 active PW is subsequently found, a management indication should be 403 generated, so clearing the previous failure indication. Additionally, 404 a PE may use the optional request switchover procedures described in 405 Section 6.3. to have both PE nodes switch to a common PW. 407 There may also be transient conditions where endpoints do not share a 408 common view of the active/standby state of the PWs. This could be 409 caused by propagation delay of the T-LDP status messages between 410 endpoints. In this case, the behavior of the receiving endpoint is 411 outside the scope of this document. 413 Thus, in this mode of operation, the following definition of Active 414 and Standby PW states apply: 416 o Active State 418 A PW is considered to be in Active state when the PW labels are 419 exchanged between its two endpoints, and the status bits exchanged 420 between the endpoints indicate the PW is UP and Active at both 421 endpoints. In this state user traffic can flow over the PW in both 422 directions. 424 o Standby State 426 A PW is considered to be in Standby state when the PW labels are 427 exchanged between its two endpoints, but the status bits exchanged 428 indicate the PW is in Standby state at one or both endpoints. In this 429 state the endpoints MUST NOT forward data traffic over the PW but MAY 430 allow PW OAM packets, e.g., VCCV, to be sent and received in order to 431 test the liveliness of standby PWs. If the PW is a spoke in H-VPLS, 432 any MAC addresses learned via the PW SHOULD be flushed when it 433 transitions to Standby state according to the procedures in RFC4762 434 [3] and [9]. 436 5.2. Master/Slave Mode: 438 One endpoint node of the redundant set of PWs is designated the 439 Master and is responsible for selecting which PW both endpoints must 440 use to forward user traffic. 442 The Master indicates the forwarding state in the Active/Standby 443 status bit. The other endpoint node, the Slave, MUST follow the 444 decision of the Master node based on the received status bits. 446 One endpoint of the PW, the Master, actively selects which PW to 447 activate and uses it for forwarding user traffic. This status is 448 indicated to the Slave node by setting the preferential forwarding 449 status bit in the status bit TLV to Active. It does not forward user 450 traffic to any other of the PW's in the redundancy set to the slave 451 node and indicates this by setting the preferential forwarding status 452 bit in the status bit TLV to Standby for those PWs. The master node 453 MUST ignore any Active/Standby status bits received from the Slave 454 nodes. 456 If more than one PW qualify for the Active state, each PW endpoint 457 MUST implement a common mechanism to choose the PW for forwarding. If 458 this mechanism uses a precedence value for the PW, it must use the PW 459 with the lowest configured precedence value. The precedence parameter 460 is optional. 462 If more than one PW qualify for the Active state, and the PW endpoint 463 is configured with one PW as primary, it must use the primary PW in 464 preference to all secondary PWs. If a primary PW is not available, it 465 must use the secondary PW with the lowest precedence value. If the 466 primary PW becomes available, a PW endpoint must revert to it 467 immediately or after the expiration of a configurable delay. These 468 primary/secondary procedures are optional. 470 The Slave endpoint(s) are required to act on the status bits received 471 from the Master. When the received status bit transitions from Active 472 to Standby, a Slave node MUST stop forwarding over the previously 473 active PW. When the received status bit transitions from Standby to 474 Active for a given PW, the Slave node MUST start forwarding user 475 traffic over this PW. 477 There is a single PE Master PW endpoint node and one or many PE PW 478 endpoint Slave nodes. The assignment of Master/Slave roles to the PW 479 endpoints is performed by local configuration. Note that the above 480 behavior assumes correct configuration of the Master and Slave 481 endpoints. This document does not define a mechanism to detect errors 482 in the configuration. 484 In this mode of operation, the following definition of Active and 485 Standby PW states apply: 487 o Active State 489 A PW is considered to be in Active state when the PW labels are 490 exchanged between its two endpoints, and the status bits exchanged 491 between the endpoints indicate the PW is UP at both endpoints, and 492 the forwarding status sent by the Master endpoint indicates Active 493 state. In this state user traffic can flow over the PW in both 494 directions. 496 o Standby State 498 A PW is considered to be in Standby state when the PW labels are 499 exchanged between its two endpoints, but the status bits sent by the 500 Master endpoint indicate the PW is in Standby state. In this state 501 the endpoints MUST NOT forward data traffic over the PW but MAY allow 502 PW OAM packets, e.g., VCCV, to be sent and received. If the PW is a 503 spoke in H-VPLS, any MAC addresses learned via the PW SHOULD be 504 flushed when it transitions to Standby state according to the 505 procedures in RFC4762 [3] and [9]. 507 6. PW State Transition Signaling Procedures 509 This section describes the extensions to PW status signaling and the 510 processing rules for these extensions. It defines a new "PW 511 preferential forwarding" bit Status Code that is to be used with the 512 PW Status TLV specified in RFC 4447 [2]. The PW preferential 513 forwarding bit, when set, is used to signal the Standby state of the 514 PW by one PE to the far end PE. 516 6.1. PW Standby Notification Procedures in Independent mode 518 PEs that contain PW endpoints independently select which PW they 519 intend to use for forwarding, depending on the specific application 520 (example applications are described in [5]). They advertise the 521 corresponding Active/Standby forwarding state for each PW. An active 522 forwarding state is indicated by clearing the Active/Standby status 523 bit in the PW status TLV. A standby forwarding state is indicated by 524 setting the Active/Standby status bit in the PW status TLV. This 525 advertisement occurs in both the initial label mapping message and in 526 a subsequent notification message when the forwarding state 527 transitions as a result of a state change in the specific 528 application. 530 Each PW endpoint compares the updated local and remote status and 531 effectively activates the PW which is operationally UP at both 532 endpoints and which shows both local Active and remote Active states. 534 When a PW is in active state, the PEs can forward both user packets 535 and OAM packets over the PW. 537 When a PW is in standby state, the PEs MUST NOT forward user packets 538 over the PW but MAY forward PW OAM packets. 540 For MS-PWs, S-PEs MUST relay the PW status notification containing 541 both the operational and preferential forwarding status bits between 542 ingress and egress PWs as per the procedures defined in [4]. 544 6.2. PW Standby notification procedures in Master/Slave mode 546 Whenever the Master PW endpoint selects or deselects a PW for 547 forwarding user traffic at its end, it explicitly notifies the event 548 to the remote Slave endpoint. The slave endpoint carries out the 549 corresponding action on receiving the PW state change notification. 551 If the PW preferential forwarding bit in PW Status TLV received by 552 the slave is set, it indicates that the PW at the Master end is not 553 used for forwarding and is thus kept in the Standby state, the PW 554 MUST also not be used for forwarding at Slave endpoint. Clearing the 555 PW Preferential Forwarding bit in PW Status TLV indicates that the PW 556 at the Master endpoint is used for forwarding and is in Active state, 557 and the receiving Slave endpoint MUST activate the PW if it was 558 previously not used for forwarding. 560 When this mechanism is used, a common group-id in the PWid FEC 561 element or Grouping TLV in Generalized PWid FEC Element defined in 562 [2] MAY be used to signal PWs in groups in order to minimize the 563 number of LDP status messages that must be sent. When PWs are 564 provisioned with such grouping a termination point sends a single 565 "wildcard" Notification message using a PW FEC TLV with only the 566 group ID set, to denote this change in status for all affected PW 567 connections. This status message contains either the PW FEC TLV with 568 only the Group ID set, or else it contains the PW Generalized FEC TLV 569 with only the PW Grouping ID TLV. As mentioned in [2], the Group ID 570 field of the PWid FEC Element, or the PW Grouping TLV used with the 571 Generalized ID FEC Element, can be used to send status notification 572 for all arbitrary set of PWs. For example, Group-ID in PWiD may be 573 used to send wildcard status notification message for a group of PWs 574 when PWid FEC element is used for PW state signaling. When 575 Generalized PWiD FEC Element defined is used in PW state signaling, 576 PW Grouping TLV may be used for wildcard status notification for a 577 group of PWs. 579 For MS-PWs, S-PEs MUST relay the PW status notification containing 580 both the operational and preferential forwarding status bits between 581 ingress and egress PW segments as per the procedures defined in [4]. 583 6.2.1. PW State Machine 585 It is convenient to describe the PW state change behavior in terms of 586 a state machine (Table 1). The PW state machine is explained in 587 detail in the two defined states and the behavior is presented as a 588 state transition table. The same state machine is applicable to PW 589 Groups. 591 STATE EVENT NEW STATE 593 ACTIVE PW put in Standby (master) STANDBY 594 Action: Transmit PW preferential 595 forwarding bit set 597 Receive PW preferential forwarding STANDBY 598 bit set (slave) 599 Action: Stop forwarding over PW 601 Receive PW preferential forwarding ACTIVE 602 bit set but bit not supported 603 Action: None 605 Receive PW preferential forwarding ACTIVE 606 bit clear 607 Action: None. 609 STANDBY PW activated (master) ACTIVE 610 Action: Transmit PW preferential 611 forwarding bit clear 613 Receive PW preferential forwarding ACTIVE 614 bit clear (slave) 615 Action: Activate PW 617 Receive PW preferential forwarding STANDBY 618 bit clear but bit not supported 619 Action: None 621 Receive PW preferential forwarding STANDBY 622 bit set 623 Action: No action 625 Table 1 PW State Transition Table 627 6.3. Coordination of PW Switchover 629 There are PW redundancy applications which require that PE nodes 630 coordinate the switchover to a PW such that both endpoints will 631 forward over the same PW at any given time. One such application for 632 redundant MS-PW is identified in [5]. Multiple MS-PWs are configured 633 between a pair of T-PE nodes. The paths of these MS-PWs are diverse 634 and are switched at different S-PE nodes. Only one of these MS-PWs is 635 active at any given time. The others are put in standby. The 636 endpoints follow the Independent Mode procedures to use the PW which 637 is both UP and for which both endpoints advertise an Active 638 'preferential forwarding' status bit. 640 The trigger for sending a request to switchover of the MS-PW by one 641 endpoint can be an operational event, for example a failure, which 642 causes the endpoints to be unable to find a common PW for which both 643 endpoints advertise an Active 'preferential forwarding' status bit. 644 The other trigger is the execution of an administrative maintenance 645 operation by the network operator in order to move the traffic away 646 from the nodes or links currently used by the active PW. 648 Unlike the case of a Master/Slave mode of operation, the endpoint 649 requesting the switchover requires explicit acknowledgement from the 650 peer endpoint that the request can be honored before it switches to 651 another PW. Furthermore, any of the endpoints can make the request to 652 switchover. 654 This document specifies a second status bit that is used by a PE to 655 request that its peer PE switchover to use a different active PW. 656 This bit is referred to as the 'request PW switchover' status bit. 657 The 'preferential forwarding' status bit continues to be used by each 658 endpoint to indicate its current local settings of the active/standby 659 state of each PW in the redundancy set. In other words, as in the 660 Independent mode, it indicates to the far-end which of the PWs is 661 being used to forward packets and which is being put in standby. It 662 can thus be used as a way for the far-end to acknowledge the 663 requested switchover operation. 665 The request switchover bit is OPTIONAL and, if received by a PE, is 666 ignored if not understood. 668 If the request switchover bit is supported by both sending and 669 receiving PEs, the following procedures MUST be followed by both 670 endpoints of a PW to coordinate the switchover of the PW. 672 S-PEs nodes MUST relay the PW status notification containing the 673 operational status bits, as well as the 'preferential forwarding' and 674 'request switchover' status bits between ingress and egress PW 675 segments as per the procedures defined in [4]. 677 6.3.1. Procedures at the requesting endpoint 679 a. The requesting endpoint sends a Status TLV in the LDP 680 notification message with the 'request switchover' bit set on the 681 PW it desires to switch to. 683 b. The endpoint does not activate forwarding on that PW at this 684 point in time. It MAY, however, enable receiving on that PW. Thus 685 the 'preferential forwarding' status bit still reflects the 686 currently-used PW. 688 c. The requesting endpoint starts a timer while waiting the remote 689 endpoint to acknowledge the request. 691 d. If while waiting for the acknowledgment, the requesting endpoint 692 receives a request from its peer to switchover to the same or a 693 different PW, it must perform the following: 695 i. If its address is higher than that of the peer, this 696 endpoint ignores the request and continues to wait for 697 the acknowledgement from its peer. 699 ii. If its system IP address is lower than that of its peer, 700 it aborts the timer and immediately starts the 701 procedures of the receiving endpoint in Section 6.3.2. 703 e. If while waiting for the acknowledgment, the requesting 704 endpoint receives a status notification message from its peer 705 with the 'preferential forwarding' status bit cleared in the 706 requested PW, it must treat this as an explicit acknowledgment of 707 the request and must perform the following: 709 i. Abort the timer. 711 ii. Activate the PW. 713 iii. Send an update status notification message with the 714 'preferential forwarding' status bit and the 'request 715 switchover' bit clear on the newly active PW and send an 716 update status notification message with the 717 'preferential forwarding' status bit set in the 718 previously active PW. 720 f. If while waiting for the acknowledgment, the requesting endpoint 721 detects that the requested PW went into operational Down state 722 locally, and could use an alternate PW which is operationally UP, 723 it must perform the following: 725 i. Abort the timer. 727 ii. Issue a new request to switchover to the alternate PW. 729 iii. Re-start the timer. 731 g. If, while waiting for the acknowledgment, the requesting endpoint 732 detects that the requested PW went into an operational Down state 733 locally, and could not use an alternate PW which is operationally 734 UP, it must perform the following: 736 i. Abort the timer. 738 ii. Send an update status notification message with the 739 'preferential forwarding' status bit unchanged and the 740 'request switchover' bit reset for the requested PW. 742 h. If, while waiting for the acknowledgment, the timer expires, the 743 requesting endpoint MUST assume that the request was rejected and 744 MAY issue a new request. 746 i. If the requesting node receives the acknowledgment after the 747 request expired, it will treat it as if the remote endpoint 748 unilaterally switched between the PWs without issuing a request. 749 In that case, it may issue a new request and follow the 750 requesting endpoint procedures to synchronize which PW to use for 751 the transmit and receive directions of the emulated service. 753 6.3.2. Procedures at the receiving endpoint 755 a. Upon receiving a status notification message with the 'request 756 switchover' bit set on a PW different from the currently active 757 one, and the requested PW is operationally UP, the receiving 758 endpoint must perform the following: 760 i. Activate the PW. 762 ii. Send an update status notification message with the 763 'preferential forwarding' status bit clear and the 764 'request switchover' bit reset on the newly active PW , 765 and send an update status notification message with the 766 'preferential forwarding' status bit set in the 767 previously active PW. 769 iii. Upon receiving a status notification message with the 770 'request switchover' bit set on a PW different from the 771 currently active one, and the requested PW is 772 operationally Down, the receiving endpoint MUST ignore 773 the request. 775 7. Operational Status Mapping 777 The generation and processing of the PW Status TLV must follow the 778 procedures in RFC 4447 [2]. The PW status TLV is sent on the active 779 PW and standby PWs to make sure the remote AC and remote PW states 780 are always known to the local PE node. 782 The generation and processing of PW Status TLV by an S-PE node in a 783 MS-PW must follow the procedures in [4]. 785 The procedures for mapping the operational status between a PW and an 786 AC in a PW service must follow the rules in [7] with the following 787 modifications. 789 7.1. AC Defect State Entry/Exit 791 A PE enters the AC receive (or transmit) defect state for a PW when 792 one or more of the conditions specified for this PW type in [7] are 793 met. 795 When a PE enters the AC receive (or transmit) defect state for a PW, 796 it must send a forward (reverse) defect indication to the remote 797 peers over all PWs in the redundancy set when required by the PW type 798 in [7]. 800 When a PE exits the AC receive (or transmit) defect state for a PW 801 service, it must clear the forward (or reverse) defect indication to 802 the remote peers over all PWs in the redundancy set when required by 803 the PW type in [7]. 805 7.2. PW Defect State Entry/Exit 807 A PE enters the PW receive (or transmit) defect state for a PW 808 service when one or more of the conditions specified in Section 8.2.1 809 (Section 8.2.2) in [7] are met for all PWs in the redundancy set. 811 When a PE enters the PW receive (or transmit) defect state for a PW 812 service, it must send a reverse (or forward) defect indication over 813 one or more of the PWs in the redundancy set if the PW failure was 814 detected by this PE without receiving a forward defect indication 815 from the remote PE [7]. 817 When a PE exits the PW receive (or transmit) defect state for a PW, 818 it must clear the reverse (or forward) defect indication over any PW 819 in the redundancy set if applicable. 821 8. Applicability and Backward Compatibility 823 The mechanism defined in this document is applicable to applications 824 where standby state signaling of a PW or PW group is required. 826 A PE implementation that uses the mechanisms described in this 827 document MUST negotiate the use of PW status TLV between its T-LDP 828 peers as per RFC 4447 [2]. If PW Status TLV is found to be not 829 supported by either of its endpoint after status negotiation 830 procedures, then the mechanisms specified in this document cannot be 831 used. 833 A PE implementation compliant to RFC 4447 [2], and which does not 834 support the generation or processing of the 'preferential forwarding' 835 status bit or of the 'request switchover' status bit, will ignore 836 these status bits if they are received from a peer PE. 838 9. Security Considerations 840 This document uses the LDP extensions that are needed for protecting 841 pseudo-wires. It will have the same security properties as in the 842 PWE3 control protocol [2]. 844 10. MIB Considerations 846 This document makes the following update to the PwOperStatusTC 847 textual convention in RFC5542 [8]: 849 PwOperStatusTC ::= TEXTUAL-CONVENTION 850 STATUS current 851 DESCRIPTION 852 "Indicates the operational status of the PW. 854 - up(1): Ready to pass packets. 856 - down(2): PW signaling is not yet finished, or 857 indications available at the service 858 level indicate that the PW is not 859 passing packets. 861 - testing(3): AdminStatus at the PW level is set to 862 test. 864 - dormant(4): The PW is not in a condition to pass 865 packets but is in a 'pending' state, 866 waiting for some external event. 868 - notPresent(5): Some component is missing to accomplish 869 the setup of the PW. It can be 870 configuration error, incomplete 871 configuration, or a missing H/W component. 873 - lowerLayerDown(6): One or more of the lower-layer interfaces 874 responsible for running the underlying PSN 875 is not in OperStatus 'up' state." 877 SYNTAX INTEGER { 878 up(1), 879 down(2), 880 testing(3), 881 dormant(4), 882 notPresent(5), 883 lowerLayerDown(6) 884 } 886 11. IANA Considerations 888 This document defines the following PW status codes for the PW 889 redundancy application. IANA is requested to allocate these from the 890 PW Status Codes registry. 892 11.1. Status Code for PW Preferential Forwarding Status 894 0x00000020 When the bit is set, it indicates "PW forwarding 896 standby". 898 When the bit is cleared, it indicates "PW forwarding 900 active". 902 11.2. Status Code for PW Request Switchover Status 904 0x00000040 When the bit is set, it represents "Request switchover to 905 this PW". 907 When the bit is cleared, it represents no specific 908 action. 910 12. Major Contributing Authors 912 The editors would like to thank Matthew Bocci, Pranjal Kumar Dutta, 913 Giles Heron, Marc Lasserre, Luca Martini, Thomas Nadeau, Jonathan 914 Newton, Hamid Ould-Brahim, and Olen Stokes, who made a major 915 contribution to the development of this document. 917 Matthew Bocci 918 Alcatel-Lucent 919 Email: matthew.bocci@alcatel-lucent.com 921 Pranjal Kumar Dutta 922 Alcatel-Lucent 923 Email: pdutta@alcatel-lucent.com 925 Giles Heron 926 BT 927 giles.heron@gmail.com 929 Marc Lasserre 930 Alcatel-Lucent 931 Email: mlasserre@alcatel-lucent.com 933 Luca Martini 934 Cisco Systems, Inc. 935 Email: lmartini@cisco.com 937 Thomas Nadeau 938 BT 939 tom.nadeau@bt.com 941 Jonathan Newton 942 Cable & Wireless 943 Email: Jonathan.Newton@cw.com 945 Hamid Ould-Brahim 946 Nortel 947 Email: hbrahim@nortel.com 948 Olen Stokes 949 Extreme Networks 950 Email: ostokes@extremenetworks.com 952 13. Acknowledgments 954 The authors would like to thank Vach Kompella, Kendall Harvey, 955 Tiberiu Grigoriu, John Rigby, Prashanth Ishwar, Neil Hart, Kajal 956 Saha, Florin Balus, Philippe Niger, Dave McDysan, and Roman 957 Krzanowski for their valuable comments and suggestions. 959 14. References 961 14.1. Normative References 963 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 964 Levels", BCP 14, RFC 2119, March 1997. 966 [2] Martini, L., et al., "Pseudowire Setup and Maintenance using 967 LDP", RFC 4447, April 2006. 969 [3] Kompella,V., Lasserrre, M. , et al., "Virtual Private LAN 970 Service (VPLS) Using LDP Signalling", RFC 4762, January 2007. 972 14.2. Informative References 974 [4] Martini, L., et al., "Segmented Pseudo Wire", draft-ietf-pwe3- 975 segmented-pw-13.txt, August 2009. 977 [5] Muley, P., et al., "Pseudowire (PW) Redundancy", draft-ietf- 978 pwe3-redundancy-02.txt", October 2009. 980 [6] Bryant, S., et al., "Pseudo Wire Emulation Edge-to-Edge (PWE3) 981 Architecture", RFC 3985, March 2005 983 [7] Aissaoui, M., et al., "Pseudo Wire (PW) OAM Message Mapping", 984 draft-ietf-pwe3-oam-msg-map-11.txt, June 2009. 986 [8] Nadeau, T., Zelig, D., Nicklass, O., "Definitions of Textual 987 Conventions for Pseudowire (PW) Management", RFC5542, May 2009 989 [9] Dutta, P., Lasserre, M., Stokes, O., "LDP Extensions for 990 Optimized MAC Address Withdrawal in H-VPLS", draft-ietf-l2vpn- 991 vpls-ldp-mac-opt-00.txt, April 2009 993 15. Appendix A - Applications of PW Redundancy Procedures 995 This section shows how the mechanisms described in this document are 996 used to achieve the desired protection behavior for the scenarios 997 described in the PW redundancy requirements and framework document 998 [5]. 1000 15.1. One Multi-homed CE with single SS-PW redundancy 1002 The following figure illustrates an application of single segment 1003 pseudowire redundancy. 1005 |<-------------- Emulated Service ---------------->| 1006 | | 1007 | |<------- Pseudo Wire ------>| | 1008 | | | | 1009 | | |<-- PSN Tunnels-->| | | 1010 | V V V V | 1011 V AC +----+ +----+ AC V 1012 +-----+ | | PE1|==================| | | +-----+ 1013 | |----------|....|...PW1.(active)...|....|----------| | 1014 | | | |==================| | | CE2 | 1015 | CE1 | +----+ |PE2 | | | 1016 | | +----+ | | +-----+ 1017 | | | |==================| | 1018 | |----------|....|...PW2.(standby)..| | 1019 +-----+ | | PE3|==================| | 1020 AC +----+ +----+ 1022 Figure 15-1 Multi-homed CE with single SS-PW redundancy 1024 The application in Figure 15-1 makes use of the Independent mode of 1025 operation. 1027 CE1 is dual homed to PE1 and to PE3 by attachment circuits. The 1028 method for dual-homing of CE1 to PE1 and to PE3 nodes, and the 1029 protocols used, are outside the scope of this document (see [5]). 1031 In this example, the AC from CE1 to PE1 is active, while the AC from 1032 CE1 to PE3 is standby, as determined by the redundancy protocol 1033 running on the ACs. Thus, in normal operation, PE1 and PE3 will 1034 advertise "Active" and "Standby" 'preferential forwarding' status bit 1035 respectively to PE2, reflecting the forwarding state of the two ACs 1036 to CE1 as determined by the AC dual-homing protocol. PE2 advertises 1037 'preferential forwarding' status bit of "Active" on both PW1 and PW2 1038 since the AC to CE2 is single homed. As both the local and remote 1039 operational and preferential forwarding status for PW1 are UP and 1040 Active, traffic is forwarded over PW1 in both directions. 1042 On failure of the AC between CE1 and PE1, the forwarding state of the 1043 AC on PE3 transitions to Active. PE3 then announces the newly changed 1044 'preferential forwarding' status bit of "active" to PE2. PE1 will 1045 advertise a PW status notification message indicating that the AC 1046 between CE1 and PE1 is operationally down. PE2 matches the local and 1047 remote preferential forwarding status of "active" and operational 1048 status "Up" and select PW2 as the new active pseudowire to send 1049 traffic to. 1051 On failure of PE1 node, PE3 will detect it and will transition the 1052 forwarding state of its AC to Active. The method by which PE3 detects 1053 that PE1 is down is outside the scope of this document. PE3 then 1054 announces the newly changed 'preferential forwarding' status bit of 1055 "active" to PE2. PE3 and PE2 match the local and remote preferential 1056 forwarding status of "active" and operational status "Up" and select 1057 PW2 as the new active pseudo-wire to send traffic to. Note that PE2 1058 may have detected that the PW to PE1 went down via T-LDP Hello 1059 timeout or via other means. However, it will not be able to forward 1060 user traffic until it receives the updated status bit from PE3. 1062 Note in this example, the receipt of the operational status of the AC 1063 on the CE1-PE1 link is normally sufficient for PE2 to switch to PW2. 1064 However, the operator may want to trigger the switchover of the PW 1065 for administrative reasons, e.g , maintenance, and thus the use of 1066 the 'preferential forwarding' status bit is required to notify PE2 to 1067 trigger the switchover. 1069 Note that the primary/secondary procedures do not apply in this case 1070 as the PW Active/Standby status is driven by the AC forwarding state 1071 as determined by the AC dual-homing protocol used. 1073 15.2. Multiple Multi-homed CEs with single SS-PW redundancy 1075 |<-------------- Emulated Service ---------------->| 1076 | | 1077 | |<------- Pseudo Wire ------>| | 1078 | | | | 1079 | | |<-- PSN Tunnels-->| | | 1080 | V V (not shown) V V | 1081 V AC +----+ +----+ AC V 1082 +-----+ | |....|.......PW1........|....| | +-----+ 1083 | |----------| PE1|...... .........| PE3|----------| | 1084 | CE1 | +----+ \ / PW3 +----+ | CE2 | 1085 | | +----+ X +----+ | | 1086 | | | |....../ \..PW4....| | | | 1087 | |----------| PE2| | PE4|--------- | | 1088 +-----+ | |....|.....PW2..........|....| | +-----+ 1089 AC +----+ +----+ AC 1091 Figure 15-2 Multiple Multi-homed CEs with single SS-PW redundancy 1093 The application in Figure 15-2 makes use of the Independent mode of 1094 operation. 1096 CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed PE3 and PE4. The 1097 method for dual-homing and the used protocols are outside the scope 1098 of this document. Note that the PSN tunnels are not shown in this 1099 figure for clarity. However, it can be assumed that each of the PWs 1100 shown is encapsulated in a separate PSN tunnel. 1102 PE1 advertises the preferential status "active" and operational 1103 status "UP" for pseudowires PW1 and PW4 connected to PE3 and PE4. 1104 This status reflects the forwarding state of the AC attached to PE1. 1105 PE2 advertises preferential status "standby" where as operational 1106 status "UP" for pseudowires PW2 and PW3 to PE3 and PE4. PE3 1107 advertises preferential status "standby" where as operational status 1108 "UP" for pseudo-wires PW1 and PW3 to PE1 and PE2. PE4 advertise the 1109 preferential status "active" and operational status "UP" for pseudo- 1110 wires PW2 and PW4 to PE2 and PE1 respectively. The method of 1111 deriving Active/Standby status of the AC is outside the scope of 1112 this document. Thus by matching the local and remote preferential 1113 forwarding status of "active" and operational status "Up" of 1114 pseudowire, the PE nodes determine which PW should be in the Active 1115 state. In this case it is PW4 that will be selected. 1117 On failure of the AC between CE1 and PE1, the forwarding state of 1118 the AC on PE2 is changed to Active. PE2 then announces the newly 1119 changed 'preferential forwarding' status bit of "active" to PE3 and 1120 PE4. PE1 will advertise a PW status notification message indicating 1121 that the AC between CE1 and PE1 is operationally down. PE2 and PE4 1122 match the local and remote preferential forwarding status of 1123 "active" and operational status "Up" and select PW2 as the new 1124 active pseudowire to send traffic to. 1126 On failure of PE1 node, PE2 will detect it and will transition the 1127 forwarding state of its AC to Active. The method by which PE2 1128 detects that PE1 is down is outside the scope of this document. PE2 1129 then announces the newly changed 'preferential forwarding' status 1130 bit of "active" to PE3 and PE4. PE2 and PE4 match the local and 1131 remote preferential forwarding status of "active" and operational 1132 status "Up" and select PW2 as the new active pseudo-wire to send 1133 traffic to. Note that PE3 and PE4 may have detected that the PW to 1134 PE1 went down via T-LDP Hello timeout or via other means. However, 1135 they will not be able to forward user traffic until they received 1136 the updated status bit from PE2. 1138 Because each dual-homing algorithm running on the two node sets, 1139 i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects the active AC 1140 independently, there is a need to signal the active status of the AC 1141 such that the PE nodes can select a common active PW for end-to-end 1142 forwarding between CE1 and CE2 as per the procedures in the 1143 independent mode. 1145 Note that any primary/secondary procedures, as defined in sections 1146 5.1. and 5.2. , do not apply in this use case as the Active/Standby 1147 status is driven by the AC forwarding state as determined by the AC 1148 dual-homing protocol used. 1150 15.3. Multi-homed CE with MS-PW redundancy 1152 The following figure illustrates an application of multi-segment 1153 pseudowire redundancy. 1155 Native |<-----------Pseudo Wire----------->| Native 1156 Service | | Service 1157 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 1158 | V V V V V V | 1159 | +-----+ +-----+ +-----+ 1160 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 1161 | |-------|......PW1-Seg1.......|PW1-Seg2.......|-------| | 1162 | | | |=========| |=========| | | | 1163 | CE1| +-----+ +-----+ +-----+ | | 1164 | | |.| +-----+ +-----+ | CE2| 1165 | | |.|===========| |=========| | | | 1166 | | |.....PW2-Seg1......|.PW2-Seg2......|-------| | 1167 +----+ |=============|S-PE2|=========|T-PE4| | +----+ 1168 +-----+ +-----+ AC 1170 Figure 15-3 Multi-homed CE with MS-PW redundancy 1172 The application in Figure 15-3 makes use of the Independent mode of 1173 operation. 1175 CE2 is dual-homed to T-PE2 and T-PE4. PW1 and PW2 are used to extend 1176 the resilient connectivity all the way to T-PE1. PW1 has two segments 1177 and is active pseudowire while PW2 has two segments and is a standby 1178 pseudo-wire. This application requires support for MS-PW with 1179 segments of the same type as described in [4]. 1181 The operation in this case is the same as in the case of SS-PW as 1182 described in Section 15.1. . The only difference is that the S-PE 1183 nodes need to relay the PW status notification containing both the 1184 operational and forwarding status to the T-PE nodes. 1186 15.4. Single Homed CE with MS-PW redundancy 1188 The following is an application of the independent mode of operation 1189 along with the optional request switchover procedures in order to 1190 provide N:1 PW protection. A revertive behavior to a primary PW is 1191 shown as an example of configuring and using the primary/secondary 1192 procedures described in sections 5.1. and 5.2. . 1194 Native |<------------Pseudo Wire------------>| Native 1195 Service | | Service 1196 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 1197 | V V V V V V | 1198 | +-----+ +-----+ +-----+ | 1199 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 1200 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 1201 | CE1| | |=========| |=========| | | CE2| 1202 | | +-----+ +-----+ +-----+ | | 1203 +----+ |.||.| |.||.| +----+ 1204 |.||.| +-----+ |.||.| 1205 |.||.|=========| |========== .||.| 1206 |.||...PW2-Seg1......|.PW2-Seg2...||.| 1207 |.| ===========|S-PE2|============ |.| 1208 |.| +-----+ |.| 1209 |.|============+-----+============= .| 1210 |.....PW3-Seg1.| | PW3-Seg2......| 1211 ==============|S-PE3|=============== 1212 | | 1213 +-----+ 1215 Figure 15-4 Single homed CE with multi-segment pseudo-wire redundancy 1217 CE1 is connected to PE1 in provider Edge 1 and CE2 to PE2 in provider 1218 edge 2 respectively. There are three segmented PWs. A primary PW, 1219 PW1, is switched at S-PE1. A primary PW, PW1 has the lowest 1220 precedence value of zero. A secondary PW, PW2, which is switched at 1221 S-PE2 and has a precedence of 1. Finally, another secondary PW, PW3, 1222 is switched at S-PE3 and has a precedence of 2. The precedence is 1223 locally configured at the endpoints of the PW, i.e., T-PE1 and T-PE2. 1224 Lower the precedence value, higher the priority. 1226 T-PE1 and T-PE2 will select the PW they intend to activate based on 1227 their local and remote operational state as well as the local 1228 precedence configuration. In this case, they will both advertise 1229 preferential forwarding' status bit of "active" on PW1 and of 1230 "standby" on PW2 and PW3 using priority derived from local precedence 1231 configuration. Assuming all PWs are operationally UP, T-PE1 and T-PE2 1232 will use PW1 to forward user packets. 1234 If PW1 fails, then the T-PE detecting the failure will send a status 1235 notification to the remote T-PE with a "PW Down" bit set as well as 1236 the 'preferential forwarding' status bit set on PW1. It will also 1237 clear 'preferential forwarding' status bit on PW2 as it is the next 1238 it has the next lowest precedence value. T-PE2 will also perform the 1239 same steps as soon as it is informed of the failure of PW1. Both T-PE 1240 nodes will perform a match on the 'preferential forwarding' status of 1241 "active" and operational status of "Up" and will use PW2 to forward 1242 user packets. 1244 However this does not guarantee that the T-PEs will choose the same 1245 PW from the redundant set to forward on, for a given emulated 1246 service, at all times. This may be due to a mismatch of the 1247 configuration of the PW precedence in each T-PE. This may also be due 1248 to a failure which caused the endpoints to not be able to match the 1249 Active 'preferential forwarding' status bit and operational status 1250 bits. In this case, T-PE1 and/or T-PE2 can invoke the optional 1251 request switchover/acknowledgement procedures to synchronize the 1252 choice of PW to forward on in both directions. 1254 The trigger for sending a request to switchover can also be the 1255 execution of an administrative maintenance operation by the network 1256 operator in order to move the traffic away from the T-PE/S-PE nodes 1257 /links to be serviced. 1259 In case the request switchover is sent by both endpoints 1260 simultaneously, both T-PEs send status notification with the newly 1261 selected PW with 'request switchover' bit set, waiting for response 1262 from the other endpoint. In such situation, the T-PE with greater 1263 system address request is given precedence. This helps in 1264 synchronizing PWs in event of mismatch of precedence configuration as 1265 well. 1267 On recovery of primary PW1, PW1 is selected to forward traffic 1268 and the secondary PW, PW2, is set to standby. 1270 15.5. PW redundancy between H-VPLS MTU-s and PE-rs 1272 Following figure illustrates the application of use of PW redundancy 1273 in H-VPLS for the purpose of dual-homing an MTU-s node to PE nodes 1274 using PW spokes. This application makes use of the Master/Slave mode 1275 of operation. 1277 |<-PSN1-->| |<-PSN2-->| 1278 V V V V 1279 +-----+ +--------+ 1280 |MTU-s|=========|PE1-rs |======== 1281 |..Active PW group.... | H-VPLS-core 1282 | |=========| |========= 1283 +-----+ +--------+ 1284 |.| 1285 |.| +--------+ 1286 |.|===========| |========== 1287 |...Standby PW group |.H-VPLS-core 1288 =============| PE2-rs|========== 1289 +--------+ 1291 Figure 15-5 Multi-homed MTU-s in H-VPLS core 1293 MTU-s is dual homed to PE1-rs and PE2-rs. The primary spoke PWs from 1294 MTU-s are connected to PE1-rs while the secondary PWs are connected 1295 to PE2. PE1-rs and PE2-rs are connected to H-VPLS core on the other 1296 side of network. MTU-s communicates to PE1-rs and PE2-rs the 1297 forwarding status of its member PWs for a set of VSIs having common 1298 status Active/Standby. It may be signaled using PW grouping with 1299 common group-id in PWid FEC Element or Grouping TLV in Generalized 1300 PWid FEC Element as defined in [2] to scale better. MTU-s derives 1301 the status of the PWs based on local policy configuration. In this 1302 example, the primary/secondary procedures,as defined in Section 5.2. 1303 , are used but this can be based on any other policy. 1305 Whenever MTU-s performs a switchover, it sends a wildcard 1306 Notification Message to PE2-rs for the Standby PW group containing PW 1307 Status TLV with PW Standby bit cleared. On receiving the notification 1308 PE-2rs unblocks all member PWs identified by the PW group and state 1309 of PW group changes from Standby to Active. All procedures described 1310 in Section 6.2. are applicable. 1312 The use of the 'preferential forwarding' status bit in Master/Slave 1313 mode is similar to Topology Change Notification in RSTP controlled 1314 IEEE Ethernet Bridges but is restricted over a single hop. When these 1315 procedures are implemented, PE-rs devices are aware of switchovers at 1316 MTU-s and could generate MAC Withdraw Messages to trigger MAC 1317 flushing within the H-VPLS full mesh. By default, MTU-s devices 1318 should still trigger MAC Withdraw messages as currently defined in 1319 [6] to prevent two copies of MAC withdraws to be sent, one by MTU-s 1320 and another one by PE-rs nodes. Mechanisms to disable MAC Withdraw 1321 trigger in certain devices is out of the scope of this document 1323 Author's Addresses 1325 Praveen Muley 1326 Alcatel-lucent 1327 701 E. Middlefiled Road 1328 Mountain View, CA, USA 1329 Email: Praveen.muley@alcatel-lucent.com 1331 Mustapha Aissaoui 1332 Alcatel-lucent 1333 600 March Rd 1334 Kanata, ON, Canada K2K 2E6 1335 Email: mustapha.aissaoui@alcatel-lucent.com