GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6870

Internet Engineering Task Force (IETF) P. Muley, Ed. Request for Comments: 6870 M. Aissaoui, Ed. Updates: 4447 Alcatel-Lucent Category: Standards Track February 2013 ISSN: 2070-1721

           Pseudowire Preferential Forwarding Status Bit

Abstract

 This document describes a mechanism for signaling the active and
 standby status of redundant Pseudowires (PWs) between their
 termination points.  A set of Redundant PWs is configured between
 Provider Edge (PE) nodes in single-segment pseudowire (SS-PW)
 applications or between Terminating Provider Edge (T-PE) nodes in
 Multi-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 a Preferential Forwarding status with a
 value of active or standby 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 PW status code bits in the PW Status TLV.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6870.

Muley & Aissaoui Standards Track [Page 1] RFC 6870 PW Preferential Forwarding Status Bit February 2013

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.

Muley & Aissaoui Standards Track [Page 2] RFC 6870 PW Preferential Forwarding Status Bit February 2013

Table of Contents

 1. Introduction ....................................................4
    1.1. Requirements Language ......................................4
 2. Motivation and Scope ............................................4
 3. Terminology .....................................................7
 4. PE Architecture .................................................9
 5. Modes of Operation ..............................................9
    5.1. Independent Mode ...........................................9
    5.2. Master/Slave Mode .........................................12
 6. PW State Transition Signaling Procedures .......................14
    6.1. PW Standby Notification Procedures in Independent Mode ....14
    6.2. PW Standby Notification Procedures in Master/Slave Mode ...15
         6.2.1. PW State Machine ...................................16
    6.3. Coordination of PW Switchover .............................17
         6.3.1. Procedures at the Requesting Endpoint ..............18
         6.3.2. Procedures at the Receiving Endpoint ...............20
 7. Status Mapping .................................................20
    7.1. AC Defect State Entry/Exit ................................21
    7.2. PW Defect State Entry/Exit ................................21
 8. Applicability and Backward Compatibility .......................21
 9. Security Considerations ........................................22
 10. MIB Considerations ............................................22
 11. IANA Considerations ...........................................22
    11.1. Status Code for PW Preferential Forwarding Status ........22
    11.2. Status Code for PW Request Switchover Status .............23
 12. Contributors ..................................................23
 13. Acknowledgments ...............................................24
 14. References ....................................................24
    14.1. Normative References .....................................24
    14.2. Informative References ...................................24
  Appendix A. Applications of PW Redundancy Procedures .............26
    A.1. One Multi-Homed CE with Single SS-PW Redundancy ...........26
    A.2. Multiple Multi-Homed CEs with SS-PW Redundancy ............28
    A.3. Multi-Homed CE with MS-PW Redundancy ......................30
    A.4. Multi-Homed CE with MS-PW Redundancy and S-PE Protection ..31
    A.5. Single-Homed CE with MS-PW Redundancy .....................32
    A.6. PW Redundancy between H-VPLS MTU-s and PE-rs ..............33

Muley & Aissaoui Standards Track [Page 3] RFC 6870 PW Preferential Forwarding Status Bit February 2013

1. Introduction

 This document provides the extensions to the Pseudowire (PW) control
 plane to support the protection schemes of the PW redundancy
 applications described in RFC 6718, "Pseudowire (PW) Redundancy" [8].
 It specifies a new PW status bit as well as the procedures Provider
 Edge (PE) nodes follow to notify one another of the Preferential
 Forwarding state of each PW in the redundant 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.
 Section 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 PW Status TLV to indicate the state for an attachment
 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

Muley & Aissaoui Standards Track [Page 4] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 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 one that provides the
 end-to-end connectivity from Customer 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 and remotely,
 and a PE node needs to select a single PW to which to forward user
 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 status bit: the
 Preferential Forwarding status bit.  It also defines the procedures
 the PE nodes follow to indicate the Preferential 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 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, protect a specific subset of a path for the emulated
       service, consisting of an active PW and/or AC.

