| Network Working Group | P. Muley |
| Internet-Draft | M. Aissaoui |
| Intended status: Informational | M. Bocci |
| Expires: December 27, 2012 | Alcatel-Lucent |
| June 27, 2012 |
Pseudowire Redundancy
draft-ietf-pwe3-redundancy-09
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.
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].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 27, 2012.
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.
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 nodes (CEs) 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 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) labeled 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 customer edge (CE) node to different PE nodes which provide a pseudowire emulated service across the PSN. A set of PW mechanisms is therefore required that enables a primary and one or more backup PWs to terminate on different PE nodes. 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 support 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.
In both of these cases, PW redundancy is important to maximise 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 its 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 RFC4446 [RFC4446]. The mechanisms for PW redundancy are modeled on general protection switching principles.
This document uses the term ‘PE’ to be synonymous with both PEs as per RFC3985[RFC3985] and T-PEs as per RFC5659 [RFC5659].
This document uses the term ‘PW’ to be synonymous with both PWs as per RFC3985 and SS-PWs, MS-PWs, and PW segments as per RFC5659.
The following sections show the reference architecture of the PE for PW redundancy and the usage of the architecture in different topologies and applications.
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 RFC3985 [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<===========>
| | |
+----------------------------------------+
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.
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 +----+ +----+
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 reestablish 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.
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, PE1 and PE2, and 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.
|<-------------- 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
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. 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.
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|===============
| |
+-----+
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 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 which is switched by the same S-PE. This is desirable for ease of operation and troubleshooting.
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 (PE-rs). The example here uses SS-PWs and the objective is to protect the emulated service against failures of a PE-rs.
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, 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 the PE2-rs. That is, it informs PE2-rs that the status of the standby PW group has changed to active.
In this scenario, PE devices are aware of switch overs at the 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 defined in [RFC4762] to prevent two copies of MAC withdraws 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.
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, 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 rapid spanning tree (RSTP) or other mechanisms may be used to maintain loop free connectivity of the PW groups.
[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.
|<----- 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 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 is 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.
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.
This document requires extensions to the Label Distribution Protocol (LDP) that are needed for protecting pseudowires. These will inherit at least the same security properties as LDP [RFC5036] and the PW control protocol [RFC4447].
This document has no actions for IANA.
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 who 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
Olen Stokes
Extreme Networks
Email: ostokes@extremenetworks.com
Hamid Ould-Brahim
Email: ouldh@yahoo.com
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
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.
| [RFC6073] | Martini, L., Metz, C., Nadeau, T., Bocci, M. and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. |