[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-muley-pwe3-redundancy) 00 01
02 03 04 05 06 07 08 09 RFC 6718
Network Working Group P. Muley
Internet-Draft M. Aissaoui
Intended status: Informational M. Bocci
Expires: November 4, 2012 Alcatel-Lucent
May 3, 2012
Pseudowire Redundancy
draft-ietf-pwe3-redundancy-08
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 redundancy set.
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].
Status of this Memo
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 November 4, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Muley, et al. Expires November 4, 2012 [Page 1]
Internet-Draft PW Redundancy May 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Reference Models . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. PE Architecture . . . . . . . . . . . . . . . . . . . . . 5
3.2. PW Redundancy Network Reference Scenarios . . . . . . . . 5
3.2.1. Single Multi-Homed CE . . . . . . . . . . . . . . . . 5
3.2.2. Multiple Multi-Homed CEs . . . . . . . . . . . . . . . 7
3.2.3. Single-Homed CE With MS-PW Redundancy . . . . . . . . 8
3.2.4. PW Redundancy Between MTU-s in H-VPLS . . . . . . . . 9
3.2.5. PW Redundancy Between VPLS Network Facing PEs
(n-PEs) . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.6. Redundancy in a VPLS Bridge Module Model . . . . . . . 12
4. Generic PW Redundancy Requirements . . . . . . . . . . . . . . 13
4.1. Protection Switching Requirements . . . . . . . . . . . . 13
4.2. Operational Requirements . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Major Contributing Authors . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Muley, et al. Expires November 4, 2012 [Page 2]
Internet-Draft PW Redundancy May 2012
1. Introduction
The objective of PW redundancy is to enable redundant attachment
circuits (ACs), provider edge nodes (PEs), and pseudowires (PWs) to
eliminate single points of failure in the path of an emulated
service. This is achieved while ensuring that only one active path
exists between a pair of customer edge nodes (CEs).
In single-segment PW (SS-PW) applications, protection for the PW is
provided by the packet switched network (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. It is assumed that 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.
In multi-segment PW (MS-PW) applications, PSN protection mechanisms
cannot protect against the failure of a switching PE (S-PE). A set
of mechanisms that support the operation of a primary and one or more
backup PWs via a different set of S-PEs is therefore required. The
paths of these PWs are diverse in the sense that they are switched at
different S-PE nodes.
In both of these applications, PW redundancy is important to maximise
the resiliency of the emulated service.
This document describes the 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 RFC4447 [RFC4447].
The mechanisms for PW redundancy are modeled on general protection
switching principles.
2. Terminology
o Up PW: A PW which has been configured (label mapping exchanged
between PEs) and is not in any of the PW defect states specified
in [RFC4447]. Such a PW is is available for forwarding traffic.
o Down PW: A PW that has either not been fully configured, or has
been configured and is in any one of the PW defect states
Muley, et al. Expires November 4, 2012 [Page 3]
Internet-Draft PW Redundancy May 2012
specified in [RFC4447]. Such a PW is not available for forwarding
traffic.
o Active PW: An UP PW used for forwarding user, OAM 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 VPLS MTU-s or PE-rs.
o Primary PW: The PW which 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 behaviour is used.
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 it is UP and 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 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 RFC4762 [RFC4762].
o PE-rs: A hierarchical virtual private LAN service switch, as
defined in RFC4762.
o n-PE: A network facing provider edge node, as defined in RFC4026
[RFC4026].
Muley, et al. Expires November 4, 2012 [Page 4]
Internet-Draft PW Redundancy May 2012
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.
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 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<===========>
| | |
+----------------------------------------+
Figure 1: PE Architecture for PW redundancy
3.2. PW Redundancy Network Reference Scenarios
This section presents a set of reference scenarios for PW redundancy.
3.2.1. Single Multi-Homed CE
The following figure illustrates an application of single segment
pseudowire redundancy. This scenario is designed to protect the
emulated service against a failure of one of the PEs or ACs attached
Muley, et al. Expires November 4, 2012 [Page 5]
Internet-Draft PW Redundancy May 2012
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, selects
which AC CE1 should use to forward towards the PSN, and which PE (PE1
or PE3) should forward towards CE1.
|<-------------- 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: PW Redundancy with One Multi-Homed CE
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.
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
Muley, et al. Expires November 4, 2012 [Page 6]
Internet-Draft PW Redundancy May 2012
side of the network. Furthermore, failures in the PSN are not
propagated to the attached CEs.
3.2.2. Multiple Multi-Homed CEs
This scenario, illustrated in Figure 3, 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. The method used by the CEs to choose which
AC to use to forward traffic towards the PSN is determined by a dual-
homing control protocol. The details of this protocol 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. 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
Figure 3: Multiple Multi-Homed CEs with PW Redundancy
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 N:1 or 1:1 protection, only one PW MUST be
selected to forward traffic. This document defines an additional PW
state that reflects this forwarding state, which is separate from the
operational status of the PW. This is the 'Preferential Forwarding
Status'.
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
Muley, et al. Expires November 4, 2012 [Page 7]
Internet-Draft PW Redundancy May 2012
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 revaluate 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.
3.2.3. Single-Homed CE With MS-PW Redundancy
This application is shown in Figure 4. The main objective is to
protect the emulated service against failures of the S-PEs.
Muley, et al. Expires November 4, 2012 [Page 8]
Internet-Draft PW Redundancy May 2012
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 MS-PW Redundancy
CE1 is connected to PE1 and CE2 is connected to 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.
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 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.
3.2.4. PW Redundancy Between MTU-s in H-VPLS
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
Muley, et al. Expires November 4, 2012 [Page 9]
Internet-Draft PW Redundancy May 2012
for clarity, and only one PW of a PW group is shown. Here, a multi-
tenant unit switch (MTU-s) is dual-homed to two PE router switches
(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: 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.
Muley, et al. Expires November 4, 2012 [Page 10]
Internet-Draft PW Redundancy May 2012
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 switchovers 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.
3.2.5. PW Redundancy Between VPLS Network Facing PEs (n-PEs)
The following figure illustrates the use of PW redundancy for dual-
homed connectivity between PEs in a ring topology. As above, PSN
tunnels are not shown and only one PW of a PW group is shown for
clarity.
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 Ring Topology
Muley, et al. Expires November 4, 2012 [Page 11]
Internet-Draft PW Redundancy May 2012
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
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.
3.2.6. Redundancy in a VPLS Bridge Module Model
|<----- 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
Bridge Module Model
Figure 7 shows a scenario with two provider access networks. 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
Muley, et al. Expires November 4, 2012 [Page 12]
Internet-Draft PW Redundancy May 2012
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
bandwidthfor 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.
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 and
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.
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 lockout/force 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 higher priority than any local or
far-end manual trigger.
o Note that 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 the case of use of VPLS,
all VPLS application packets received from standby PWs MUST be
dropped, except for OAM 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 PW.
Muley, et al. Expires November 4, 2012 [Page 13]
Internet-Draft PW Redundancy May 2012
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.
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 (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
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].
6. IANA Considerations
This document has no actions for IANA.
7. Major Contributing Authors
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.
Muley, et al. Expires November 4, 2012 [Page 14]
Internet-Draft PW Redundancy May 2012
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
Nortel
Email: hbrahim@nortel.com
Dave McDysan
Verizon
Email: dave.mcdysan@verizon.com
Giles Heron
Cisco Systems
Email: giles.heron@gmail.com
Thomas Nadeau
Computer Associates
Email: tnadeau@lucidvision.com
8. 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.
9. References
9.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-
Muley, et al. Expires November 4, 2012 [Page 15]
Internet-Draft PW Redundancy May 2012
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, March 2005.
[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.
9.2. Informative References
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
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. Expires November 4, 2012 [Page 16]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/