Muley & Aissaoui Standards Track [Page 5] RFC 6870 PW Preferential Forwarding Status Bit February 2013

    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 the
       independent mode of operation and is described in Section 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 in Sections 5.1. and 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. By configuration, implementations can designate one PW in the
       1:1 or N:1 protection as a primary PW and the remaining as
       secondary PWs.  If more than one PW qualifies for the active
       state, as defined in Sections 5.1 and 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 protection (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 given time, and advertises that PW to the
       remote endpoints.  Only a PW that is up and that indicated
       active 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. A master/slave mode in which one PW endpoint, the master
       endpoint, selects and dictates to the other endpoint(s), the
       slave endpoint(s), which PW to activate.  This is described in
       Section 5.2.

Muley & Aissaoui Standards Track [Page 6] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 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 of an SS-PW, or on a T-PE, in the case of an MS-PW.  PW
 redundancy scenarios where the redundant set of PW segments
 terminates on a 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 a
       Public 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 terminating PEs [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 PW that has been configured (label mapping exchanged between
       PEs) and is not showing any of the PW or AC status bits
       specified in [7].  Such a PW is available for forwarding
       traffic [8].
 Down PW: A PW that either has not been fully configured or has been
       configured and is showing any of the PW or AC status bits
       specified in [7]; such a PW is not available for forwarding
       traffic [8].
 Active PW:  An up PW used for forwarding user, OAM, and control plane
       traffic [8].
 Standby PW: An up PW that is not used for forwarding user traffic but
       may forward OAM and specific control plane traffic [8].
 Primary PW: The PW that 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 of primary 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.,

Muley & Aissaoui Standards Track [Page 7] RFC 6870 PW Preferential Forwarding Status Bit February 2013

       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 PW
       that has been configured as primary 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., an SS-PW PE, an MS-PW
       T-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 the 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.  Therefore,
       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.  Therefore, it is not 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.

Muley & Aissaoui Standards Track [Page 8] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 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

 Figure 1 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 to use 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<===========>
            |                 |                      |
            +----------------------------------------+
             Figure 1. PE Architecture for PW Redundancy

5. Modes of Operation

 There are two modes of operation for the use of the PW Preferential
 Forwarding status bits:
 o  independent mode
 o  master/slave mode

5.1. Independent Mode

 PW endpoint nodes independently select which PWs are eligible to
 become active and which are not.  They advertise the corresponding
 active or standby Preferential Forwarding status for each PW.  Each
 PW endpoint compares local and remote status bits and uses the PW

Muley & Aissaoui Standards Track [Page 9] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 that is up at both endpoints and that advertised active Preferential
 Forwarding status at both the local and remote endpoints.
 In this mode of operation, the Preferential 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 the active state, each PW endpoint
 MUST implement a common mechanism to choose the PW for forwarding.
 The default mechanism MUST be supported by all implementations, and
 it operates as follows:
 1. For a PW using the PWid ID Forwarding Equivalence Class (PWid FEC)
    [2], the PW with the lowest PWid value is selected.
 2. For a PW using the Generalized PWid FEC [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, the
    Source Attachment Individual Identifier (SAII) and Target
    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 of
    AGI::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 PW that
    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
    the PWid or AGI::SAII::TAII of the redundant PWs within the first
    and last segment are ordered consistently such that the same end-
    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 selection
 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.

Muley & Aissaoui Standards Track [Page 10] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 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 achieve tiebreaking using this mechanism.
 There are scenarios with dual-homing of a CE to PE nodes where each
 PE node needs to advertise active 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 to advertise 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 Section 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 the active/standby state of the PWs.  This could be
 caused by propagation delay of the Targeted 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.

Muley & Aissaoui Standards Track [Page 11] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 Thus, in this mode of operation, the following definition of active
 and standby PW states apply:
 o  Active State
 A PW is considered to be in active 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 its Preferential
 Forwarding status is active at both endpoints.  In this state user
 traffic can flow over the PW in both directions.  As described in
 Section 5.1, the PE nodes MUST implement a common mechanism to select
 one PW for forwarding in case multiple PWs qualify for the active
 state.
 o  Standby State
 A PW is considered to be in standby state when the PW labels are
 exchanged between its two endpoints, but the Preferential Forwarding
 status bits exchanged indicate the PW Preferential Forwarding status
 is standby at one or both endpoints.  In this state, the endpoints
 MUST NOT forward data traffic over the PW but MAY allow PW OAM
 packets, e.g., Virtual Connection Connectivity Verification (VCCV)
 packets [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 packets are outside the scope of this document.  If the PW is a
 spoke in H-VPLS, any Media Access Control (MAC) addresses learned via
 the PW SHOULD be flushed when it transitions to standby state,
 according to the procedures in RFC 4762 [3] and in [10].

5.2. Master/Slave Mode

 One endpoint node of the redundant set of PWs is designated the
 master and is responsible for selecting which PW both endpoints must
 use to forward user traffic.
 The master indicates the forwarding state in the PW Preferential
 Forwarding status bit.  The other endpoint node, the slave, MUST
 follow the decision of the master node based on the received status
 bits.  In other words, the Preferential Forwarding status bit sent by
 the master node indicates the actual forwarding state of the PW at
 the master node.
 There is a single PE master PW endpoint node and one or many PE PW
 endpoint slave nodes.  The assignment of master/slave roles to the PW
 endpoints is performed by local configuration.  Note that the
 behavior described in this section assumes correct configuration of

Muley & Aissaoui Standards Track [Page 12] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 the master and slave 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
 backup master node.  In deployments where PE node protection is
 required, it is recommended to use the independent mode of operation
 as in the application described in Section 15.2.
 One endpoint of the PW, the master, actively selects which PW to
 activate and uses it for forwarding user traffic.  This status is
 indicated to the slave node by setting the Preferential Forwarding
 status bit in the status bit TLV to 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 to standby for those PWs.  The master node
 MUST ignore any PW Preferential Forwarding status bits received from
 the slave nodes.
 If more than one PW qualifies for the active state, the master PW
 endpoint node selects one.  There is no requirement to specify a
 default active PW selection mechanism in this case; however, for
 consistency across implementations, the master PW endpoint SHOULD
 implement the default active PW selection mechanism described in
 Section 5.1.
 If the master PW endpoint implements the active PW selection
 mechanism based on primary/secondary and precedence parameters, it
 MUST comply 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.
 The slave endpoint(s) are required to act on the status bits received
 from the master.  When the received status bit transitions from
 active to standby, a slave node MUST stop forwarding over the
 previously active PW.  When the received status bit transitions from
 standby to active for a given PW, the slave node MUST start
 forwarding user traffic over this PW.

Muley & Aissaoui Standards Track [Page 13] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 In this mode of operation, the following definition of active and
 standby PW states apply:
 o  Active State
 A PW is considered to be in active 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
 the Preferential Forwarding status at the master endpoint is active.
 In this state, user traffic can flow over the PW in both directions.
 o  Standby State
 A PW is considered to be in standby state when the PW labels are
 exchanged between its two endpoints, and the status bits exchanged
 between the endpoints indicate the Preferential Forwarding status at
 the master endpoint is standby.  In this state, 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 packets are 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 [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 PW
 Preferential Forwarding status bit that 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 the preferred or actual active/standby forwarding state of the
 PW by one PE to the far-end PE.  The actual semantics of the value
 being signaled vary according to whether the PW is acting in
 master/slave or independent mode.

6.1. PW Standby Notification Procedures in Independent Mode

 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 preferred active/standby forwarding state for each PW.
 An active Preferential Forwarding state is indicated by clearing the
 PW Preferential Forwarding status bit in the PW Status TLV.  A
 standby Preferential Forwarding state is indicated by setting the PW

Muley & Aissaoui Standards Track [Page 14] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 Preferential Forwarding status bit in the PW Status 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 the PW, which is up at both endpoints and which
 shows both local active and remote active Preferential Forwarding
 states.  The PE nodes MUST implement a common mechanism to select one
 PW for forwarding in case multiple PWs qualify for the active state,
 as explained in Section 5.1.
 When a PW is in active state, the PEs can forward user packets, OAM
 packets, and other control plane packets over the PW.
 When a PW is in standby 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
 defined in [4].

6.2. PW Standby Notification Procedures in Master/Slave Mode

 Whenever the master PW endpoint selects or deselects a PW for
 forwarding user traffic at its end, it explicitly notifies the event
 to the remote slave 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 the master end is not
 used for forwarding and is thus kept in the standby state.  The PW
 MUST NOT be used for forwarding at slave endpoint.  Clearing the PW
 Preferential Forwarding bit in PW Status TLV indicates that the PW at
 the master endpoint is used for forwarding and is in active state,
 and the receiving slave 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 FEC element,
 as defined in [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 such grouping, a termination point sends a
 single "wildcard" notification message to denote this change in
 status for all affected PWs.  This status message contains either the

Muley & Aissaoui Standards Track [Page 15] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 PWid FEC TLV with only the Group ID or the 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 PW segments, 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 defined states, and the behavior is presented as a
 state transition table.  The same state machine is applicable to PW
 groups.

Muley & Aissaoui Standards Track [Page 16] RFC 6870 PW Preferential Forwarding Status Bit February 2013

    STATE         EVENT                                  NEW STATE
    ACTIVE        PW put in standby (master)             STANDBY
                  Action: Transmit PW Preferential
                          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 PW Preferential
                    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
      Table 1.  PW State Transition Table in Master/Slave Mode

6.3. Coordination of PW Switchover

 There are PW redundancy applications that 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 the independent mode procedures to use the PW, which
 is both up and for which both endpoints advertise an active
 Preferential Forwarding status bit.

Muley & Aissaoui Standards Track [Page 17] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 The trigger for sending a request to switchover by one endpoint of
 the MS-PW can be an operational event.  For example, a failure that
 causes the endpoints to be unable to find a common PW for which both
 endpoints advertise an active 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 a master/slave mode of operation, the endpoint
 requesting the switchover requires explicit acknowledgment 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
 to switch over.
 This document specifies a second status bit that is used by a PE to
 request that its peer PE switch over to use a different active PW.
 This bit is referred to as the Request Switchover status bit.  The
 Preferential Forwarding status bit continues to be used by each
 endpoint to indicate its current local settings of the active/standby
 state of each PW in the redundant set.  In other words, as in the
 independent 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 bit.  A PE that receives the
 Request Switchover bit and that does not support it will ignore it.
 If the 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 status bits between ingress and egress PW segments
 as per the procedures defined in [4].

6.3.1. Procedures at the Requesting Endpoint

 a. The requesting endpoint sends a Status TLV in the LDP notification
    message with the Request Switchover bit set on the PW to which it
    desires to switch.
 b. The endpoint does not activate, forwarding on that PW at this
    point in time.  It MAY, however, enable receiving on that PW.
    Thus, the Preferential Forwarding status bit still reflects the
    currently used PW.

Muley & Aissaoui Standards Track [Page 18] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 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. If, while waiting for the acknowledgment, the requesting endpoint
    receives a request from its peer to switch 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
          acknowledgment 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. If, while waiting for the acknowledgment, the requesting endpoint
    receives a status notification message from its peer with the
    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 status bit and the Request
          Switchover bit clear on the newly active PW and send an
          update status notification message with the Preferential
          Forwarding status bit set in the previously active PW.
 f. If, while waiting for the acknowledgment, the requesting endpoint
    detects that the requested PW went into down state locally, and
    could use an alternate PW that is up, it MUST perform the
    following:
       i. Abort the timer.
      ii. Issue a new request to switchover to the alternate PW.
     iii. Restart the timer.

Muley & Aissaoui Standards Track [Page 19] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 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 PW that 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 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 the Receiving Endpoint

 a. Upon receiving a status notification message with the 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 status bit clear and the 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 bit set on a PW, which is different from
          the currently active PW 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 PW Status 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.

Muley & Aissaoui Standards Track [Page 20] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 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 set that 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 set that 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 Section 8.3.1
 (Section 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
 PWs that 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

Muley & Aissaoui Standards Track [Page 21] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 PWid FEC element, each PW MUST have a unique identifier that consists
 of the triplet AGI::SAII::TAII.
 A PE implementation that uses the mechanisms described in this
 document MUST negotiate the use of PW Status TLV between its T-LDP
 peers, as per RFC 4447 [2].  If the PW Status TLV is found to be not
 supported by either of its endpoints after status negotiation
 procedures, then the mechanisms specified in this document cannot be
 used.
 A PE implementation that is compliant with RFC 4447 [2] and that does
 not support the generation or processing of the Preferential
 Forwarding status bit or of the Request Switchover status 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.
 Finally, 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 protect PWs must be implemented because
 the status bits defined in this document have the same security
 considerations as the PW setup and maintenance protocol defined in
 RFC 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.  IANA has allocated these from the
 "Pseudowire Status Codes Registry".

11.1. Status Code for PW Preferential Forwarding Status

 0x00000020 When the bit is set, it indicates PW forwarding standby".
            When the bit is cleared, it indicates PW forwarding
            active".

Muley & Aissaoui Standards Track [Page 22] RFC 6870 PW Preferential Forwarding Status Bit February 2013

11.2. Status Code for PW Request Switchover Status

 0x00000040 When the bit is set, it represents 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-Lucent
 EMail: matthew.bocci@alcatel-lucent.com
 Pranjal Kumar Dutta
 Alcatel-Lucent
 EMail: pranjal.dutta@alcatel-lucent.com
 Giles Heron
 Cisco Systems, Inc.
 giles.heron@gmail.com
 Marc Lasserre
 Alcatel-Lucent
 EMail: marc.lasserre@alcatel-lucent.com
 Luca Martini
 Cisco Systems, Inc.
 EMail: lmartini@cisco.com
 Thomas Nadeau
 Juniper Networks
 EMail: tnadeau@lucidvision.com
 Jonathan Newton
 Cable & Wireless Worldwide
 EMail: Jonathan.Newton@cw.com
 Hamid Ould-Brahim
 EMail: ouldh@yahoo.com
 Olen Stokes
 Extreme Networks
 EMail: ostokes@extremenetworks.com

Muley & Aissaoui Standards Track [Page 23] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 Daniel Cohn
 Orckit
 daniel.cohn.ietf@gmail.com.

13. Acknowledgments

 The authors would like to thank the following individuals for their
 valuable comments and suggestions, 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., Ed., Rosen, E., El-Aawar, N., Smith, T., and G.
       Heron, "Pseudowire Setup and Maintenance Using the Label
       Distribution Protocol (LDP)", RFC 4447, April 2006.
 [3]   Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN
       Service (VPLS) Using Label Distribution Protocol (LDP)
       Signaling", RFC 4762, January 2007.
 [4]   Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui,
       "Segmented Pseudowire", RFC 6073, January 2011.
 [5]   Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., Nadeau,
       T., and Y(J). Stein, "Pseudowire (PW) Operations,
       Administration, and Maintenance (OAM) Message Mapping", RFC
       6310, July 2011.

14.2. Informative References

 [6]   Bocci, M. and S. Bryant, "An Architecture for Multi-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., Aissaoui, M., and M. Bocci, "Pseudowire Redundancy",
       RFC 6718, August 2012.

Muley & Aissaoui Standards Track [Page 24] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 [9]   Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-
       to-Edge (PWE3) Architecture", RFC 3985, March 2005.
 [10]  Dutta, P., Balus, F., Calvignac, G., and O. Stokes "LDP
       Extensions for Optimized MAC Address Withdrawal in H-VPLS",
       Work in Progress, October 2011.
 [11]  Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual
       Circuit Connectivity Verification (VCCV): A Control Channel for
       Pseudowires", RFC 5085, December 2007.

Muley & Aissaoui Standards Track [Page 25] RFC 6870 PW Preferential Forwarding Status Bit February 2013

Appendix 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 in "PW Redundancy" [8].

A.1. One Multi-Homed CE with Single SS-PW Redundancy

 The following figure illustrates an application of SS-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    +----+                  +----+
        Figure 2.  Multi-Homed CE with SS-PW Redundancy
 The application in Figure 2 makes use of the independent mode of
 operation.
 CE1 is dual-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
 advertise an active and standby Preferential Forwarding status bit,
 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 of active on both PW1 and PW2,
 since the AC to CE2 is single-homed.  As both the local and remote
 UP/DOWN status and Preferential Forwarding status for PW1 are up and
 active, traffic is forwarded over PW1 in both directions.

Muley & Aissaoui Standards Track [Page 26] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 On failure of the AC between CE1 and PE1, the forwarding state of the
 AC on PE3 transitions to active.  PE3 then announces the newly
 changed Preferential Forwarding status bit of active to PE2.  PE1
 will advertise a PW status notification message, indicating that the
 AC between CE1 and PE1 is down.  PE2 matches the local and remote
 Preferential Forwarding status of active and status of "Pseudowire
 forwarding" and selects PW2 as the new active PW to which to send
 traffic.
 On failure of the PE1 node, PE3 will detect it and will transition
 the forwarding state of its AC to 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
 of active to PE2.  PE3 and PE2 match the local and remote
 Preferential Forwarding status of active and UP/DOWN status
 "Pseudowire forwarding" and select PW2 as the new active PW to which
 to send 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; 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
 forwarding state, as determined by the AC dual-homing protocol used.

Muley & Aissaoui Standards Track [Page 27] RFC 6870 PW Preferential Forwarding Status Bit February 2013

A.2. Multiple Multi-Homed CEs with SS-PW Redundancy

           |<-------------- 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
          Figure 3. Multiple Multi-Homed CEs with SS-PW Redundancy
 The application in Figure 3 makes use of the independent 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 is active and from CE1 to PE2 it
 is standby; furthermore, assume that the AC from CE2 to PE3 is
 standby and from CE2 to PE4 it is active.  The method of deriving the
 active/standby status of the AC is outside the scope of this
 document.
 PE1 advertises the Preferential Forwarding status active 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 advertises Preferential Forwarding status
 standby and UP/DOWN status "Pseudowire forwarding" for pseudowires
 PW2 and PW3 to PE3 and PE4.  PE3 advertises Preferential Forwarding
 status standby and UP/DOWN status "Pseudowire forwarding" for
 pseudowires PW1 and PW3 to PE1 and PE2.  PE4 advertises the
 Preferential Forwarding status active and UP/DOWN status "Pseudowire
 forwarding" for pseudowires PW2 and PW4 to PE2 and PE1, respectively.
 Thus, by matching the local and remote Preferential Forwarding status
 of active and UP/DOWN status of

Muley & Aissaoui Standards Track [Page 28] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 "Pseudowire forwarding" of pseudowires, the PE nodes determine which
 PW should be in the active state.  In this case, 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 to active.  PE2 then announces the newly changed
 Preferential Forwarding status bit of active to PE3 and PE4.  PE1
 will advertise a PW status notification message, indicating that the
 AC between CE1 and PE1 is down.  PE2 and PE4 match the local and
 remote Preferential Forwarding status of active and UP/DOWN status
 "Pseudowire forwarding" and select PW2 as the new active PW to which
 to send traffic.
 On failure of the PE1 node, PE2 will detect the failure and will
 transition the forwarding state of its AC to 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 of active to PE3 and PE4.  PE2 and PE4 match
 the local and remote Preferential Forwarding status of active and
 UP/DOWN status "Pseudowire forwarding" and select PW2 as the new
 active PW to which to send 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 that no primary/secondary procedures, as defined in Sections 5.1
 and 5.2, apply in this use case as the active/standby status is
 driven by the AC forwarding state, as determined by the AC dual-
 homing protocol used.

Muley & Aissaoui Standards Track [Page 29] RFC 6870 PW Preferential Forwarding Status Bit February 2013

A.3. Multi-Homed CE with MS-PW Redundancy

 The following figure illustrates an application of MS-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
            Figure 4.  Multi-Homed CE with MS-PW Redundancy
 The application in Figure 4 makes use of the independent 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 active pseudowire, 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 of SS-PW, as
 described in Section 15.1.  The only difference is that the S-PE
 nodes need to relay the PW status notification containing both the
 UP/DOWN and forwarding status to the T-PE nodes.

Muley & Aissaoui Standards Track [Page 30] RFC 6870 PW Preferential Forwarding Status Bit February 2013

A.4. Multi-Homed CE with MS-PW Redundancy and S-PE Protection

 The following figure illustrates an application of MS-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|=============|
                              +-----+
    Figure 5.  Multi-Homed CE with MS-PW Redundancy and Protection
 The application in Figure 5 makes use of the independent mode of
 operation.
 CE2 is dual-homed to T-PE2 and T-PE4.  The PW pairs {PW1,PW3} and
 {PW2,PW4} are used to extend the resilient connectivity all the way
 to T-PE1, like in the case in Section 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, PW3, and PW4 have
 two segments and they are switched at S-PE1, S-PE2, S-PE3, and S-PE4,
 respectively.

Muley & Aissaoui Standards Track [Page 31] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 It is possible that S-PE1 coincides with S-PE4 and/or SP-2 coincides
 with S-PE3, in particular, where the two PSN domains are
 interconnected via two nodes.  However, Figure 5 shows four separate
 S-PE nodes for clarity.
 The behavior of this setup is exactly the same as the setup in
 Section 15.3 except that T-PE1 will always see a pair of PWs eligible
 for the active state, for example, 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 for forwarding, as explained in Section 5.1.  Similarly,
 T-PE1 and T-PE4 must use the same mechanism to select among the pair
 {PW2,PW4} when the AC between CE2 and T-PE4 is in active state.

A.5. Single-Homed CE with MS-PW Redundancy

 The following is an application of the independent mode of operation,
 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 in Sections 5.1. and 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|===============
                              |     |
                              +-----+
           Figure 6.  Single-Homed CE with MS-PW Redundancy
 CE1 is connected to PE1 in provider edge 1 and CE2 to PE2 in provider
 edge 2, respectively.  There are three segmented PWs:  a primary PW,
 PW1, is switched at S-PE1 and has the lowest precedence value of

Muley & Aissaoui Standards Track [Page 32] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 zero; a secondary PW, PW2, which is switched at S-PE2 and has a
 precedence of 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.  The 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/DOWN state, as well as the local precedence
 configuration.  In this case, they will both advertise Preferential
 Forwarding status bit of active on PW1 and of standby 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 Local PSN-facing PW (ingress)
 Receive Fault bit set, a Local PSN-facing PW (egress) Transmit Fault
 bit set, or a Pseudowire Not Forwarding bit set.  In addition, it
 will set the Preferential Forwarding status bit on PW1 to standby.
 It will also advertise the Preferential Forwarding status bit on PW2
 as active, as it has the next-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 status of active and UP/DOWN status of "Pseudowire
 forwarding" and will use PW2 to forward user packets.
 However, 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 failure that caused the endpoints to not be able to match
 the active Preferential Forwarding status bit and UP/DOWN status
 bits.  In this case, T-PE1 and/or T-PE2 can invoke the request
 switchover/acknowledgment procedures to synchronize the choice of PW
 to forward on in both directions.
 The trigger for sending a request to switch 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-PE
 nodes/links to be serviced.
 In case the Request Switchover is sent by both endpoints
 simultaneously, both T-PEs send status notification with the newly
 selected PW with Request Switchover bit set, waiting for a response
 from the other endpoint.  In such a situation, the T-PE with greater

Muley & Aissaoui Standards Track [Page 33] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 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 primary PW, PW1 is selected to forward traffic and
 the secondary PW, PW2, is set to standby.

A.6. PW Redundancy between H-VPLS MTU-s and PE-rs

 The 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 the
 master/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-rs
        A.6.  Multi-Homed MTU-s in H-VPLS Core
 MTU-s is dual-homed to PE1-rs and PE2-rs.  The primary spoke PWs from
 MTU-s are connected to PE1-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 of Virtual Switch
 Instances (VSIs) having common status active/standby.  It may be

Muley & Aissaoui Standards Track [Page 34] RFC 6870 PW Preferential Forwarding Status Bit February 2013

 signaled using PW grouping with a common group-id in the PWid FEC
 element or Grouping TLV in the Generalized PWid FEC element, 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 Section 5.2 are used, but
 this can be based on any other policy.
 Whenever MTU-s performs a switchover, it sends a wildcard
 notification message to PE2-rs for the previously standby PW group
 containing PW Status TLV with PW Preferential Forwarding bit cleared.
 On receiving the notification, PE-2rs unblocks all member PWs
 identified by the PW group and the state of the PW group changes from
 standby to active.  All procedures described in Section 6.2 are
 applicable.
 The use of the Preferential Forwarding status bit in master/slave
 mode is similar to Topology Change Notification in the 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 Withdraw messages to trigger MAC flushing within the H-VPLS full
 mesh.  By default, MTU-s devices should still trigger MAC Withdraw
 messages, as currently defined in [3], to prevent two copies of MAC
 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 this document.

Authors' Addresses

 Praveen Muley
 Alcatel-lucent
 701 E. Middlefield Road
 Mountain View, CA, 94043, USA
 EMail: praveen.muley@alcatel-lucent.com
 Mustapha Aissaoui
 Alcatel-lucent
 600 March Rd
 Kanata, ON, Canada K2K 2E6
 EMail: mustapha.aissaoui@alcatel-lucent.com

Muley & Aissaoui Standards Track [Page 35]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6870.txt · Last modified: 2013/02/20 21:16 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki