Internet DRAFT - draft-ietf-pwe3-redundancy-bit
draft-ietf-pwe3-redundancy-bit
Network Working Group Praveen Muley, Ed.
Internet Draft Mustapha Aissaoui, Ed.
Updates: RFC 4447 Alcatel-Lucent
Intended Status: Standards Track
Expires: July 4, 2013 January 4, 2013
Pseudowire Preferential Forwarding Status Bit
draft-ietf-pwe3-redundancy-bit-09.txt
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 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."
Muley et al. Expires July 4,2013 [Page 1]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
This Internet-Draft will expire on July 4, 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.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
Table of Contents
1. Introduction...................................................3
2. Motivation and Scope...........................................4
3. Terminology....................................................6
4. PE Architecture................................................8
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....................................15
6.3. Coordination of PW Switchover............................17
6.3.1. Procedures at the requesting endpoint...............18
6.3.2. Procedures at the receiving endpoint................19
7. Status Mapping................................................20
Muley et al. Expires July 4, 2013 [Page 2]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
7.1. AC Defect State Entry/Exit...............................20
7.2. PW Defect State Entry/Exit...............................20
8. Applicability and Backward Compatibility......................21
9. Security Considerations.......................................21
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............22
12. Contributors.................................................22
13. Acknowledgments..............................................23
14. References...................................................24
14.1. Normative References....................................24
14.2. Informative References..................................24
15. Appendix A - Applications of PW Redundancy Procedures........25
15.1. One Multi-homed CE with single SS-PW redundancy.........25
15.2. Multiple Multi-homed CEs with single SS-PW redundancy...27
15.3. Multi-homed CE with MS-PW redundancy....................28
15.4. Multi-homed CE with MS-PW redundancy and S-PE protection29
15.5. Single Homed CE with MS-PW redundancy...................31
15.6. PW redundancy between H-VPLS MTU-s and PE-rs............33
Authors' Addresses...............................................34
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 RFC6718 (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 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.
Muley et al. Expires July 4, 2013 [Page 3]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
Section 15. 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].
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 AC and a PW
[7]:
0x00000000 - Pseudowire forwarding (clear all failures)
0x00000001 - Pseudowire Not Forwarding
0x00000002 - Local Attachment Circuit (ingress) Receive Fault
0x00000004 - Local Attachment Circuit (egress) Transmit Fault
0x00000008 - Local PSN-facing PW (ingress) Receive Fault
0x00000010 - Local PSN-facing PW (egress) Transmit Fault
The applications defined in [8] allow the provisioning of a primary
PW and one or many secondary backup PWs in the same Virtual Private
Wire Service (VPWS) or Virtual Private LAN Service (VPLS). The
objective of PW redundancy is to maintain end-to-end connectivity
for the emulated service by activating the correct PW whenever an
AC, a PE, or a PW fails. The correct PW means the one which provides
the end-to-end connectivity from 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 forward user packets
to. 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, and the procedures the PE nodes
follow to indicate the preferential forwarding state of a PW to its
peer PE node.
Muley et al. Expires July 4, 2013 [Page 4]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
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, protects a specific subset of a path for the
emulated service, consisting of an active PW and/or AC. .
c. A mechanism to allow PW endpoints to coordinate the switchover
to a given PW by using an explicit request/acknowledgment
switchover procedure. This mechanism is complementary to 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. 5.1 and 5.2. 5.2 . The PW with the
lowest precedence value has the highest priority. Precedence
may be configured via, for example, a local configuration
parameter at the PW endpoint.
e. Implementations can designate by configuration 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 qualify for the active
state, as defined in sections 5.1. 5.1 and 5.2. 5.2 , a PE
node selects the primary PW in preference to a secondary PW.
In other words, the primary PW has implicitly the lowest
precedence value. Furthermore, a PE node reverts to the
primary PW immediately after it comes back up or after the
expiration of a delay effectively achieving revertive
protection switching.
Muley et al. Expires July 4, 2013 [Page 5]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
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 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 it to the
remote endpoints. Only a PW which is up and which
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.
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 a single-segment pseudowire (SS-PW), or on a terminating
provider edge (T-PE)in the case of a multi-segment pseudowire (MS-
PW). PW redundancy scenarios where the redundant set of PW segments
terminates on an 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 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 T-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 which has been configured (label mapping exchanged
between PEs) and is not in any of the PW or AC defect
states specified in [7]. Such a PW is available for
forwarding traffic [8].
Muley et al. Expires July 4, 2013 [Page 6]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
Down PW: A PW that has either not been fully configured, or has been
configured and is in any of the PW or AC defect states
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 which 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., 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 which 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., A SS-PW PE, an MS-PW
T-PE, or an 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 attachment circuits (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
Muley et al. Expires July 4, 2013 [Page 7]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
of the preceding and succeeding segments of the MS-PW. It
therefore 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. It is therefore 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.
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 4-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 using the criteria
described in this document.
Muley et al. Expires July 4, 2013 [Page 8]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
+----------------------------------------+
| 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 4-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
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
operates as follows:
Muley et al. Expires July 4, 2013 [Page 9]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
1. For a PW ID Forwarding Equivalence Class (PWid FEC) PW [2], the
PW with the lowest pw-id value is selected.
2. For a Generalized PWid FEC PW [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 SAII and 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 which 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 pw-id 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.
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 tie-breaking 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
Muley et al. Expires July 4, 2013 [Page 10]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
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 advertize 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. 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 T-LDP status messages between
endpoints. In this case, the behavior of the receiving endpoint is
outside the scope of this document.
Thus, in this mode of operation, the following definition 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. 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
Muley et al. Expires July 4, 2013 [Page 11]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
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 [12], 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 is 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 in [11].
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
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 recommended to use the Independent Mode
of operation as in the application described in 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.
Muley et al. Expires July 4, 2013 [Page 12]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
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 but 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 follow 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.
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
Muley et al. Expires July 4, 2013 [Page 13]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
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 is outside the scope of this document.
If the PW is a spoke in H-VPLS, any MAC addresses learned via the PW
SHOULD be flushed when it transitions to standby state according to
the procedures in RFC 4762 [3] and [11].
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" bit Status Code 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 a
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
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. 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.
Muley et al. Expires July 4, 2013 [Page 14]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
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 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
PWid FEC TLV with only the Group ID, or else it contains 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 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
Muley et al. Expires July 4, 2013 [Page 15]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
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.
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
Muley et al. Expires July 4, 2013 [Page 16]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
6.3. Coordination of PW Switchover
There are PW redundancy applications which 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.
The trigger for sending a request to switchover of the MS-PW by one
endpoint can be an operational event, for example a failure, which
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 acknowledgement from the
peer endpoint that the request can be honored before it switches to
another PW. Furthermore, any of the endpoints can make the request
to switchover.
This document specifies a second status bit that is used by a PE to
request that its peer PE switchover 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 which receives
the 'request switchover' bit and which 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.
Muley et al. Expires July 4, 2013 [Page 17]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
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 it desires to switch to.
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.
c. The requesting endpoint starts a timer while waiting 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 switchover to the same or a
different PW, it MUST perform the following:
i. If its address is higher than that of the peer, this
endpoint ignores the request and continues to wait for
the acknowledgement from its peer.
ii. If its system IP address is lower than that of its peer,
it aborts the timer and immediately starts the
procedures of the receiving endpoint in Section 6.3.2.
e. 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
Muley et al. Expires July 4, 2013 [Page 18]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
'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 which is up, it MUST perform the
following:
i. Abort the timer.
ii. Issue a new request to switchover to the alternate PW.
iii. Re-start the timer.
g. If, while waiting for the acknowledgment, the requesting endpoint
detects that the requested PW went into the down state locally,
and could not use an alternate PW which 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
Muley et al. Expires July 4, 2013 [Page 19]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
'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 different from the
currently active one, and the requested PW 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.
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 which 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 which 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.2.1 (Section 8.2.2) in [5] are met for each of the PWs in the
redundant set.
Muley et al. Expires July 4, 2013 [Page 20]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
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 which are part of a redundant set MUST use the same FEC type.
When the set uses PWid FEC element, each PW is uniquely identified
by its PW ID. When the redundant set uses Generalized PWid FEC
element, each PW MUST have a unique identifier which 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 PW Status TLV is found to be not
supported by either of its endpoint after status negotiation
procedures, then the mechanisms specified in this document cannot be
used.
A PE implementation compliant to RFC 4447 [2], and which 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 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 pseudowires must be
implemented because the status bits defined in this document have
the same security considerations as the pseudowire setup and
Muley et al. Expires July 4, 2013 [Page 21]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
maintenance protocol defined in RFC4447 [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 is requested to allocate these from the
PW 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".
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
Muley et al. Expires July 4, 2013 [Page 22]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
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
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.
Muley et al. Expires July 4, 2013 [Page 23]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
14. References
14.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Martini, L., et al., "Pseudowire Setup and Maintenance using
LDP", RFC 4447, April 2006.
[3] Kompella,V., Lasserrre, M. , et al., "Virtual Private LAN
Service (VPLS) Using LDP Signalling", RFC 4762, January 2007.
[4] Martini, L., et al., "Segmented Pseudowire", RFC 6073, January
2011.
[5] Aissaoui, M., et al., "Pseudowire (PW) OAM Message Mapping",
RFC 6310, July 2011.
14.2. Informative References
[6] Bocci, M., Bryant, S., et al., "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., et al., "Pseudowire (PW) Redundancy", RFC 6718,
August 2012.
[9] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge (PWE3)
Architecture", RFC 3985, March 2005
[10] Nadeau, T., Zelig, D., Nicklass, O., "Definitions of Textual
Conventions for Pseudowire (PW) Management", RFC 5542, May
2009
[11] Dutta, P., Lasserre, M., Stokes, O., "LDP Extensions for
Optimized MAC Address Withdrawal in H-VPLS", draft-ietf-l2vpn-
vpls-ldp-mac-opt-05.txt, October 2011
[12] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
Muley et al. Expires July 4, 2013 [Page 24]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
15. 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 the PW Redundancy [8].
15.1. One Multi-homed CE with single SS-PW redundancy
The following figure illustrates an application of single segment
pseudowire 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 15-1 Multi-homed CE with single SS-PW redundancy
The application in Figure 15-1 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 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
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
Muley et al. Expires July 4, 2013 [Page 25]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
UP/DOWN status and preferential forwarding status for PW1 are up and
Active, traffic is forwarded over PW1 in both directions.
On failure of the AC between CE1 and PE1, the forwarding state of
the AC on PE3 transitions 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 select PW2 as the new active pseudowire to send
traffic to.
On failure of 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 pseudowire
to send traffic to. 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 in this example, the receipt of the AC status on the CE1-PE1
link is normally sufficient for PE2 to switch to PW2. However, the
operator may want to trigger the switchover of the PW for
administrative reasons, e.g., maintenance, and 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 et al. Expires July 4, 2013 [Page 26]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
15.2. Multiple Multi-homed CEs with single 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 15-2 Multiple Multi-homed CEs with single SS-PW redundancy
The application in Figure 15-2 makes use of the Independent mode of
operation.
CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed 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, from CE1 to PE2 is
Standby; furthermore, assume that the AC from CE2 to PE3 is Standby
and from CE2 to PE4 is Active. The method of deriving Active/Standby
status of the AC is outside the scope of this document.
PE1 advertises the preferential 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 status Standby and
UP/DOWN status "Pseudowire forwarding" for pseudowires PW2 and PW3
to PE3 and PE4. PE3 advertises preferential status Standby and
UP/DOWN status "Pseudowire forwarding" for pseudowires PW1 and PW3
to PE1 and PE2. PE4 advertise the preferential 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
"Pseudowire forwarding" of pseudowires, the PE nodes determine which
Muley et al. Expires July 4, 2013 [Page 27]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
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 pseudowire
to send traffic to.
On failure of PE1 node, PE2 will detect it 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 pseudowire
to send traffic to. 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
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 any primary/secondary procedures, as defined in sections
5.1. 5.1 and 5.2. 5.2 , do not 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.
15.3. Multi-homed CE with MS-PW redundancy
The following figure illustrates an application of multi-segment
pseudowire redundancy.
Muley et al. Expires July 4, 2013 [Page 28]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
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 15-3 Multi-homed CE with MS-PW redundancy
The application in Figure 15-3 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 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. 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.
15.4. Multi-homed CE with MS-PW redundancy and S-PE protection
The following figure illustrates an application of multi-segment
pseudowire redundancy with 1:1 PW protection.
Muley et al. Expires July 4, 2013 [Page 29]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
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 15-4 Multi-homed CE with MS-PW redundancy and protection
The application in Figure 15-4 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. 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.
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 15-4 shows four
separate S-PE nodes for clarity.
Muley et al. Expires July 4, 2013 [Page 30]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
The behavior of this setup is exactly the same as in the setup
in Section 15.3. 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.
15.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. 5.1 and 5.2. 5.2 .
Native |<------------Pseudowire ------------>| Native
Service | | Service
(AC) | |<-PSN1-->| |<-PSN2-->| | (AC)
| V V V V V V |
| +-----+ +-----+ +-----+ |
+----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+
| |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| |
| CE1| | |=========| |=========| | | CE2|
| | +-----+ +-----+ +-----+ | |
+----+ |.||.| |.||.| +----+
|.||.| +-----+ |.||.|
|.||.|=========| |========== .||.|
|.||...PW2-Seg1......|.PW2-Seg2...||.|
|.| ===========|S-PE2|============ |.|
|.| +-----+ |.|
|.|============+-----+============= .|
|.....PW3-Seg1.| | PW3-Seg2......|
==============|S-PE3|===============
| |
+-----+
Figure 15-5 Single homed CE with multi-segment pseudowire 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. A primary PW, PW1 has the
lowest precedence value of zero. A secondary PW, PW2, which is
switched at S-PE2 and has a precedence of 1. Finally, another
secondary PW, PW3, is switched at S-PE3 and has a precedence of 2.
Muley et al. Expires July 4, 2013 [Page 31]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
The precedence is locally configured at the endpoints of the PW,
i.e., T-PE1 and T-PE2. Lower the precedence value, 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, or 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 which 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/acknowledgement procedures to synchronize the choice of
PW to forward on in both directions.
The trigger for sending a request to switchover 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 response
from the other endpoint. In such situation, the T-PE with greater
system address request is given precedence. This helps in
synchronizing PWs in event of mismatch of precedence configuration
as well.
Muley et al. Expires July 4, 2013 [Page 32]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
On recovery of primary PW1, PW1 is selected to forward traffic and
the secondary PW, PW2, is set to standby.
15.6. PW redundancy between H-VPLS MTU-s and PE-rs
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
Figure 15-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 network. MTU-s communicates to PE1-rs and PE2-rs the
forwarding status of its member PWs for a set of VSIs having common
status Active/Standby. It may be signaled using PW grouping with
common group-id in PWid FEC element or Grouping TLV in 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
Muley et al. Expires July 4, 2013 [Page 33]
Internet-Draft PW Preferential Forwarding Status Bit January 4, 2013
example, the primary/secondary procedures as defined in Section 5.2.
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 state of PW group changes from
Standby to Active. All procedures described in Section 6.2. 6.2 are
applicable.
The use of the Preferential Forwarding status bit in Master/Slave
mode is similar to Topology Change Notification in RSTP controlled
IEEE Ethernet Bridges 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 to be sent,
one by MTU-s and another one by PE-rs nodes. Mechanisms to disable
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, 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 et al. Expires July 4, 2013 [Page 34]
