summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6718.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6718.txt')
-rw-r--r--doc/rfc/rfc6718.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc6718.txt b/doc/rfc/rfc6718.txt
new file mode 100644
index 0000000..6df2c4d
--- /dev/null
+++ b/doc/rfc/rfc6718.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) P. Muley
+Request for Comments: 6718 M. Aissaoui
+Category: Informational M. Bocci
+ISSN: 2070-1721 Alcatel-Lucent
+ August 2012
+
+
+ Pseudowire Redundancy
+
+Abstract
+
+ This document describes a framework comprised of a number of
+ scenarios and associated requirements for pseudowire (PW) redundancy.
+ A set of redundant PWs is configured between provider edge (PE) nodes
+ in single-segment PW applications or between terminating PE (T-PE)
+ nodes in multi-segment 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 PW status is required to indicate the
+ preferential forwarding status of active or standby for each PW in
+ the redundant set.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ 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). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see 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/rfc6718.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muley, et al. Informational [Page 1]
+
+RFC 6718 PW Redundancy August 2012
+
+
+Copyright Notice
+
+ Copyright (c) 2012 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.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................4
+ 2.1. Requirements Language ......................................6
+ 3. Reference Models ................................................6
+ 3.1. PE Architecture ............................................6
+ 3.2. PW Redundancy Network Reference Scenarios ..................7
+ 3.2.1. PW Redundancy for AC and PE Protection: One
+ Dual-Homed CE with Redundant SS-PWs .................7
+ 3.2.2. PW Redundancy for AC and PE Protection: Two
+ Dual-Homed CEs with Redundant SS-PWs ................8
+ 3.2.3. PW Redundancy for S-PE Protection:
+ Single-Homed CEs with Redundant MS-PWs .............10
+ 3.2.4. PW Redundancy for PE-rs Protection in
+ H-VPLS Using SS-PWs ................................11
+ 3.2.5. PW Redundancy for PE Protection in a VPLS
+ Ring Using SS-PWs ..................................13
+ 3.2.6. PW Redundancy for VPLS n-PE Protection
+ Using SS-PWs .......................................14
+ 4. Generic PW Redundancy Requirements .............................15
+ 4.1. Protection Switching Requirements .........................15
+ 4.2. Operational Requirements ..................................15
+ 5. Security Considerations ........................................16
+ 6. Contributors ...................................................16
+ 7. Acknowledgements ...............................................17
+ 8. References .....................................................17
+ 8.1. Normative References ......................................17
+ 8.2. Informative Reference .....................................18
+
+
+
+
+
+
+
+Muley, et al. Informational [Page 2]
+
+RFC 6718 PW Redundancy August 2012
+
+
+1. Introduction
+
+ The objective of pseudowire (PW) redundancy is to maintain
+ connectivity across the packet switched network (PSN) used by the
+ emulated service if a component in the path of the emulated service
+ fails or a backup component is activated. For example, PW redundancy
+ will enable the correct PW to be used for forwarding emulated service
+ packets when the connectivity of an attachment circuit (AC) changes
+ due to the failure of an AC or when a pseudowire (PW) or packet
+ switched network (PSN) tunnel fails due to the failure of a provider
+ edge (PE) node.
+
+ PW redundancy uses redundant ACs, PEs, and PWs to eliminate single
+ points of failure in the path of an emulated service. This is
+ achieved while ensuring that only one path between a pair of customer
+ edge (CE) nodes is active at any given time. Mechanisms that rely on
+ more than one active path between the CEs, e.g., 1+1 protection
+ switching, are out of the scope of this document because they may
+ require a permanent bridge to provide traffic replication as well as
+ support for a 1+1 protection switching protocol in the CEs.
+
+ Protection for a PW segment can be provided by the PSN layer. This
+ may be a Resource Reservation Protocol with Traffic Engineering
+ (RSVP-TE) label switched path (LSP) with a fast-reroute (FRR) backup
+ or an end-to-end backup LSP. These mechanisms can restore PSN
+ connectivity rapidly enough to avoid triggering protection by PW
+ redundancy. PSN protection mechanisms cannot protect against the
+ failure of a PE node or the failure of the remote AC. Typically,
+ this is supported by dual-homing a CE node to different PE nodes that
+ provide a pseudowire emulated service across the PSN. A set of PW
+ mechanisms that enables a primary and one or more backup PWs to
+ terminate on different PE nodes is therefore required. An important
+ requirement is that changes occurring on the dual-homed side of the
+ network due to the failure of an AC or PE are not propagated to the
+ ACs on the other side of the network. Furthermore, failures in the
+ PSN are not propagated to the attached CEs.
+
+ In cases where PSN protection mechanisms are not able to recover from
+ a PSN failure or where a failure of a switching PE (S-PE) may occur,
+ a set of mechanisms that supports the operation of a primary and one
+ or more backup PWs via a different set of S-PEs or diverse PSN
+ tunnels is therefore required. For multi-segment PWs (MS-PWs), the
+ paths of these PWs are diverse in that they are switched at different
+ S-PE nodes.
+
+
+
+
+
+
+
+Muley, et al. Informational [Page 3]
+
+RFC 6718 PW Redundancy August 2012
+
+
+ In both of these cases, PW redundancy is important to maximize the
+ resiliency of the emulated service. It supplements PSN protection
+ techniques and can operate in addition to or instead of those
+ techniques when they are not available.
+
+ This document describes a framework for these applications and
+ associated operational requirements. The framework utilizes a new PW
+ status, called the 'Preferential Forwarding Status' of the PW. This
+ is separate from the operational states defined in RFC 5601
+ [RFC5601]. The mechanisms for PW redundancy are modeled on general
+ protection switching principles.
+
+2. Terminology
+
+ o Up PW: A PW that has been configured (label mapping exchanged
+ between PEs) and is not in any of the PW or AC defect states
+ represented by the status codes specified in [RFC4446]. Such a PW
+ is available for forwarding traffic.
+
+ o Down PW: A PW that either has not been fully configured or has
+ been configured and is in any one of the PW or AC defect states
+ specified in [RFC4446]. Such a PW is not available for forwarding
+ traffic.
+
+ o Active PW: An up PW used for forwarding Operations,
+ Administration, and Maintenance (OAM) as well as user-plane and
+ control-plane traffic.
+
+ o Standby PW: An up PW that is not used for forwarding user traffic
+ but may forward OAM and specific control-plane traffic.
+
+ o PW Endpoint: A PE where a PW terminates on a point where native
+ service processing is performed, e.g., a single-segment PW (SS-PW)
+ PE, a multi-segment pseudowire (MS-PW) terminating PE (T-PE), or a
+ hierarchical Virtual Private LAN Service (VPLS) MTU-s or PE-rs.
+
+ o Primary PW: The PW that a PW endpoint activates (i.e., uses for
+ forwarding) in preference to any other PW when more than one PW
+ qualifies for the active state. When the primary PW comes back up
+ after a failure and qualifies for the 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 behavior is used and is not applicable
+ when non-revertive protection switching is used.
+
+
+
+
+
+
+
+Muley, et al. Informational [Page 4]
+
+RFC 6718 PW Redundancy August 2012
+
+
+ o Secondary PW: When it qualifies for the 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.
+
+ o Revertive protection switching: Traffic will be carried by the
+ primary PW if all of the following is true: it is up, a wait-to-
+ restore timer expires, and the primary PW is made the active PW.
+
+ o Non-revertive protection switching: Traffic will be carried by the
+ last PW selected as a result of a previous active PW entering the
+ operationally down state.
+
+ o Manual selection of a PW: The ability to manually select the
+ primary/secondary PWs.
+
+ o MTU-s: A hierarchical virtual private LAN service multi-tenant
+ unit switch, as defined in RFC 4762 [RFC4762].
+
+ o PE-rs: A hierarchical virtual private LAN service switch, as
+ defined in RFC 4762.
+
+ o n-PE: A network-facing provider edge node, as defined in RFC 4026
+ [RFC4026].
+
+ o 1:1 protection: 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. User traffic
+ is transmitted over only one specific subset of the path at a
+ time.
+
+ o N:1 protection: N specific subsets of paths for an emulated
+ service, consisting of standby PWs and/or ACs, protect another
+ specific subset of the path for the emulated service. User
+ traffic is transmitted over only one specific subset of the path
+ at a time.
+
+ o 1+1 protection: 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. Traffic is
+ permanently duplicated at the ingress node on both the currently
+ active and standby subsets of the paths.
+
+
+
+
+
+
+
+
+Muley, et al. Informational [Page 5]
+
+RFC 6718 PW Redundancy August 2012
+
+
+ This document uses the term 'PE' to be synonymous with both PEs as
+ per RFC 3985 [RFC3985] and T-PEs as per RFC 5659 [RFC5659].
+
+ This document uses the term 'PW' to be synonymous with both PWs as
+ per RFC 3985 and SS-PWs, MS-PWs, and PW segments as per RFC 5659.
+
+2.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 [RFC2119].
+
+3. Reference Models
+
+ The following sections show the reference architecture of the PE for
+ PW redundancy and the usage of the architecture in different
+ topologies and applications.
+
+3.1. 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 [RFC3985]. 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
+
+
+
+
+
+
+
+
+Muley, et al. Informational [Page 6]
+
+RFC 6718 PW Redundancy August 2012
+
+
+3.2. PW Redundancy Network Reference Scenarios
+
+ This section presents a set of reference scenarios for PW redundancy.
+ These reference scenarios represent example network topologies that
+ illustrate the use of PW redundancy. They can be combined together
+ to create more complex or comprehensive topologies, as required by a
+ particular application or deployment.
+
+3.2.1. PW Redundancy for AC and PE Protection: One Dual-Homed CE with
+ Redundant SS-PWs
+
+ Figure 2 illustrates an application of single-segment pseudowire
+ redundancy where one of the CEs is dual-homed. This scenario is
+ designed to protect the emulated service against a failure of one of
+ the PEs or ACs attached to the multi-homed CE. Protection against
+ failures of the PSN tunnels is provided using PSN mechanisms such as
+ MPLS fast reroute, so that these failures do not impact the PW.
+
+ CE1 is dual-homed to PE1 and PE3. A dual-homing control protocol,
+ the details of which are outside the scope of this document, enables
+ the PEs and CEs to determine which PE (PE1 or PE3) should forward
+ towards CE1 and therefore which AC CE1 should use to forward towards
+ the PSN.
+
+ |<-------------- Emulated Service ---------------->|
+ | |
+ | |<------- Pseudo Wire ------>| |
+ | | | |
+ | | |<-- PSN Tunnels-->| | |
+ | V V V V |
+ V AC +----+ +----+ AC V
+ +-----+ | | PE1|==================| | | +-----+
+ | |----------|....|...PW1.(active)...|....|----------| |
+ | | | |==================| | | CE2 |
+ | CE1 | +----+ |PE2 | | |
+ | | +----+ | | +-----+
+ | | | |==================| |
+ | |----------|....|...PW2.(standby)..| |
+ +-----+ | | PE3|==================| |
+ AC +----+ +----+
+
+ Figure 2: One Dual-Homed CE and Redundant SS-PWs
+
+ In this scenario, only one of the PWs should be used for forwarding
+ between PE1/PE3 and PE2. PW redundancy determines which PW to make
+ active based on the forwarding state of the ACs so that only one path
+ is available from CE1 to CE2. This requires an additional PW state
+
+
+
+
+Muley, et al. Informational [Page 7]
+
+RFC 6718 PW Redundancy August 2012
+
+
+ that reflects this forwarding state, which is separate from the
+ operational status of the PW. This is the 'Preferential Forwarding
+ Status'.
+
+ Consider the example where the AC from CE1 to PE1 is initially active
+ and the AC from CE1 to PE3 is initially standby. PW1 is made active
+ and PW2 is made standby in order to complete the path to CE2.
+
+ On failure of the AC between CE1 and PE1, the forwarding state of the
+ AC on PE3 transitions to active. The preferential forwarding state
+ of PW2 therefore needs to become active, and PW1 standby, in order to
+ re-establish connectivity between CE1 and CE2. PE3 therefore uses
+ PW2 to forward towards CE2, and PE2 uses PW2 instead of PW1 to
+ forward towards CE1. PW redundancy in this scenario requires that
+ the forwarding status of the ACs at PE1 and PE3 be signaled to PE2 so
+ that PE2 can choose which PW to make active.
+
+ Changes occurring on the dual-homed side of the network due to a
+ failure of the AC or PE are not propagated to the ACs on the other
+ side of the network. Furthermore, failures in the PSN are not
+ propagated to the attached CEs.
+
+3.2.2. PW Redundancy for AC and PE Protection: Two Dual-Homed CEs with
+ Redundant SS-PWs
+
+ Figure 3 illustrates an application of single-segment pseudowire
+ redundancy where both of the CEs are dual-homed. This scenario is
+ also designed to protect the emulated service against failures of the
+ ACs and failures of the PEs. Both CE1 and CE2 are dual-homed to
+ their respective PEs, CE1 to PE1 and PE2, and CE2 to PE3 and PE4. A
+ dual-homing control protocol, the details of which are outside the
+ scope of this document, enables the PEs and CEs to determine which
+ PEs should forward towards the CEs and therefore which ACs the CEs
+ should use to forward towards the PSN.
+
+ 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. Protection against failures of the PSN
+ tunnels is provided using PSN mechanisms such as MPLS fast reroute,
+ so that these failures do not impact the PW.
+
+
+
+
+
+
+
+
+
+
+
+Muley, et al. Informational [Page 8]
+
+RFC 6718 PW Redundancy August 2012
+
+
+ |<-------------- Emulated Service ---------------->|
+ | |
+ | |<------- Pseudowire ------->| |
+ | | | |
+ | | |<-- PSN Tunnels-->| | |
+ | V V V V |
+ V AC +----+ +----+ AC V
+ +-----+ | |....|.......PW1........|....| | +-----+
+ | |----------| PE1|...... .........| PE3|----------| |
+ | CE1 | +----+ \ / PW3 +----+ | CE2 |
+ | | +----+ X +----+ | |
+ | | | |....../ \..PW4....| | | |
+ | |----------| PE2| | PE4|--------- | |
+ +-----+ | |....|.....PW2..........|....| | +-----+
+ AC +----+ +----+ AC
+
+ Figure 3: Two Dual-Homed CEs and Redundant SS-PWs
+
+ PW1 and PW4 connect PE1 to PE3 and PE4, respectively. Similarly, PW2
+ and PW3 connect PE2 to PE4 and PE3. PW1, PW2, PW3, and PW4 are all
+ up. In order to support protection for the emulated service, only
+ one PW MUST be selected to forward traffic.
+
+ If a PW has a preferential forwarding status of 'active', it can be
+ used for forwarding traffic. The actual up PW chosen by the combined
+ set of PEs connected to the CEs is determined by considering the
+ preferential forwarding status of each PW at each PE. The mechanisms
+ for communicating the preferential forwarding status are outside the
+ scope of this document. Only one PW is used for forwarding.
+
+ The following failure scenario illustrates the operation of PW
+ redundancy in Figure 3. In the initial steady state, when there are
+ no failures of the ACs, one of the PWs is chosen as the active PW,
+ and all others are chosen as standby. The dual-homing protocol
+ between CE1 and PE1/PE2 chooses to use the AC to PE2, while the
+ protocol between CE2 and PE3/PE4 chooses to use the AC to PE4.
+ Therefore, the PW between PE2 and PE4 is chosen as the active PW to
+ complete the path between CE1 and CE2.
+
+ On failure of the AC between the dual-homed CE1 and PE2, the
+ preferential forwarding status of the PWs at PE1, PE2, PE3 and PE4
+ needs to change so as to re-establish a path from CE1 to CE2.
+ Different mechanisms can be used to achieve this and these are beyond
+ the scope of this document. After the change in status, the
+ algorithm needs to evaluate and select which PW to forward traffic
+ on. In this application, each dual-homing algorithm, i.e., {CE1,
+ PE1, PE2} and {CE2, PE3, PE4}, selects the active AC independently.
+
+
+
+
+Muley, et al. Informational [Page 9]
+
+RFC 6718 PW Redundancy August 2012
+
+
+ There is therefore a need to signal the active status of each AC such
+ that the PEs can select a common active PW for forwarding between CE1
+ and CE2.
+
+ Changes occurring on one side of network due to a failure of the AC
+ or PE are not propagated to the ACs on the other side of the network.
+ Furthermore, failures in the PSN are not propagated to the attached
+ CEs. Note that end-to-end native service protection switching can
+ also be used to protect the emulated service in this scenario. In
+ this case, PW3 and PW4 are not necessary.
+
+ If the CEs do not perform native service protection switching, they
+ may instead use load balancing across the paths between the CEs.
+
+3.2.3. PW Redundancy for S-PE Protection: Single-Homed CEs with
+ Redundant MS-PWs
+
+ Figure 4 shows a scenario where both CEs are single-homed, and MS-PW
+ redundancy is used. The main objective is to protect the emulated
+ service against failures of the S-PEs.
+
+ Native |<----------- Pseudowires ----------->| 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 4: Single-Homed CE with Redundant MS-PWs
+
+
+
+
+
+
+
+
+Muley, et al. Informational [Page 10]
+
+RFC 6718 PW Redundancy August 2012
+
+
+ CE1 is connected to T-PE1, and CE2 is connected to T-PE2. There are
+ three multi-segment PWs. PW1 is switched at S-PE1, PW2 is switched
+ at S-PE2, and PW3 is switched at S-PE3. This scenario provides N:1
+ protection for the subset of the path of the emulated service from
+ T-PE1 to T-PE2.
+
+ Since there is no multi-homing running on the ACs, the T-PE nodes
+ advertise 'active' for the preferential forwarding status based on a
+ priority for the PW. The priority associates a meaning of 'primary
+ PW' and 'secondary PW' to a PW. These priorities MUST be used if
+ revertive mode is used and the active PW to use for forwarding is
+ determined accordingly. The priority can be derived via
+ configuration or based on the value of the PW forwarding equivalence
+ class (FEC). For example, a lower value of PWid FEC can be taken as
+ a higher priority. However, this does not guarantee selection of
+ same PW by the T-PEs because of, for example, a mismatch in the
+ configuration of the PW priority at each T-PE. The intent of this
+ application is for T-PE1 and T-PE2 to synchronize the transmit and
+ receive paths of the PW over the network. In other words, both T-PE
+ nodes are required to transmit over the PW segment that is switched
+ by the same S-PE. This is desirable for ease of operation and
+ troubleshooting.
+
+3.2.4. PW Redundancy for PE-rs Protection in H-VPLS Using SS-PWs
+
+ The following figure (based on the architecture shown in Figure 3 of
+ [RFC4762]) illustrates the application of PW redundancy to
+ hierarchical VPLS (H-VPLS). Note that the PSN tunnels are not shown
+ for clarity, and only one PW of a PW group is shown. A multi-tenant
+ unit switch (MTU-s) is dual-homed to two PE router switches. The
+ example here uses SS-PWs, and the objective is to protect the
+ emulated service against failures of a PE-rs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muley, et al. Informational [Page 11]
+
+RFC 6718 PW Redundancy August 2012
+
+
+ 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
+
+ Figure 5: MTU-s Dual-Homing in H-VPLS Core
+
+ In Figure 5, the MTU-s is dual-homed to PE1-rs and PE2-rs and has
+ spoke PWs to each of them. The MTU-s needs to choose only one of the
+ spoke PWs (the active PW) to forward traffic to one of the PEs and
+ sets the other PW to standby. The MTU-s can derive the status of the
+ PWs based on local policy configuration. PE1-rs and PE2-rs are
+ connected to the H-VPLS core on the other side of network. The MTU-s
+ communicates the status of its member PWs for a set of virtual
+ switching instances (VSIs) that share a common status of active or
+ standby. Here, the MTU-s controls the selection of PWs used to
+ forward traffic. Signaling using PW grouping with a common group-id
+ in the PWid FEC Element, or a Grouping TLV in Generalized PWid FEC
+ Element as defined in [RFC4447], to PE1-rs and PE2-rs, is recommended
+ for improved scaling.
+
+ Whenever an MTU-s performs a switchover of the active PW group, it
+ needs to communicate this status change to the PE2-rs. That is, it
+ informs PE2-rs that the status of the standby PW group has changed to
+ active.
+
+
+
+
+
+Muley, et al. Informational [Page 12]
+
+RFC 6718 PW Redundancy August 2012
+
+
+ In this scenario, PE devices are aware of switchovers at the MTU-s
+ and could generate Media Access Control (MAC) Address Withdraw
+ messages to trigger MAC flushing within the H-VPLS full mesh. By
+ default, MTU-s devices should still trigger MAC Address Withdraw
+ messages as defined in [RFC4762] to prevent two copies of MAC Address
+ Withdraw messages to be sent (one by the MTU-s and another one by the
+ PE-rs). Mechanisms to disable the MAC withdraw trigger in certain
+ devices are out of the scope of this document.
+
+3.2.5. PW Redundancy for PE Protection in a VPLS Ring Using SS-PWs
+
+ The following figure illustrates the use of PW redundancy for dual-
+ homed connectivity between PEs in a VPLS ring topology. As above,
+ PSN tunnels are not shown, and only one PW of a PW group is shown for
+ clarity. The example here uses SS-PWs, and the objective is to
+ protect the emulated service against failures of a PE on the ring.
+
+ PE1 PE2
+ +--------+ +--------+
+ | VSI | | VSI |
+ | -- | | -- |
+ ......|../ \..|.....................|../ \..|.......
+ | \ / | PW Group 1 | \ / |
+ | -- | | -- |
+ +--------+ +--------+
+ . .
+ . .
+ VPLS Domain A . . VPLS Domain B
+ . .
+ . .
+ . .
+ +--------+ +--------+
+ | VSI | | VSI |
+ | -- | | -- |
+ ......|../ \..|.....................|../ \..|........
+ | \ / | PW Group 2 | \ / |
+ | -- | | -- |
+ +--------+ +--------+
+ PE3 PE4
+
+ Figure 6: Redundancy in a VPLS Ring Topology
+
+ In Figure 6, PE1 and PE3 from VPLS domain A are connected to PE2 and
+ PE4 in VPLS domain B via PW group 1 and PW group 2. The PEs are
+ connected to each other in such a way as to form a ring topology.
+ Such scenarios may arise in inter-domain H-VPLS deployments where the
+ Rapid Spanning Tree Protocol (RSTP) or other mechanisms may be used
+ to maintain loop-free connectivity of the PW groups.
+
+
+
+Muley, et al. Informational [Page 13]
+
+RFC 6718 PW Redundancy August 2012
+
+
+ [RFC4762] outlines multi-domain VPLS services without specifying how
+ multiple redundant border PEs per domain and per VPLS instance can be
+ supported. In the example above, PW group 1 may be blocked at PE1 by
+ RSTP, and it is desirable to block the group at PE2 by exchanging the
+ PW preferential forwarding status of standby. The details of how PW
+ grouping is achieved and used is deployment specific and is outside
+ the scope of this document.
+
+3.2.6. PW Redundancy for VPLS n-PE Protection Using SS-PWs
+
+ |<----- Provider ----->|
+ Core
+ +------+ +------+
+ | n-PE |::::::::::::::::::::::| n-PE |
+ Provider | (P) |.......... .........| (P) | Provider
+ Access +------+ . . +------+ Access
+ Network X Network
+ (1) +------+ . . +------+ (2)
+ | n-PE |.......... .........| n-PE |
+ | (B) |......................| (B) |
+ +------+ +------+
+
+ Figure 7: Bridge Module Model
+
+ Figure 7 shows a scenario with two provider access networks. The
+ example here uses SS-PWs, and the objective is to protect the
+ emulated service against failures of a network-facing PE (n-PE).
+
+ Each network has two n-Pes. These n-PEs are connected via a full
+ mesh of PWs for a given VPLS instance. As shown in the figure, only
+ one n-PE in each access network serves as the primary PE (P) for that
+ VPLS instance, and the other n-PE serves as the backup PE (B). In
+ this figure, each primary PE has two active PWs originating from it.
+ Therefore, when a multicast, broadcast, or unknown unicast frame
+ arrives at the primary n-PE from the access network side, the n-PE
+ replicates the frame over both PWs in the core even though it only
+ needs to send the frames over a single PW (shown with :::: in the
+ figure) to the primary n-PE on the other side. This is an
+ unnecessary replication of the customer frames that consumes core-
+ network bandwidth (half of the frames get discarded at the receiving
+ n-PE). This issue gets aggravated when there are three or more n-PEs
+ per provider access network. For example, if there are three n-PEs
+ or four n-PEs per access network, then 67% or 75% of core bandwidth
+ for multicast, broadcast, and unknown unicast are wasted,
+ respectively.
+
+
+
+
+
+
+Muley, et al. Informational [Page 14]
+
+RFC 6718 PW Redundancy August 2012
+
+
+ In this scenario, the n-PEs can communicate the active or standby
+ status of the PWs among them. This status can be derived from the
+ active or backup state of an n-PE for a given VPLS.
+
+4. Generic PW Redundancy Requirements
+
+4.1. Protection Switching Requirements
+
+ o Protection architectures such as N:1,1:1 or 1+1 are possible. 1:1
+ protection MUST be supported. The N:1 protection case is less
+ efficient in terms of the resources that must be allocated; hence,
+ this SHOULD be supported. 1+1 protection MAY be used in the
+ scenarios described in the document. However, the details of its
+ usage are outside the scope of this document, as it MAY require a
+ 1+1 protection switching protocol between the CEs.
+
+ o Non-revertive behavior MUST be supported, while revertive behavior
+ is OPTIONAL. This avoids the need to designate one PW as primary
+ unless revertive behavior is explicitly required.
+
+ o Protection switchover can be initiated from a PE, e.g., using a
+ manual switchover or a forced switchover, or it may be triggered
+ by a signal failure, i.e., a defect in the PW or PSN. Manual
+ switchover may be necessary if it is required to disable one PW in
+ a redundant set. Both methods MUST be supported, and signal
+ failure triggers MUST be treated with a lower priority than any
+ local or far-end forced switch or manual trigger.
+
+ o A PE MAY be able to forward packets received from a PW with a
+ standby status in order to avoid black holing of in-flight packets
+ during switchover. However, in cases where VPLS is used, all VPLS
+ application packets received from standby PWs MUST be dropped,
+ except for OAM and control-plane packets.
+
+4.2. Operational Requirements
+
+ o (T-)PEs involved in protecting a PW SHOULD automatically discover
+ and attempt to resolve inconsistencies in the configuration of
+ primary/secondary PWs.
+
+ o (T-)PEs involved in protecting a PW SHOULD automatically discover
+ and attempt to resolve inconsistencies in the configuration of
+ revertive/non-revertive protection switching mode.
+
+ o (T-)PEs that do not automatically discover or resolve
+ inconsistencies in the configuration of primary/secondary,
+ revertive/non-revertive, or other parameters MUST generate an
+ alarm upon detection of an inconsistent configuration.
+
+
+
+Muley, et al. Informational [Page 15]
+
+RFC 6718 PW Redundancy August 2012
+
+
+ o (T-)PEs participating in PW redundancy MUST support the
+ configuration of revertive or non-revertive protection switching
+ modes if both modes are supported.
+
+ o The MIB(s) MUST support inter-PSN monitoring of the PW redundancy
+ configuration, including the protection switching mode.
+
+ o (T-)PEs participating in PW redundancy SHOULD support the local
+ invocation of protection switching.
+
+ o (T-)PEs participating in PW redundancy SHOULD support the local
+ invocation of a lockout of protection switching.
+
+5. Security Considerations
+
+ The PW redundancy method described in this RFC will require an
+ extension to the PW setup and maintenance protocol [RFC4447], which
+ in turn is carried over the Label Distribution Protocol (LDP)
+ [RFC5036]. This PW redundancy method will therefore inherit the
+ security mechanisms of the version of LDP implemented in the PEs.
+
+6. Contributors
+
+ The editors would like to thank Pranjal Kumar Dutta, Marc Lasserre,
+ Jonathan Newton, Hamid Ould-Brahim, Olen Stokes, Dave Mcdysan, Giles
+ Heron, and Thomas Nadeau, all of whom made a major contribution to
+ the development of this document.
+
+ Pranjal Dutta
+ Alcatel-Lucent
+ EMail: pranjal.dutta@alcatel-lucent.com
+
+ Marc Lasserre
+ Alcatel-Lucent
+ EMail: marc.lasserre@alcatel-lucent.com
+
+ Jonathan Newton
+ Cable & Wireless
+ EMail: Jonathan.Newton@cw.com
+
+ Hamid Ould-Brahim
+ EMail: ouldh@yahoo.com
+
+ Olen Stokes
+ Extreme Networks
+ EMail: ostokes@extremenetworks.com
+
+
+
+
+
+Muley, et al. Informational [Page 16]
+
+RFC 6718 PW Redundancy August 2012
+
+
+ Dave McDysan
+ Verizon
+ EMail: dave.mcdysan@verizon.com
+
+ Giles Heron
+ Cisco Systems
+ EMail: giles.heron@gmail.com
+
+ Thomas Nadeau
+ Juniper Networks
+ EMail: tnadeau@lucidvision.com
+
+7. Acknowledgements
+
+ The authors would like to thank Vach Kompella, Kendall Harvey,
+ Tiberiu Grigoriu, Neil Hart, Kajal Saha, Florin Balus, and Philippe
+ Niger for their valuable comments and suggestions.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
+ Edge (PWE3) Architecture", RFC 3985, March 2005.
+
+ [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
+ Private Network (VPN) Terminology", RFC 4026, March 2005.
+
+ [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
+ Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
+
+ [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
+ Heron, "Pseudowire Setup and Maintenance Using the Label
+ Distribution Protocol (LDP)", RFC 4447, April 2006.
+
+ [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
+ (VPLS) Using Label Distribution Protocol (LDP) Signaling",
+ RFC 4762, January 2007.
+
+ [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
+ Specification", RFC 5036, October 2007.
+
+ [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
+ Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
+ October 2009.
+
+
+
+Muley, et al. Informational [Page 17]
+
+RFC 6718 PW Redundancy August 2012
+
+
+8.2. Informative Reference
+
+ [RFC5601] Nadeau, T. and D. Zelig, "Pseudowire (PW) Management
+ Information Base (MIB)", RFC 5601, July 2009.
+
+Authors' Addresses
+
+ Praveen Muley
+ Alcatel-Lucent
+
+ EMail: praveen.muley@alcatel-lucent.com
+
+
+ Mustapha Aissaoui
+ Alcatel-Lucent
+
+ EMail: mustapha.aissaoui@alcatel-lucent.com
+
+
+ Matthew Bocci
+ Alcatel-Lucent
+
+ EMail: matthew.bocci@alcatel-lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muley, et al. Informational [Page 18]
+