Network Working Group PraveenInternet Engineering Task Force (IETF) P. Muley, Ed.Internet Draft MustaphaRequest for Comments: 6870 M. Aissaoui, Ed. Updates:RFC4447 Alcatel-LucentIntended Status:Category: Standards TrackExpires: July 4, 2013 January 4,February 2013 ISSN: 2070-1721 Pseudowire Preferential Forwarding Status Bitdraft-ietf-pwe3-redundancy-bit-09.txtAbstract This document describes a mechanism for signaling the active and standby status of redundantpseudowiresPseudowires (PWs) between their termination points. A set ofredundantRedundant PWs is configured betweenprovider edgeProvider Edge (PE) nodes in single-segment pseudowire (SS-PW)applications,applications or betweenterminating provider edgeTerminating Provider Edge (T-PE) nodes inmulti-segment pseudowireMulti-Segment Pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is defined. This bit indicates apreferential forwardingPreferential Forwarding status with a value ofActiveactive orStandbystandby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. Finally, this document updates RFC 4447 by adding details to the handling of the PWStatus Codestatus code bits in the PW Status TLV. Status ofthisThis Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 4, 2013.http://www.rfc-editor.org/info/rfc6870. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1].Table of Contents 1.Introduction...................................................3Introduction ....................................................3 1.1. Requirements Language ......................................4 2. Motivation andScope...........................................4Scope ............................................4 3.Terminology....................................................6Terminology .....................................................7 4. PEArchitecture................................................8Architecture .................................................9 5. Modes ofOperation.............................................9Operation ..............................................9 5.1. IndependentMode:.........................................9Mode ...........................................9 5.2. Master/SlaveMode:.......................................12Mode .........................................12 6. PW State Transition SignalingProcedures......................14Procedures .......................14 6.1. PW Standby Notification Procedures in Independentmode...14Mode ....14 6.2. PW Standbynotification proceduresNotification Procedures in Master/Slavemode..15Mode ...15 6.2.1. PW StateMachine....................................15Machine ...................................16 6.3. Coordination of PWSwitchover............................17Switchover .............................17 6.3.1. Procedures at therequesting endpoint...............18Requesting Endpoint ..............18 6.3.2. Procedures at thereceiving endpoint................19Receiving Endpoint ...............20 7. StatusMapping................................................20Mapping .................................................20 7.1. AC Defect StateEntry/Exit...............................20Entry/Exit ................................21 7.2. PW Defect StateEntry/Exit...............................20Entry/Exit ................................21 8. Applicability and BackwardCompatibility......................21Compatibility .......................21 9. SecurityConsiderations.......................................21Considerations ........................................22 10. MIBConsiderations...........................................22Considerations ............................................22 11. IANAConsiderations..........................................22Considerations ...........................................22 11.1. Status Code for PW Preferential ForwardingStatus.......22Status ........22 11.2. Status Code for PW Request SwitchoverStatus............22Status .............23 12.Contributors.................................................22Contributors ..................................................23 13.Acknowledgments..............................................23Acknowledgments ...............................................24 14.References...................................................24References ....................................................24 14.1. NormativeReferences....................................24References .....................................24 14.2. InformativeReferences..................................24 15.References ...................................24 AppendixA -A. Applications of PW RedundancyProcedures........25 15.1.Procedures .............26 A.1. OneMulti-homedMulti-Homed CE withsingleSingle SS-PWredundancy.........25 15.2.Redundancy ...........26 A.2. MultipleMulti-homedMulti-Homed CEs withsingleSS-PWredundancy...27 15.3. Multi-homedRedundancy ............28 A.3. Multi-Homed CE with MS-PWredundancy....................28 15.4. Multi-homedRedundancy ......................30 A.4. Multi-Homed CE with MS-PWredundancyRedundancy and S-PEprotection29 15.5. Single HomedProtection ..31 A.5. Single-Homed CE with MS-PWredundancy...................31 15.6.Redundancy .....................32 A.6. PWredundancyRedundancy between H-VPLS MTU-s andPE-rs............33 Authors' Addresses...............................................34PE-rs ..............33 1. Introduction This document provides the extensions to thepseudowirePseudowire (PW) control plane to support the protection schemes of the PW redundancy applications described inRFC6718 (PW Redundancy [8]).RFC 6718, "Pseudowire (PW) Redundancy" [8]. It specifies a new PW status bit as well as the proceduresprovider edgeProvider Edge (PE) nodes follow to notify one another of thepreferential forwardingPreferential Forwarding state of each PW in the redundantset i.e.set, i.e., active or standby. This status bit is different from the PW status bits already defined in RFC 4447, the pseudowire setup and maintenance protocol [2]. In addition, this document specifies a second status bit to allow peer PE nodes to coordinate a switchover operation of the PW from active to standby, or vice versa. As a result of the introduction of these new status bits, this document updates RFC 4447 by clarifying the rules for processing status bits not originally defined in RFC 4447. It also updates RFC 4447 by defining that a status bit can indicate a status other than a fault or can indicate an instruction to the peer PE. See more details in Section 8. Section15.15 shows in detail how the mechanisms described in this document are used to achieve the desired protection schemes of the applications described in [8]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 2. Motivation and Scope The PW setup and maintenance protocol defines the following status codes in the PWstatusStatus TLV to indicate the state for anACattachment circuit (AC) and a PW [7]: 0x00000000 - Pseudowire forwarding (clear all failures) 0x00000001 - Pseudowire Not Forwarding 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 0x00000010 - Local PSN-facing PW (egress) Transmit Fault The applications defined in [8] allow the provisioning of a primary PW and one or many secondary backup PWs in the same Virtual Private Wire Service (VPWS) or Virtual Private LAN Service (VPLS). The objective of PW redundancy is to maintain end-to-end connectivity for the emulated service by activating the correct PW whenever an AC, a PE, or a PW fails. The correct PW means the onewhichthat provides the end-to-end connectivity fromCECustomer Edge (CE) to CE such that packets continue to flow. A PE node makes a selection of which PW to activate at any given time for the purpose of forwarding user packets. This selection takes into account the local state of the PW and AC, as well as the remote state of the PW and AC as indicated in the PW status bits it received from the peer PE node. In the absence of faults, all PWs are up both locally andremotelyremotely, and a PE node needs to select a single PW to which to forward userpackets to.packets. This is referred to as the active PW. All other PWs will be in standby and must not be used to forward user packets. In order for both ends of the service to select the same PW for forwarding user packets, this document defines a new statusbit,bit: the Preferential Forwarding statusbit, andbit. It also defines the procedures the PE nodes follow to indicate thepreferential forwardingPreferential Forwarding state of a PW to its peer PE node. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW if required by the application. This is known as the'request switchover'Request Switchover status bit. Together, the mechanisms described in this document achieve the following protection capabilities defined in [8]: a. A 1:1 protection in which a specific subset of a path for an emulated service, consisting of a standby PW and/or AC, protects another specific subset of a path for the emulated service, consisting of an active PW and/or AC..An active PW can forward data traffic and control plane traffic, such as Operations, Administration, and Maintenance (OAM) packets. A standby PW does not carry data traffic. b. An N:1 protection scheme in which N specific subsets of a path for an emulated service, consisting each of a standby PW and/or AC,protectsprotect a specific subset of a path for the emulated service, consisting of an active PW and/or AC..c. A mechanism to allow PW endpoints to coordinate the switchover to a given PW by using an explicit request/acknowledgment switchover procedure. This mechanism is complementary to theIndependentindependent mode of operation and is described in Section 6.3.6.3 .6.3. This mechanism can be invoked manually by the user, effectively providing a manual switchover capability. It can also be invoked automatically to resolve a situation where the PW endpoints could not match the two directions of the PW. d. A locally configured precedence to govern the selection of a PW when more than one PW qualifies for the active state, as defined insectionsSections 5.1.5.1and 5.2.5.2 .The PW with the lowest precedence value has the highest priority. Precedence may be configured via, for example, a local configuration parameter at the PW endpoint. e.ImplementationsBy configuration, implementations can designateby configurationone PW in the 1:1 or N:1 protection as a primary PW and the remaining as secondary PWs. If more than one PWqualifyqualifies for the active state, as defined insections 5.1.Sections 5.1 and5.2. 5.2 ,5.2, a PE node selects the primary PW in preference to a secondary PW. In other words, the primary PW has implicitly the lowest precedence value. Furthermore, a PE node reverts to the primary PW immediately after it comes back up or after the expiration of a delay effectively achieving revertive protection switching. 1+1 protectionin(in which one specific subset of a path for an emulated service, consisting of a standby PW and/or AC, protects another specific subset of a path for the emulated service and in which traffic is permanently duplicated at the ingress node on both the currently active and standby subsets of the paths) is not supported. The above protection schemes are provided using the following operational modes: 1. An independent mode of operation in which each PW endpoint node uses its own local rule to select which PW it intends to activate at any giventimetime, and advertisesitthat PW to the remote endpoints. Only a PWwhichthat is up andwhichthat indicatedActiveactive status bit locally and remotely is in the active state and can be used to forward data packets. This is described in Section 5.1. 2. AMaster/Slavemaster/slave mode in which one PW endpoint, theMastermaster endpoint, selects and dictates to the other endpoint(s), theSlaveslave endpoint(s), which PW to activate. This is described in Section 5.2. Note that this document specifies the mechanisms to support PW redundancy where a set of redundant PWs terminate on either a PE, in the case ofa single-segment pseudowire (SS-PW),an SS-PW, or on aterminating provider edge (T-PE)inT-PE, in the case ofa multi-segment pseudowire (MS- PW).an MS-PW. PW redundancy scenarios where the redundant set of PW segments terminates onan S-PEa Switching Provider Edge (S-PE) are for further study. 3. Terminology Pseudowire (PW): A mechanism that carries the essential elements of an emulated service from one PE to one or more other PEs over aPSNPublic Service Network (PSN) [9]. Single-Segment Pseudowire (SS-PW): A PW set up directly between two T-PE devices. The PW label is unchanged between the originating and terminatingT-PEsPEs [6]. Multi-Segment Pseudowire (MS-PW): A static or dynamically configured set of two or more contiguous PW segments that behave and function as a single point-to-point PW. Each end of an MS-PW, by definition, terminates on a T-PE [6]. Up PW: A PWwhichthat has been configured (label mapping exchanged between PEs) and is notinshowing any of the PW or ACdefect statesstatus bits specified in [7]. Such a PW is available for forwarding traffic [8]. Down PW: A PW thathaseither has not been fullyconfigured,configured or has been configured and isinshowing any of the PW or ACdefect statesstatus bits specifiedin[7],in [7]; such a PW is not available for forwarding traffic [8]. Active PW: An up PW used for forwarding user,OAMOAM, and control plane traffic [8]. Standby PW: An up PW that is not used for forwarding usertraffic,traffic but may forward OAM and specific control plane traffic [8]. Primary PW: The PWwhichthat a PW endpoint activates in preference to any other PW when more than one PW qualifies for active state. When the primary PW comes back up after a failure and qualifies for active state, the PW endpoint always reverts to it. The designation ofPrimaryprimary is performed by local configuration for the PW at the PE and is only required when revertive protection switching is used [8]. Secondary PW: When it qualifies for active state, a secondary PW is only selected if no primary PW is configured or if the configured primary PW does not qualify for active state (e.g., is down). By default, a PW in a redundancy PW set is considered secondary. There is no revertive mechanism among secondary PWs [8]. PW Precedence: This is a configuration local to the PE that dictates the order in which a forwarder chooses to use a PW when multiple PWs all qualify for the active state. Note that a PWwhichthat has been configured asPrimary has implicitlyprimary has, implicitly, the lowest precedence value. PW Endpoint: A PE where a PW terminates on a point where Native Service Processing is performed, e.g.,Aan SS-PW PE, an MS-PWT-PE, or an H-VPLS MTU-sT- PE, a Hierarchical VPLS (H-VPLS) MTU-s, or PE-rs [8]. Provider Edge (PE): A device that provides PWE3 to a CE [9]. PW Terminating Provider Edge (T-PE): A PE where thecustomer- facing attachment circuits (ACs)customer-facing ACs are bound to a PW forwarder. A terminating PE is present in the first and last segments of an MS-PW. This incorporates the functionality of a PE as defined in RFC 3985 [6]. PW Switching Provider Edge (S-PE): A PE capable of switching the control and data planes of the preceding and succeeding PW segments in an MS-PW. The S-PE terminates the PSN tunnels of the preceding and succeeding segments of the MS-PW.It thereforeTherefore, it includes a PW switching point for an MS-PW. A PW switching point is never the S-PE and the T-PE for the same MS-PW. A PW switching point runs necessary protocols to set up and manage PW segments with other PW switching points and terminating PEs. An S-PE can exist anywhere a PW must be processed or policy applied.ItTherefore, it isthereforenot limited to the edge of a provider network [6]. MTU-s: A hierarchical virtual private LAN service Multi-Tenant Unit switch, as defined in RFC 4762 [3]. PE-rs: A routing and bridging capable PE as defined in RFC 4762 [3]. FEC: Forwarding Equivalence Class. OAM: Operations, Administration, and Maintenance. VCCV: Virtual Connection Connectivity Verification. This document uses the term 'PE' to be synonymous with both PEs as per RFC 3985 [9] and T-PEs as per RFC 5659 [6]. This document uses the term 'PW' to be synonymous with both PWs as per RFC 3985 [9] and SS-PWs, MS-PWs, and PW segments as per RFC 5659 [6]. 4. PE Architecture Figure4-11 shows the PE architecture for PW redundancy, when more than one PW in a redundant set is associated with a single AC. This is based on the architecture in Figure 4b of RFC 3985 [9]. The forwarder selects which of the redundant PWs tousinguse based on the criteria described in this document. +----------------------------------------+ | PE Device | +----------------------------------------+ Single | | Single | PW Instance AC | + PW Instance X<===========> | | | | |----------------------| <------>o | Single | PW Instance | Forwarder + PW Instance X<===========> | | | | |----------------------| | | Single | PW Instance | + PW Instance X<===========> | | | +----------------------------------------+ Figure4-11. PE Architecture for PWredundancyRedundancy 5. Modes of Operation There are two modes of operation for the use of the PW Preferential Forwarding status bits: oIndependentindependent mode oMaster/Slave mode.master/slave mode 5.1. IndependentMode:Mode PW endpoint nodes independently select which PWs are eligible to become active and which are not. They advertise the correspondingActiveactive or standbypreferential forwardingPreferential Forwarding status for each PW. Each PW endpoint compares local and remote status bits and uses the PW that is up at both endpoints and that advertisedActive preferential forwardingactive Preferential Forwarding status at both the local and remote endpoints. In this mode of operation, thepreferential forwardingPreferential Forwarding status indicates the preferred forwarding state of each endpoint but the actual forwarding state of the PW is the result of the comparison of the local and remote forwarding status bits. If more than one PW qualifies for theActiveactive state, each PW endpoint MUST implement a common mechanism to choose the PW for forwarding. The default mechanism MUST be supported by allimplementationsimplementations, and it operates as follows: 1. For a PW using the PWid ID Forwarding Equivalence Class (PWid FEC)PW[2], the PW with the lowestpw-idPWid value is selected. 2. For a PW using the Generalized PWid FECPW[2], each PW in a redundant set is uniquely identified at each PE using the following triplet: AGI::SAII::TAII. The unsigned integer form of the concatenated word can be used in the comparison. However, theSAIISource Attachment Individual Identifier (SAII) andTAIITarget Attachment Individual Identifier (TAII) values as seen on a PE node are the mirror values of what the peer PE node sees. So that both PE nodes compare the same value, the PE with the lowest system IP address MUST use the unsigned integer form ofAGI::SAII::TAIIAGI::SAII::TAII, while the PE with the highest system IP address MUST use the unsigned integer form of AGI::TAII::SAII. This way, both PE nodes will compare the same values. The PWwhichthat corresponds to the minimum of the compared values across all PWs in the redundant set is selected. In the case where the system IP address is not known, it is RECOMMENDED to implement the active PW selection mechanism described next. In the case of segmented PW, the operator needs to make sure that thepw-idPWid or AGI::SAII::TAII of the redundant PWs within the first and last segment are ordered consistently such that the sameend-to-endend- to-end MS-PW gets selected. Otherwise, it is RECOMMENDED to implement the active PW selection mechanism described next. The PW endpoints MAY also implement the following active PW selectionmechanism.mechanism: 1. If the PW endpoint is configured with the precedence parameter on each PW in the redundant set, it selects the PW with the lowest configured precedence value. 2. If the PW endpoint is configured with one PW as primary and one or more PWs as secondary, it selects the primary PW in preference to all secondary PWs. If a primary PW is not available, it selects the secondary PW with the lowest precedence value. If the primary PW becomes available, a PW endpoint reverts to it immediately or after the expiration of a configurable delay. 3. This active PW selection mechanism assumes the precedence parameter values are configured consistently at both PW endpoints and that unique values are assigned to the PWs in the same redundant set to achievetie-breakingtiebreaking using this mechanism. There are scenarios with dual-homing of a CE to PE nodes where each PE node needs to advertiseActive preferential forwardingactive Preferential Forwarding status on more than one PW in the redundant set. However, a PE MUST always select a single PW for forwarding using the above active PW selection algorithm. An example of such a case is described in 15.2..There are scenarios where each PE needs toadvertize Active preferential forwardingadvertise active Preferential Forwarding status on a single PW in the redundant set. In order to ensure that both PE nodes make the same selection, they MUST use the above active PW selection algorithm to determine the PW eligible for active state. An example of such a case is described in 15.5..In steady state with consistent configuration, a PE will always find an active PW. However, it is possible that such a PW is not found due to a misconfiguration. In the event that an active PW is not found, a management notification SHOULD be generated. If a management notification for failure to find an active PW was generated and an active PW is subsequently found, a management notification SHOULD be generated, so clearing the previous failure indication. Additionally, a PE MAY use the request switchover procedures described in Section6.3.6.3 to have both PE nodes switch to a common PW. There may also be transient conditions where endpoints do not share a common view of theActive/Standbyactive/standby state of the PWs. This could be caused by propagation delay of theT-LDPTargeted Label Distribution Protocol (T-LDP) status messages between endpoints. In this case, the behavior of the receiving endpoint is outside the scope of this document. Thus, in this mode of operation, the following definition ofActiveactive andStandbystandby PW states apply: o Active State A PW is considered to be inActiveactive state when the PW labels are exchanged between its two endpoints and the status bits exchanged between the endpoints indicate the PW is up and itspreferential forwardingPreferential Forwarding status isActiveactive at both endpoints. In this state user traffic can flow over the PW in both directions. As described in Section5.1. 5.1 ,5.1, the PE nodes MUST implement a common mechanism to select one PW for forwarding in case multiple PWs qualify for theActiveactive state. o Standby State A PW is considered to be inStandbystandby state when the PW labels are exchanged between its two endpoints, but the Preferential Forwarding status bits exchanged indicate the PWpreferential forwardingPreferential Forwarding status isStandbystandby at one or both endpoints. In thisstatestate, the endpoints MUST NOT forward data traffic over the PW but MAY allow PW OAM packets, e.g., Virtual Connection Connectivity Verification (VCCV) packets[12],[11], to be sent and received in order to test the liveliness of standby PWs. The endpoints of the PW MAY also allow the forwarding of specific control plane packets of applications using the PW. The specification of applications and the allowed control plane packetsisare outside the scope of this document. If the PW is a spoke in H-VPLS, anyMACMedia Access Control (MAC) addresses learned via the PW SHOULD be flushed when it transitions toStandby statestandby state, according to the procedures in RFC 4762 [3] and in[11].[10]. 5.2. Master/SlaveMode:Mode One endpoint node of the redundant set of PWs is designated theMastermaster and is responsible for selecting which PW both endpoints must use to forward user traffic. TheMastermaster indicates the forwarding state in the PW Preferential Forwarding status bit. The other endpoint node, theSlave,slave, MUST follow the decision of theMastermaster node based on the received status bits. In other words, the Preferential Forwarding status bit sent by theMastermaster node indicates the actual forwarding state of the PW at theMastermaster node. There is a single PEMastermaster PW endpoint node and one or many PE PW endpointSlaveslave nodes. The assignment ofMaster/Slavemaster/slave roles to the PW endpoints is performed by local configuration. Note that the behavior described in this section assumes correct configuration of theMastermaster andSlaveslave endpoints. This document does not define a mechanism to detect errors in the configuration, and misconfiguration might lead to protection switchover failing to work correctly. Furthermore, this document does not specify the procedures for a backupMastermaster node. In deployments where PE node protection is required, it is recommended to use theIndependent Modeindependent mode of operation as in the application described in Section 15.2. One endpoint of the PW, theMaster,master, actively selects which PW to activate and uses it for forwarding user traffic. This status is indicated to theSlaveslave node by setting the Preferential Forwarding status bit in the status bit TLV toActive.active. It does not forward user traffic to any other of the PW's in the redundant set to the slave node and indicates this by setting the Preferential Forwarding status bit in the status bit TLV toStandbystandby for those PWs. The master node MUST ignore any PW Preferential Forwarding status bits received from theSlaveslave nodes. If more than one PW qualifies for theActiveactive state, theMastermaster PW endpoint node selects one. There is no requirement to specify a default active PW selection mechanism in thiscase butcase; however, for consistency across implementations, theMastermaster PW endpoint SHOULD implement the default active PW selection mechanism described in Section 5.1. If theMastermaster PW endpoint implements the active PW selection mechanism based on primary/secondary and precedence parameters, it MUSTfollowcomply with the following behavior: 1. If the PW endpoint is configured with the precedence parameter on each PW in the redundant set, it MUST select the PW with the lowest configured precedence value. 2. If the PW endpoint is configured with one PW as primary and one or more PWs as secondary, it MUST select the primary PW in preference to all secondary PWs. If a primary PW is not available, it MUST use the secondary PW with the lowest precedence value. If the primary PW becomes available, a PW endpoint MUST revert to it immediately or after the expiration of a configurable delay. TheSlaveslave endpoint(s) are required to act on the status bits received from theMaster.master. When the received status bit transitions fromActiveactive toStandby,standby, aSlaveslave node MUST stop forwarding over the previously active PW. When the received status bit transitions fromStandbystandby toActiveactive for a given PW, theSlaveslave node MUST start forwarding user traffic over this PW. In this mode of operation, the following definition ofActiveactive andStandbystandby PW states apply: o Active State A PW is considered to be inActiveactive state when the PW labels are exchanged between its two endpoints, and the status bits exchanged between the endpoints indicate the PW is up at both endpoints, and thepreferential forwardingPreferential Forwarding status at theMastermaster endpoint isActive.active. In thisstatestate, user traffic can flow over the PW in both directions. o Standby State A PW is considered to be inStandbystandby state when the PW labels are exchanged between its two endpoints, and the status bits exchanged between the endpoints indicate thepreferential forwardingPreferential Forwarding status at theMastermaster endpoint isStandby.standby. In thisstatestate, the endpoints MUST NOT forward data traffic over the PW but MAY allow PW OAM packets, e.g., VCCV, to be sent and received. The endpoints of the PW MAY also allow the forwarding of specific control plane packets of applications using the PW. The specification of applications and the allowed control plane packetsisare outside the scope of this document. If the PW is a spoke in H-VPLS, any MAC addresses learned via the PW SHOULD be flushed when it transitions to standby state according to the procedures in RFC 4762 [3] and[11].[10]. 6. PW State Transition Signaling Procedures This section describes the extensions to PW status signaling and the processing rules for these extensions. It defines a new"PWPW PreferentialForwarding"Forwarding status bitStatus Codethat is to be used with the PW Status TLV specified in RFC 4447 [2]. The PW Preferential Forwarding bit, when set, is used to signal either thePreferredpreferred orActual Active/Standbyactual active/standby forwarding state of the PW by one PE to thefar endfar-end PE. The actual semantics of the value being signaled vary according to whether the PW is acting ina Master/Slavemaster/slave orIndependentindependent mode. 6.1. PW Standby Notification Procedures in IndependentmodeMode PEs that contain PW endpoints independently select which PW they intend to use for forwarding, depending on the specific application (example applications are described in [8]). They advertise the corresponding preferredActive/Standbyactive/standby forwarding state for each PW. AnActiveactive Preferential Forwarding state is indicated by clearing the PW Preferential Forwarding status bit in the PWstatusStatus TLV. AStandbystandby Preferential ForwardingStatestate is indicated by setting the PW Preferential Forwarding status bit in the PWstatusStatus TLV. This advertisement occurs in both the initial label mapping message and in a subsequent notification message when the forwarding state transitions as a result of a state change in the specific application. Each PW endpoint compares the updated local and remote status and effectively activates thePWPW, which is up at both endpoints and which shows both localActiveactive and remoteActiveactive Preferential Forwarding states. The PE nodes MUST implement a common mechanism to select one PW for forwarding in case multiple PWs qualify for theActive stateactive state, as explained in Section 5.1.5.1 .When a PW is inActiveactive state, the PEs can forward user packets, OAM packets, and other control plane packets over the PW. When a PW is inStandbystandby state, the PEs MUST NOT forward user packets over the PW but MAY forward PW OAM packets and specific control plane packets. For MS-PWs, S-PEs MUST relay the PW status notification containing both the existing status bits and the new Preferential Forwarding status bits between ingress and egress PWs as per the procedures definedin[4].in [4]. 6.2. PW Standbynotification proceduresNotification Procedures in Master/SlavemodeMode Whenever theMastermaster PW endpoint selects or deselects a PW for forwarding user traffic at its end, it explicitly notifies the event to the remoteSlaveslave endpoint. The slave endpoint carries out the corresponding action on receiving the PW state change notification. If the PW Preferential Forwarding bit in PW Status TLV received by the slave is set, it indicates that the PW at theMastermaster end is not used for forwarding and is thus kept in theStandbystandby state. The PW MUST NOT be used for forwarding atSlaveslave endpoint. Clearing the PW Preferential Forwarding bit in PW Status TLV indicates that the PW at theMastermaster endpoint is used for forwarding and is inActiveactive state, and the receivingSlaveslave endpoint MUST activate the PW if it was previously not used for forwarding. When this mechanism is used, a common Group ID in the PWid FEC element or a PW Grouping ID TLV in the Generalized PWid FECelementelement, as defined in[2][2], MAY be used to signal PWs in groups in order to minimize the number of LDP status messages that MUST be sent. When PWs are provisioned with suchgroupinggrouping, a termination point sends a single "wildcard"Notificationnotification message to denote this change in status for all affected PWs. This status message contains either the PWid FEC TLV with only the GroupID,ID orelse it containsthe Generalized PWid FEC TLV with only the PW Grouping ID TLV. As mentioned in [2], the Group ID field of the PWid FEC element, or the PW Grouping ID TLV in the Generalized PWid FEC element, can be used to send status notification for an arbitrary set of PWs. For MS-PWs, S-PEs MUST relay the PW status notification containing both the existing and the new Preferential Forwarding status bits between ingress and egress PWsegmentssegments, as per the procedures defined in [4]. 6.2.1. PW State Machine It is convenient to describe the PW state change behavior in terms of a state machine (Table 1). The PW state machine is explained in detail in the two definedstatesstates, and the behavior is presented as a state transition table. The same state machine is applicable to PWGroups.groups. STATE EVENT NEW STATE ACTIVE PW put inStandbystandby (master) STANDBY Action: Transmit PWpreferential forwardingPreferential Forwarding bit set Receive PW Preferential Forwarding STANDBY bit set (slave) Action: Stop forwarding over PW Receive PW Preferential Forwarding ACTIVE bit set but bit not supported Action: None Receive PW Preferential Forwarding ACTIVE bit clear Action: None. STANDBY PW activated (master) ACTIVE Action: Transmit PWpreferential forwardingPreferential Forwarding bit clear Receive PW Preferential Forwarding ACTIVE bit clear (slave) Action: Activate PW Receive PW Preferential Forwarding STANDBY bit clear but bit not supported Action: None Receive PW Preferential Forwarding STANDBY bit set Action: None Table11. PW State Transition Table in Master/Slave Mode 6.3. Coordination of PW Switchover There are PW redundancy applicationswhichthat require that PE nodes coordinate the switchover to a PW such that both endpoints will forward over the same PW at any given time. One such application for redundant MS-PW is identified in [8]. Multiple MS-PWs are configured between a pair of T-PE nodes. The paths of these MS-PWs are diverse and are switched at different S-PE nodes. Only one of these MS-PWs is active at any given time. The others are put in standby. The endpoints follow theIndependent Modeindependent mode procedures to use thePWPW, which is both up and for which both endpoints advertise anActiveactive Preferential Forwarding status bit. The trigger for sending a request to switchoverof the MS-PWby one endpoint of the MS-PW can be an operationalevent, for exampleevent. For example, afailure, whichfailure that causes the endpoints to be unable to find a common PW for which both endpoints advertise anActiveactive Preferential Forwarding status bit. The other trigger is the execution of an administrative maintenance operation by the network operator in order to move the traffic away from the nodes or links currently used by the active PW. Unlike the case of aMaster/Slavemaster/slave mode of operation, the endpoint requesting the switchover requires explicit acknowledgement from the peer endpoint that the request can be honored before it switches to another PW. Furthermore, any of the endpoints can make the request toswitchover.switch over. This document specifies a second status bit that is used by a PE to request that its peer PEswitchoverswitch over to use a different active PW. This bit is referred to as the'request switchover'Request Switchover status bit. The Preferential Forwarding status bit continues to be used by each endpoint to indicate its current local settings of theActive/Standbyactive/standby state of each PW in the redundant set. In other words, as in theIndependentindependent mode, it indicates to the far-end which of the PWs is being used to forward packets and which is being put in standby. It can thus be used as a way for the far-end to acknowledge the requested switchover operation. A PE MAY support the'request switchover'Request Switchover bit. A PEwhichthat receives the'request switchover'Request Switchover bit andwhichthat does not support it will ignore it. If the'request switchover'Request Switchover bit is supported by both sending and receiving PEs, the following procedures MUST be followed by both endpoints of a PW to coordinate the switchover of the PW. S-PEs nodes MUST relay the PW status notification containing the existing status bits, as well as the new Preferential Forwarding and'request switchover'Request Switchover status bits between ingress and egress PW segments as per the procedures defined in [4]. 6.3.1. Procedures at therequesting endpointRequesting Endpoint a. The requesting endpoint sends a Status TLV in the LDP notification message with the'request switchover'Request Switchover bit set on the PW to which it desires toswitch to.switch. b. The endpoint does notactivateactivate, forwarding on that PW at this point in time. It MAY, however, enable receiving on that PW.ThusThus, the Preferential Forwarding status bit still reflects thecurrently-usedcurrently used PW. c. The requesting endpoint starts a timer while waiting for the remote endpoint to acknowledge the request. This timer SHOULD be configurable with a default value of 3 seconds. d.IfIf, while waiting for the acknowledgment, the requesting endpoint receives a request from its peer toswitchoverswitch over to the same or a different PW, it MUST perform the following: i. If its address is higher than that of the peer, this endpoint ignores the request and continues to wait for the acknowledgement from its peer. ii. If its system IP address is lower than that of its peer, it aborts the timer and immediately starts the procedures of the receiving endpoint in Section 6.3.2. e.IfIf, while waiting for the acknowledgment, the requesting endpoint receives a status notification message from its peer with the'Preferential Forwarding'Preferential Forwarding status bit cleared in the requested PW, it MUST treat this as an explicit acknowledgment of the request and MUST perform the following: i. Abort the timer. ii. Activate the PW. iii. Send an update status notification message with the'Preferential Forwarding'Preferential Forwarding status bit and the'request switchover'Request Switchover bit clear on the newly active PW and send an update status notification message with the'Preferential Forwarding'Preferential Forwarding status bit set in the previously active PW. f.IfIf, while waiting for the acknowledgment, the requesting endpoint detects that the requested PW went into down state locally, and could use an alternate PWwhichthat is up, it MUST perform the following: i. Abort the timer. ii. Issue a new request to switchover to the alternate PW. iii.Re-startRestart the timer. g. If, while waiting for the acknowledgment, the requesting endpoint detects that the requested PW went into the down state locally, and could not use an alternate PWwhichthat is up, it MUST perform the following: i. Abort the timer. ii. Send an update status notification message with the Preferential Forwarding status bit unchanged and the'request switchover'Request Switchover bit reset for the requested PW. h. If, while waiting for the acknowledgment, the timer expires, the requesting endpoint MUST assume that the request was rejected and MAY issue a new request. i. If the requesting node receives the acknowledgment after the request expired, it will treat it as if the remote endpoint unilaterally switched between the PWs without issuing a request. In that case, it MAY issue a new request and follow the requesting endpoint procedures to synchronize which PW to use for the transmit and receive directions of the emulated service. 6.3.2. Procedures at thereceiving endpointReceiving Endpoint a. Upon receiving a status notification message with the'request switchover'Request Switchover bit set on a PW different from the currently active one, and the requested PW is up, the receiving endpoint MUST perform the following: i. Activate the PW. ii. Send an update status notification message with the'Preferential Forwarding'Preferential Forwarding status bit clear and the'request switchover'Request Switchover bit reset on the newly active PW , and send an update status notification message with the Preferential Forwarding status bit set in the previously active PW. iii. Upon receiving a status notification message with the'request switchover'Request Switchover bit set on aPWPW, which is different from the currently activeone, and the requestedPW but is down, the receiving endpoint MUST ignore the request. 7. Status Mapping The generation and processing of the PW Status TLV MUST follow the procedures in RFC 4447 [2]. The PWstatusStatus TLV is sent on the active PW and standby PWs to make sure the remote AC and PW states are always known to the local PE node. The generation and processing of PW Status TLV by an S-PE node in a MS-PW MUST follow the procedures in [4]. The procedures for determining and mapping PW and AC states MUST follow the rules in [5] with the following modifications. 7.1. AC Defect State Entry/Exit A PE enters the AC receive (or transmit) defect state for a PW service when one or more of the conditions specified for this PW service in [5] are met. When a PE enters the AC receive (or transmit) defect state for a PW, it MUST send a forward (reverse) defect indication to the remote peers over all PWs in the redundant setwhichthat are associated with this AC. When a PE exits the AC receive (or transmit) defect state for a PW service, it MUST clear the forward (or reverse) defect indication to the remote peers over all PWs in the redundant setwhichthat are associated with this AC. 7.2. PW Defect State Entry/Exit A PE enters the PW receive (or transmit) defect state for a PW service when one or more of the conditions specified in Section8.2.18.3.1 (Section8.2.2)8.3.2) in [5] are met for each of the PWs in the redundant set. When a PE enters the PW receive (or transmit) defect state for a PW service associated with an AC, it MUST send a reverse (or forward) defect indication over one or more of the PWs in the redundant set associated with the same AC if the PW failure was detected by this PE without receiving a forward defect indication from the remote PE [5]. When a PE exits the PW receive (or transmit) defect state for a PW, it MUST clear the reverse (or forward) defect indication over any PW in the redundant associated with the same AC set if applicable. 8. Applicability and Backward Compatibility The mechanisms defined in this document are to be used in applications where standby state signaling of a PW or PW group is required. Both PWid FEC and Generalized PWid FEC are supported. All PWswhichthat are part of a redundant set MUST use the same FEC type. When the set uses the PWid FEC element, each PW is uniquely identified by its PW ID. When the redundant set uses the Generalized PWid FEC element, each PW MUST have a unique identifierwhichthat consists of the triplet AGI::SAII::TAII. A PE implementation that uses the mechanisms described in this document MUST negotiate the use of PWstatusStatus TLV between its T-LDPpeerspeers, as per RFC 4447 [2]. If the PW Status TLV is found to be not supported by either of itsendpointendpoints after status negotiation procedures, then the mechanisms specified in this document cannot be used. A PE implementation that is complianttowith RFC 4447[2],[2] andwhichthat does not support the generation or processing of the Preferential Forwarding status bit or of the'request switchover'Request Switchover statusbit,bit MUST ignore these status bits if they are set by a peer PE. This document in fact updates RFC 4447 by prescribing the same behavior for any status bit not originally defined in RFC 4447.FinallyFinally, this document updates RFC 4447 by defining that a status bit can indicate a status other than a fault or can indicate an instruction to the peer PE. As a result, a PE implementation compliant to RFC 4447 MUST process each status bit it supports when set according to the rules specific to that status bit. 9. Security Considerations LDP extensions/options that protectpseudowiresPWs must be implemented because the status bits defined in this document have the same security considerations as thepseudowirePW setup and maintenance protocol defined inRFC4447RFC 4447 [2]. It should be noted that the security of a PW redundant set is only as good as the weakest security on any of its members. 10. MIB Considerations New MIB objects for the support of PW redundancy will be defined in a separate document. 11. IANA Considerations This document defines the following PW status codes for the PW redundancy application. IANAis requested to allocatehas allocated these from thePW"Pseudowire Status Codesregistry.Registry". 11.1. Status Code for PW Preferential Forwarding Status 0x00000020 When the bit is set, it indicates"PWPW forwarding standby". When the bit is cleared, it indicates"PWPW forwarding active". 11.2. Status Code for PW Request Switchover Status 0x00000040 When the bit is set, it represents"Request switchover"Request Switchover to this PW. When the bit is cleared, it represents no specific action. 12. Contributors The editors would like to thank Matthew Bocci, Pranjal Kumar Dutta, Giles Heron, Marc Lasserre, Luca Martini, Thomas Nadeau, Jonathan Newton, Hamid Ould-Brahim, Olen Stokes, and Daniel Cohn who made a contribution to the development of this document. Matthew Bocci Alcatel-LucentEmail:EMail: matthew.bocci@alcatel-lucent.com Pranjal Kumar Dutta Alcatel-LucentEmail:EMail: pranjal.dutta@alcatel-lucent.com Giles Heron Cisco Systems, Inc. giles.heron@gmail.com Marc Lasserre Alcatel-LucentEmail:EMail: marc.lasserre@alcatel-lucent.com Luca Martini Cisco Systems, Inc.Email:EMail: lmartini@cisco.com Thomas Nadeau Juniper NetworksEmail:EMail: tnadeau@lucidvision.com Jonathan Newton Cable & Wireless WorldwideEmail:EMail: Jonathan.Newton@cw.com Hamid Ould-BrahimEmail:EMail: ouldh@yahoo.com Olen Stokes Extreme NetworksEmail:EMail: ostokes@extremenetworks.com Daniel Cohn Orckit daniel.cohn.ietf@gmail.com. 13. Acknowledgments The authors would like to thank the following individuals for their valuable comments andsuggestionssuggestions, which improved the document both technically and editorially: Vach Kompella, Kendall Harvey, Tiberiu Grigoriu, John Rigby, Prashanth Ishwar, Neil Hart, Kajal Saha, Florin Balus, Philippe Niger, Dave McDysan, Roman Krzanowski, Italo Busi, Robert Rennison, and Nicolai Leymann. 14. References 14.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Martini, L.,et al.,Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenanceusing LDP",Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [3]Kompella,V., Lasserrre, M. , et al.,Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) UsingLDP Signalling",Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. [4] Martini, L.,et al.,Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. [5] Aissaoui, M.,et al.,Busschbach, P., Martini, L., Morrow, M., Nadeau, T., and Y(J). Stein, "Pseudowire (PW)OAMOperations, Administration, and Maintenance (OAM) Message Mapping", RFC 6310, July 2011. 14.2. Informative References [6] Bocci,M.,M. and S. Bryant,S., et al.,"An Architecture forMulti- SegmentMulti-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009. [7] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. [8] Muley, P.,et al.,Aissaoui, M., and M. Bocci, "Pseudowire(PW)Redundancy", RFC 6718, August 2012. [9] Bryant, S.,et al., "PseudowireEd., and P. Pate, Ed., "Pseudo Wire EmulationEdge-to-EdgeEdge- to-Edge (PWE3) Architecture", RFC 3985, March20052005. [10]Nadeau, T., Zelig, D., Nicklass, O., "Definitions of Textual Conventions for Pseudowire (PW) Management", RFC 5542, May 2009 [11]Dutta, P.,Lasserre, M., Stokes, O.,Balus, F., Calvignac, G., and O. Stokes "LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS",draft-ietf-l2vpn- vpls-ldp-mac-opt-05.txt,Work in Progress, October2011 [12]2011. [11] Nadeau,T.T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.15.AppendixA -A. Applications of PW Redundancy Procedures This section shows how the mechanisms described in this document are used to achieve the desired protection behavior for some of the applications described inthe PW Redundancy"PW Redundancy" [8].15.1.A.1. OneMulti-homedMulti-Homed CE withsingleSingle SS-PWredundancyRedundancy The following figure illustrates an application ofsingle segment pseudowireSS-PW redundancy. |<-------------- Emulated Service ---------------->| | | | |<------- Pseudowire ------>| | | | | | | | |<-- PSN Tunnels-->| | | | V V V V | V AC +----+ +----+ AC V +-----+ | | PE1|==================| | | +-----+ | |----------|....|...PW1.(active)...|....|----------| | | | | |==================| | | CE2 | | CE1 | +----+ |PE2 | | | | | +----+ | | +-----+ | | | |==================| | | |----------|....|...PW2.(standby)..| | +-----+ | | PE3|==================| | AC +----+ +----+ Figure15-1 Multi-homed2. Multi-Homed CE withsingleSS-PWredundancyRedundancy The application in Figure15-12 makes use of theIndependentindependent mode of operation. CE1 isdual homeddual-homed to PE1 and to PE3 by attachment circuits. The method for dual-homing of CE1 to PE1 and to PE3 nodes and the protocols used are outside the scope of this document (see [8]). In this example, the AC from CE1 to PE1 is active, while the AC from CE1 to PE3 is standby, as determined by the redundancy protocol running on the ACs. Thus, in normal operation, PE1 and PE3 will advertiseActivean active andStandbystandby Preferential Forwarding statusbit respectivelybit, respectively, to PE2, reflecting the forwarding state of the two ACs to CE1 as determined by the AC dual-homing protocol. PE2 advertises a Preferential Forwarding status bit ofActiveactive on both PW1 andPW2PW2, since the AC to CE2 issingle homed.single-homed. As both the local and remote UP/DOWN status andpreferential forwardingPreferential Forwarding status for PW1 are up andActive,active, traffic is forwarded over PW1 in both directions. On failure of the AC between CE1 and PE1, the forwarding state of the AC on PE3 transitions toActive.active. PE3 then announces the newly changed Preferential Forwarding status bit ofActiveactive to PE2. PE1 will advertise a PW status notificationmessagemessage, indicating that the AC between CE1 and PE1 is down. PE2 matches the local and remotepreferential forwardingPreferential Forwarding status ofActiveactive and status of "Pseudowire forwarding" andselectselects PW2 as the new activepseudowirePW to which to sendtraffic to.traffic. On failure of the PE1 node, PE3 will detect it and will transition the forwarding state of its AC toActive.active. The method by which PE3 detects that PE1 is down is outside the scope of this document. PE3 then announces the newly changed Preferential Forwarding status bit ofActiveactive to PE2. PE3 and PE2 match the local and remotepreferential forwardingPreferential Forwarding status ofActiveactive and UP/DOWN status "Pseudowire forwarding" and select PW2 as the new activepseudowirePW to which to sendtraffic to.traffic. Note that PE2 may have detected that the PW to PE1 went down via T-LDP Hello timeout or via other means. However, it will not be able to forward user traffic until it receives the updated status bit from PE3. Note that, in this example, the receipt of the AC status on the CE1-PE1 link is normally sufficient for PE2 to switch to PW2. However, the operator may want to trigger the switchover of the PW for administrative reasons, e.g.,maintenance, and thusmaintenance; thus, the use of the Preferential Forwarding status bit is required to notify PE2 to trigger the switchover. Note that the primary/secondary procedures do not apply in this case as the PW Preferential Forwarding status is driven by the AC forwardingstatestate, as determined by the AC dual-homing protocol used.15.2.A.2. MultipleMulti-homedMulti-Homed CEs withsingleSS-PWredundancyRedundancy |<-------------- Emulated Service ---------------->| | | | |<------- Pseudowire ------>| | | | | | | | |<-- PSN Tunnels-->| | | | V V (not shown) V V | V AC +----+ +----+ AC V +-----+ | |....|.......PW1........|....| | +-----+ | |----------| PE1|...... .........| PE3|----------| | | CE1 | +----+ \ / PW3 +----+ | CE2 | | | +----+ X +----+ | | | | | |....../ \..PW4....| | | | | |----------| PE2| | PE4|--------- | | +-----+ | |....|.....PW2..........|....| | +-----+ AC +----+ +----+ AC Figure15-23. MultipleMulti-homedMulti-Homed CEs withsingleSS-PWredundancyRedundancy The application in Figure15-23 makes use of theIndependentindependent mode of operation. CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed to PE3 and PE4. The method for dual-homing and the used protocols are outside the scope of this document. Note that the PSN tunnels are not shown in this figure for clarity. However, it can be assumed that each of the PWs shown is encapsulated in a separate PSN tunnel. Assume that the AC from CE1 to PE1 isActive,active and from CE1 to PE2 it isStandby;standby; furthermore, assume that the AC from CE2 to PE3 isStandbystandby and from CE2 to PE4 it isActive.active. The method of derivingActive/Standbythe active/standby status of the AC is outside the scope of this document. PE1 advertises thepreferentialPreferential Forwarding statusActiveactive and UP/DOWN status "Pseudowire forwarding" for pseudowires PW1 and PW4 connected to PE3 and PE4. This status reflects the forwarding state of the AC attached to PE1. PE2 advertisespreferentialPreferential Forwarding statusStandbystandby and UP/DOWN status "Pseudowire forwarding" for pseudowires PW2 and PW3 to PE3 and PE4. PE3 advertisespreferentialPreferential Forwarding statusStandbystandby and UP/DOWN status "Pseudowire forwarding" for pseudowires PW1 and PW3 to PE1 and PE2. PE4advertiseadvertises thepreferentialPreferential Forwarding statusActiveactive and UP/DOWN status "Pseudowire forwarding" for pseudowires PW2 and PW4 to PE2 andPE1PE1, respectively.ThusThus, by matching the local and remotepreferential forwardingPreferential Forwarding status ofActiveactive and UP/DOWN status of "Pseudowire forwarding" of pseudowires, the PE nodes determine which PW should be in theActiveactive state. In thiscasecase, it is PW4 that will be selected. On failure of the AC between CE1 and PE1, the forwarding state of the AC on PE2 is changed toActive.active. PE2 then announces the newly changed Preferential Forwarding status bit ofActiveactive to PE3 and PE4. PE1 will advertise a PW status notificationmessagemessage, indicating that the AC between CE1 and PE1 is down. PE2 and PE4 match the local and remotepreferential forwardingPreferential Forwarding status ofActiveactive and UP/DOWN status "Pseudowire forwarding" and select PW2 as the new activepseudowirePW to which to sendtraffic to.traffic. On failure of the PE1 node, PE2 will detectitthe failure and will transition the forwarding state of its AC toActive.active. The method by which PE2 detects that PE1 is down is outside the scope of this document. PE2 then announces the newly changed Preferential Forwarding status bit ofActiveactive to PE3 and PE4. PE2 and PE4 match the local and remotepreferential forwardingPreferential Forwarding status ofActiveactive and UP/DOWN status "Pseudowire forwarding" and select PW2 as the new activepseudowirePW to which to sendtraffic to.traffic. Note that PE3 and PE4 may have detected that the PW to PE1 went down via T-LDP Hello timeout or via other means. However, they will not be able to forward user traffic until they have received the updated status bit from PE2. Because each dual-homing algorithm running on the two node sets, i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects the active AC independently, there is a need to signal the active status of the AC such that the PE nodes can select a common active PW for end-to-end forwarding between CE1 and CE2 as per the procedures in the independent mode. Note thatanyno primary/secondary procedures, as defined insections 5.1.Sections 5.1 and5.2. 5.2 , do not5.2, apply in this use case as theActive/Standbyactive/standby status is driven by the AC forwardingstatestate, as determined by the ACdual-homingdual- homing protocol used.15.3. Multi-homedA.3. Multi-Homed CE with MS-PWredundancyRedundancy The following figure illustrates an application ofmulti-segment pseudowireMS-PW redundancy. Native |<-----------Pseudowire ------------->| Native Service | | Service (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) | V V V V V V | | +-----+ +-----+ +-----+ | +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ | |-------|......PW1-Seg1.......|PW1-Seg2.......|-------| | | | | |=========| |=========| | | | | CE1| +-----+ +-----+ +-----+ | | | | |.| +-----+ +-----+ | CE2| | | |.|===========| |=========| | | | | | |.....PW2-Seg1......|.PW2-Seg2......|-------| | +----+ |=============|S-PE2|=========|T-PE4| | +----+ +-----+ +-----+ AC Figure15-3 Multi-homed4. Multi-Homed CE with MS-PWredundancyRedundancy The application in Figure15-34 makes use of theIndependentindependent mode of operation. It extends the application described in Section 15.1. 15.1 of this document and in [8] by adding a pair of S-PE nodes to switch the segments of PW1 and PW2. CE2 is dual-homed to T-PE2 and T-PE4. PW1 and PW2 are used to extend the resilient connectivity all the way to T-PE1. PW1 has two segments and is an activepseudowirepseudowire, while PW2 has two segments and is a standby pseudowire. This application requires support for MS-PW with segments of the same type as described in [4]. The operation in this case is the same as in the case ofSS-PWSS-PW, as described in Section 15.1.15.1 .The only difference is that theS- PES-PE nodes need to relay the PW status notification containing both the UP/DOWN and forwarding status to the T-PE nodes.15.4. Multi-homedA.4. Multi-Homed CE with MS-PWredundancyRedundancy and S-PEprotectionProtection The following figure illustrates an application ofmulti-segment pseudowireMS-PW redundancy with 1:1 PW protection. Native |<-----------Pseudowire ------------->| Native Service | | Service (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) | V V V V V V | | +-----+ | | |=============| |=============| | | |.....PW3-Seg1......|.PW3-Seg2....| | | |.|===========|S-PE3|===========|.| | | |.| +-----+ |.| | | +-----+ +-----+ +-----+ | +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ | |-------|......PW1-Seg1.......|PW1-Seg2.......|-------| | | | | |=========| |=========| | | | | CE1| +-----+ +-----+ +-----+ | | | | |.| |.| +-----+ +-----+ | CE2| | | |.| |.|=========| |=========| | | | | | |.| |...PW2-Seg1......|.PW2-Seg2......|-------| | +----+ |.| |===========|S-PE2|=========|T-PE4| | +----+ |.| +-----+ +-----+ AC |.| +-----+ |.| |.|=============| |===========|.| |.......PW4-Seg1......|.PW4-Seg2....| |===============|S-PE4|=============| +-----+ Figure15-4 Multi-homed5. Multi-Homed CE with MS-PWredundancyRedundancy andprotectionProtection The application in Figure15-45 makes use of theIndependentindependent mode of operation. CE2 is dual-homed to T-PE2 and T-PE4. The PW pairs {PW1,PW3} and{PW2, PW4}{PW2,PW4} are used to extend the resilient connectivity all the way to T-PE1, like in the case in Section15.3. 15.3 ,15.3, with the addition that this setup provides for S-PE node protection. CE1 is connected to T-PE1 while CE2 is dual-homed to T-PE2 and T-PE4. There are four segmented PWs. PW1 and PW2 are primary PWs and are used to support CE2 multi-homing. PW3 and PW4 are secondary PWs and are used to support 1:1 PW protection. PW1, PW2,PW3PW3, and PW4 have two segments and they are switched atS- PE1,S-PE1, S-PE2,S-PE3S-PE3, andS-PE4S-PE4, respectively. It is possible that S-PE1 coincides with S-PE4 and/or SP-2 coincides with S-PE3, inparticularparticular, where the two PSN domains are interconnected via two nodes.HoweverHowever, Figure15-45 shows four separate S-PE nodes for clarity. The behavior of this setup is exactly the same asinthe setup in Section15.3.15.3 except that T-PE1 will always see a pair of PWs eligible for the active state, forexampleexample, the pair {PW1,PW3} when the AC between CE2 and T-PE2 is in active state. Thus, it is important that both T-PE1 and T-PE2 implement a common mechanism to choose one the two PWs forforwardingforwarding, as explained in Section 5.1. Similarly,T-PE1T- PE1 and T-PE4 must use the same mechanism to select among the pair{PW2, PW4}{PW2,PW4} when the AC between CE2 and T-PE4 is in active state.15.5. Single HomedA.5. Single-Homed CE with MS-PWredundancyRedundancy The following is an application of the independent mode ofoperationoperation, along with the request switchover procedures in order to provide N:1 PW protection. A revertive behavior to a primary PW is shown as an example of configuring and using the primary/secondary procedures described insectionsSections 5.1.5.1and 5.2.5.2 .Native |<------------Pseudowire ------------>| Native Service | | Service (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) | V V V V V V | | +-----+ +-----+ +-----+ | +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | | CE1| | |=========| |=========| | | CE2| | | +-----+ +-----+ +-----+ | | +----+ |.||.| |.||.| +----+ |.||.| +-----+ |.||.| |.||.|=========| |========== .||.| |.||...PW2-Seg1......|.PW2-Seg2...||.| |.| ===========|S-PE2|============ |.| |.| +-----+ |.| |.|============+-----+============= .| |.....PW3-Seg1.| | PW3-Seg2......| ==============|S-PE3|=============== | | +-----+ Figure15-5 Single homed6. Single-Homed CE withmulti-segment pseudowire redundancyMS-PW Redundancy CE1 is connected to PE1 in providerEdgeedge 1 and CE2 to PE2 in provider edge22, respectively. There are three segmentedPWs. APWs: a primary PW, PW1, is switched atS-PE1. A primary PW, PW1S-PE1 and has the lowest precedence value ofzero. Azero; a secondary PW, PW2, which is switched at S-PE2 and has a precedence of1. Finally,1; and another secondary PW, PW3, which is switched at S-PE3 and has a precedence of 2. The precedence is locally configured at the endpoints of the PW, i.e., T-PE1 and T-PE2.LowerThe lower the precedence value, the higher the priority. T-PE1 and T-PE2 will select the PW they intend to activate based on their local and remote UP/DOWNstatestate, as well as the local precedence configuration. In this case, they will both advertise PreferentialForwarding'Forwarding status bit ofActiveactive on PW1 and ofStandbystandby on PW2 and PW3 using priority derived from local precedence configuration. Assuming all PWs are up, T-PE1 and T-PE2 will use PW1 to forward user packets. If PW1 fails, then the T-PE detecting the failure will send a status notification to the remote T-PE with a"LocalLocal PSN-facing PW (ingress) ReceiveFault"Fault bit set,ora"LocalLocal PSN-facing PW (egress) TransmitFault"Fault bit set, or a"PseudowirePseudowire NotForwarding"Forwarding bit set. In addition, it will set the Preferential Forwarding status bit on PW1 toStandby.standby. It will also advertise the Preferential Forwarding status bit on PW2 asActiveactive, as it has thenext lowestnext-lowest precedence value. T-PE2 will also perform the same steps as soon as it is informed of the failure of PW1. Both T-PE nodes will perform a match on the'preferential forwarding'Preferential Forwarding status ofActiveactive and UP/DOWN status of "Pseudowire forwarding" and will use PW2 to forward user packets.HoweverHowever, this does not guarantee that the T-PEs will choose the same PW from the redundant set to forward on, for a given emulated service, at all times. This may be due to a mismatch of the configuration of the PW precedence in each T-PE. This may also be due to a failurewhichthat caused the endpoints to not be able to match theActiveactive Preferential Forwarding status bit and UP/DOWN status bits. In this case, T-PE1 and/or T-PE2 can invoke the request switchover/acknowledgement procedures to synchronize the choice of PW to forward on in both directions. The trigger for sending a request toswitchoverswitch over can also be the execution of an administrative maintenance operation by the network operator in order to move the traffic away from the T-PE/S-PEnodes /linksnodes/links to be serviced. In case the'request switchover'Request Switchover is sent by both endpoints simultaneously, both T-PEs send status notification with the newly selected PW with'request switchover'Request Switchover bit set, waiting for a response from the other endpoint. In such a situation, the T-PE with greater system address request is given precedence. This helps in synchronizing PWs in the event of mismatch of precedence configuration as well. On recovery of the primaryPW1,PW, PW1 is selected to forward traffic and the secondary PW, PW2, is set to standby.15.6.A.6. PWredundancyRedundancy between H-VPLS MTU-s and PE-rsFollowingThe following figure illustrates the application of use of PW redundancy in H-VPLS for the purpose of dual-homing an MTU-s node to PE nodes using PW spokes. This application makes use of theMaster/Slavemaster/slave mode of operation. PE1-rs +--------+ | VSI | Active PW | -- | Group..........|../ \..|. CE-1 . | \ / | . \ . | -- | . \ . +--------+ . \ MTU-s . . . PE3-rs +--------+ . . . +--------+ | VSI | . . H-VPlS .| VSI | | -- ..|.. . Core |.. -- | | / \ | . PWs | / \ | | \ /..|.. . | \ / | | -- | . . .|.. -- | +--------+ . . . +--------+ / . . . / . +--------+ . / . | VSI | . CE-2 . | -- | . ..........|../ \..|. Standby PW | \ / | Group | -- | +--------+ PE2-rsFigure 15-6 Multi-homedA.6. Multi-Homed MTU-s in H-VPLScoreCore MTU-s isdual homeddual-homed to PE1-rs and PE2-rs. The primary spoke PWs from MTU-s are connected toPE1-rsPE1-rs, while the secondary PWs are connected to PE2. PE1-rs and PE2-rs are connected to H-VPLS core on the other side of the network. MTU-s communicates to PE1-rs and PE2-rs the forwarding status of its member PWs for a set ofVSIsVirtual Switch Instances (VSIs) having common statusActive/Standby.active/standby. It may be signaled using PW grouping with a common group-id in the PWid FEC element or Grouping TLV in the Generalized PWid FECelementelement, as defined in [2] to scale better. MTU-s derives the status of the PWs based on local policy configuration. In this example, the primary/secondary procedures as defined in Section5.2.5.2 areusedused, but this can be based on any other policy. Whenever MTU-s performs a switchover, it sends a wildcardNotification Messagenotification message to PE2-rs for the previously standby PW group containing PW Status TLV with PW Preferential Forwarding bit cleared. On receiving thenotificationnotification, PE-2rs unblocks all member PWs identified by the PW group and the state of the PW group changes fromStandbystandby toActive.active. All procedures described in Section6.2.6.2 are applicable. The use of the Preferential Forwarding status bit inMaster/Slavemaster/slave mode is similar to Topology Change Notification inRSTP controlledthe IEEE Ethernet Bridges controlled by Rapid Spanning Tree Protocol (RSTP) but is restricted over a single hop. When these procedures are implemented, PE-rs devices are aware of switchovers at MTU-s and could generate MAC WithdrawMessagesmessages to trigger MAC flushing within the H-VPLS full mesh. By default, MTU-s devices should still trigger MAC Withdrawmessagesmessages, as currently defined in[3][3], to prevent two copies of MACwithdraws to be sent,Withdraws being sent: one by MTU-s and another one by PE-rs nodes. Mechanisms to disable a MAC Withdraw trigger in certain devices is out of the scope of thisdocumentdocument. Authors' Addresses Praveen Muley Alcatel-lucent 701 E. Middlefield Road Mountain View, CA, 94043, USAEmail:EMail: praveen.muley@alcatel-lucent.com Mustapha Aissaoui Alcatel-lucent 600 March Rd Kanata, ON, Canada K2K 2E6Email:EMail: mustapha.aissaoui@alcatel-lucent.com