Network Working Group Praveen Muley, Ed.
Internet Draft Mustapha Aissaoui, Ed.
Updates: RFC5542 (if approved) Alcatel-Lucent
Intended Status: Standards Track
Expires: November 14, 2010
May 14, 2010
Pseudowire Preferential Forwarding Status Bit
draft-ietf-pwe3-redundancy-bit-03.txt
Abstract
This document describes a mechanism for standby status signaling 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 needed
to indicate a preferential forwarding status 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.
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 14, 2010.
Copyright Notice
Muley et al. Expires April 14, 2010 [Page 1]
Internet-Draft Preferential Forwarding Status Bit October 2009
Copyright (c) 2010 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.........................................5
3. Terminology..................................................7
4. PE Architecture..............................................8
5. Modes of Operation...........................................9
5.1. Independent Mode:.......................................9
5.2. Master/Slave Mode:......................................10
6. PW State Transition Signaling Procedures.....................12
6.1. PW Standby Notification Procedures in Independent mode..12
6.2. PW Standby notification procedures in Master/Slave mode.12
6.2.1. PW State Machine...................................13
6.3. Coordination of PW Switchover...........................14
6.3.1. Procedures at the requesting endpoint..............16
6.3.2. Procedures at the receiving endpoint...............17
7. Operational Status Mapping...................................18
7.1. AC Defect State Entry/Exit..............................18
7.2. PW Defect State Entry/Exit..............................18
8. Applicability and Backward Compatibility.....................19
9. Security Considerations......................................19
10. MIB Considerations..........................................19
11. IANA Considerations.........................................20
Muley et al. Expires March 14, 2010 [Page 2]
Internet-Draft Preferential Forwarding Status Bit October 2009
11.1. Status Code for PW Preferential Forwarding Status......20
11.2. Status Code for PW Request Switchover Status...........21
12. Major Contributing Authors..................................21
13. Acknowledgments.............................................22
14. References..................................................22
14.1. Normative References...................................22
14.2. Informative References.................................22
15. Appendix A - Applications of PW Redundancy Procedures.......23
15.1. One Multi-homed CE with single SS-PW redundancy........23
15.2. Multiple Multi-homed CEs with single SS-PW redundancy..25
15.3. Multi-homed CE with MS-PW redundancy...................26
15.4. Single Homed CE with MS-PW redundancy..................28
15.5. PW redundancy between H-VPLS MTU-s and PE-rs...........29
Author's Addresses..............................................31
1. Introduction
In Virtual Private Wire Services (VPWS) or Virtual Private Local Area
network Services (VPLS) that use SS-PWs, 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)
label switched path (LSP) with a fast reroute (FRR) backup or an end-
to-end backup LSP. There are, however, applications where PSN
protection is insufficient to fully protect the PW-based service.
These include the following:
In a VPWS service where the Customer Edge (CE) node is dual homed to
a pair of PE nodes, PW redundancy mechanisms are required to ensure
that the correct PW is used for forwarding when attachment circuit
(AC) redundancy is used. PW redundancy mechanisms are also required
when multiple redundant MS-PWs are used between T-PEs, to ensure that
both T-PEs use the same MS-PW to forward to one another.
In a hierarchical VPLS (H-VPLS) service, PW redundancy mechanisms are
required to enable a multi-tenant unit switch (MTU-s) to be dual-
homed to two PE-rs devices.
In these cases, pseudowire redundancy mechanisms are required. These
scenarios are described in the PW redundancy and framework document
[5].
Scenarios, such as those above, therefore rely on a set of two or
more pseudowires to protect a given VPWS or VPLS . Only one of these
pseudowires is used by the PEs to forward user traffic on at any
given time. This is the active PW. The other PWs in the set are
Muley et al. Expires March 14, 2010 [Page 3]
Internet-Draft Preferential Forwarding Status Bit October 2009
considered standby and are not used for forwarding unless they become
active. This provides a 1:1 or N:1 PW protection with the possibility
of multi-homing between the CE and the PEs.
In order to support AC or spoke PW redundancy, at least one of the
PEs on which a PW terminates must be different from that on which the
primary PW terminates, as described in [5]. Figure 1-1 illustrates an
application of Active and Standby PWs.
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnels-->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| | | +-----+
| |----------|....|...PW1.(active)...|....|----------| |
| | | |==================| | | CE2 |
| CE1 | +----+ |PE2 | | |
| | +----+ | | +-----+
| | | |==================| |
| |----------|....|...PW2.(standby)..| |
+-----+ | | PE3|==================| |
AC +----+ +----+
Figure 1-1: Reference Model for PW Redundancy
In MS-PW applications, PW redundancy is also required to protect the
service against failures of the switching PEs, which cannot be
protected by PSN mechanisms. In addition, PW redundancy is also
required if CEs are dual-homed to the PEs, as described above. In
this case, multiple MS-PWs are configured between a pair of T-PE
nodes, as described in Figure 2 of [5]. The paths of these MS-PWs are
diverse in that they are switched at different S-PE nodes. Only one
of these MS-PWs is active at any given time, while the others are
standby.
This document specifies a new PW status bit to indicate the
preferential forwarding status of the PW for the purpose of notifying
the remote PE of the preferential forwarding state of each PW in the
redundancy set i.e. active or standby. This status bit is different
from the operational status bits already defined in the PWE3 control
Muley et al. Expires March 14, 2010 [Page 4]
Internet-Draft Preferential Forwarding Status Bit October 2009
protocol [2]. In addition, a second status bit is defined to allow
peer PE nodes to coordinate a switchover operation of the PW from
active to standby, or vice versa.
2. Motivation and Scope
The PWE3 control protocol [2] defines the following status codes in
PW the status TLV to indicate the operational state for an AC and a
PW:
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 scenarios defined in [5] allow the provisioning of a primary PW
and one or many secondary PWs in the same VPWS or VPLS service.
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 operational state of the PW as well as the remote
operational state of the PW as indicated in the status bits of the PW
it received from the peer PE node.
In the absence of faults, all PWs are operationally 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, to allow a PE node to indicate
the preferential forwarding state of a PW to its peer PE node.
In addition, a second status bit is defined to allow peer PE nodes to
coordinate a switchover operation of the PW if required by the
application. This is known as the 'request switchover' status bit.
Together, the mechanisms described in this document achieve the
following PW protection capabilities:
Muley et al. Expires March 14, 2010 [Page 5]
Internet-Draft Preferential Forwarding Status Bit October 2009
a. A MANDATORY 1:1 PW protection with a single active PW and one
standby PW. An active PW can forward data traffic and control
plane traffic, such as OAM packets. A standby PW does not
carry data traffic.
b. An OPTIONAL N:1 PW protection scheme with a single active PW
and N standby PWs.
c. An OPTIONAL 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. . 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. An OPTIONAL, locally configured precedence to govern the
selection of a PW when more than one PW qualify for the active
state, as defined in sections 5.1. and 5.2. The PW with the
lowest precedence value has the highest priority. Precedence
may be configured via, for example, a local configuration
parameter at the PW endpoint.
e. OPTIONALLY, implementations can designate by configuration one
PW in the 1:1 or N:1 set 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. and 5.2. , a PE node
selects the primary PW in preference to a secondary PW. In
other words, the primary PW has implicitly the lowest
precedence value. Furthermore, a PE node reverts to the
primary PW immediately after it comes back up or after the
expiration of a delay. The PE node can use the PW precedence
to select a secondary PW among many that qualify for active
state.
These 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 operationally 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.
Muley et al. Expires March 14, 2010 [Page 6]
Internet-Draft Preferential Forwarding Status Bit October 2009
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.
The above mechanisms and operational modes allow the following:
a.Multi-homing of a CE device to two or more PE nodes.
b.Multi-homing of a PE node to two or more PE nodes.
More details of how these schemes are used can be found in
Informative Appendix A.
Note that this document specifies the mechanisms to support PW
redundancy where a set of redundant PWs terminate on either a PE (for
SS-PW) or a T-PE (for MS-PW). PW redundancy scenarios where the
redundant set of PW segments terminate on an S-PE are for further
study.
3. Terminology
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 [2]. Such a PW is available for forwarding
traffic.
DOWN PW: A PW that has either not been fully configured, or has been
configured and is in any of the PW defect states specified
in [2], such a PW is not available for forwarding traffic.
Active PW: An UP PW used for forwarding user and OAM traffic.
Standby PW: An UP PW that is not used for forwarding user traffic,
but may forward OAM traffic.
Primary PW: the PW which a PW endpoint activates in preference to any
other PW when more than one PW qualify 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.
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
Muley et al. Expires March 14, 2010 [Page 7]
Internet-Draft Preferential Forwarding Status Bit October 2009
considered secondary. There is no Revertive mechanism among
secondary PWs.
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.
This document uses the term 'PE' to be synonymous with both PEs as
per RFC3985 and T-PEs as per RFC5659.
This document uses the term 'PW' to be synonymous with both PWs as
per RFC3985 and SS-PWs and MS-PWs as per RFC5659.
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 RFC3985 [6]. The
forwarder selects which of the redundant PWs to using 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 4-1 PE Architecure for PW redundancy
Muley et al. Expires March 14, 2010 [Page 8]
Internet-Draft Preferential Forwarding Status Bit October 2009
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 PW they intend to make
active and which PWs they intend to make standby. They advertise the
corresponding Active/Standby forwarding state for each PW. Each PW
endpoint compares local and remote status and uses the PW that is
operationally UP at both endpoints and that shows Active states at
both the local and remote endpoint.
If more than one PW qualify for the Active state, each PW endpoint
MUST implement a common mechanism to choose the PW for forwarding. If
this mechanism uses a precedence value for the PW, it must use the PW
with the lowest configured precedence value. The precedence parameter
is optional.
If more than one PW qualify for the Active state, and the PW endpoint
is configured with one PW as primary, it must use 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. These
primary/secondary procedures are optional.
In steady state with consistent configuration, a PE will always find
an Active PW. However, it is possible that due to a misconfiguration,
such a PW is not found. In the event that an active PW is not found,
a management indication SHOULD be generated. If a management
indication for failure to find an active PW was generated and an
active PW is subsequently found, a management indication should be
generated, so clearing the previous failure indication. Additionally,
a PE may use the optional request switchover procedures described in
Section 6.3. to have both PE nodes switch to a common PW.
There may also be transient conditions where endpoints do not share a
common view of the active/standby state of the PWs. This could be
caused by propagation delay of the T-LDP status messages between
Muley et al. Expires March 14, 2010 [Page 9]
Internet-Draft Preferential Forwarding Status Bit October 2009
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 Active at both
endpoints. 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, but the status bits exchanged
indicate the PW is in Standby state 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., VCCV, to be sent and received in order to
test the liveliness of standby PWs. 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 RFC4762
[3] and [9].
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 Active/Standby
status bit. The other endpoint node, the Slave, MUST follow the
decision of the Master node based on the received status bits.
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 redundancy 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 Active/Standby status bits received from the Slave
nodes.
Muley et al. Expires March 14, 2010 [Page 10]
Internet-Draft Preferential Forwarding Status Bit October 2009
If more than one PW qualify for the Active state, each PW endpoint
MUST implement a common mechanism to choose the PW for forwarding. If
this mechanism uses a precedence value for the PW, it must use the PW
with the lowest configured precedence value. The precedence parameter
is optional.
If more than one PW qualify for the Active state, and the PW endpoint
is configured with one PW as primary, it must use 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. These
primary/secondary procedures are optional.
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.
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 above
behavior assumes correct configuration of the Master and Slave
endpoints. This document does not define a mechanism to detect errors
in the configuration.
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 forwarding status sent by the Master endpoint indicates Active
state. 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, but the status bits sent by the
Master endpoint indicate the PW is in Standby state. In this state
the endpoints MUST NOT forward data traffic over the PW but MAY allow
PW OAM packets, e.g., VCCV, to be sent and received. If the PW is a
Muley et al. Expires March 14, 2010 [Page 11]
Internet-Draft Preferential Forwarding Status Bit October 2009
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 RFC4762 [3] and [9].
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 the Standby state of the
PW by one PE to the far end PE.
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 [5]). They advertise the
corresponding Active/Standby forwarding state for each PW. An active
forwarding state is indicated by clearing the Active/Standby status
bit in the PW status TLV. A standby forwarding state is indicated by
setting the Active/Standby 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 operationally UP at both
endpoints and which shows both local Active and remote Active states.
When a PW is in active state, the PEs can forward both user packets
and OAM packets over the PW.
When a PW is in standby state, the PEs MUST NOT forward user packets
over the PW but MAY forward PW OAM packets.
For MS-PWs, S-PEs MUST relay the PW status notification containing
both the operational and 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.
Muley et al. Expires March 14, 2010 [Page 12]
Internet-Draft Preferential Forwarding Status Bit October 2009
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 also 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 Grouping TLV in Generalized PWid FEC Element 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 using a PW FEC TLV with only the
group ID set, to denote this change in status for all affected PW
connections. This status message contains either the PW FEC TLV with
only the Group ID set, or else it contains the PW Generalized 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 used with the
Generalized ID FEC Element, can be used to send status notification
for all arbitrary set of PWs. For example, Group-ID in PWiD may be
used to send wildcard status notification message for a group of PWs
when PWid FEC element is used for PW state signaling. When
Generalized PWiD FEC Element defined is used in PW state signaling,
PW Grouping TLV may be used for wildcard status notification for a
group of PWs.
For MS-PWs, S-PEs MUST relay the PW status notification containing
both the operational and preferential forwarding status bits between
ingress and egress PW segments as per the procedures defined in [4].
6.2.1. PW State Machine
It is convenient to describe the PW state change behavior in terms of
a state machine (Table 1). The PW state machine is explained in
detail in the two defined states and the behavior is presented as a
state transition table. The same state machine is applicable to PW
Groups.
Muley et al. Expires March 14, 2010 [Page 13]
Internet-Draft Preferential Forwarding Status Bit October 2009
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: No action
Table 1 PW State Transition Table
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
Muley et al. Expires March 14, 2010 [Page 14]
Internet-Draft Preferential Forwarding Status Bit October 2009
redundant MS-PW is identified in [5]. 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 PW 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 redundancy 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.
The request switchover bit is OPTIONAL and, if received by a PE, is
ignored if not understood.
If the request switchover bit is supported by both sending and
receiving PEs, the following procedures MUST be followed by both
endpoints of a PW to coordinate the switchover of the PW.
S-PEs nodes MUST relay the PW status notification containing the
operational status bits, as well as the 'preferential forwarding' and
'request switchover' status bits between ingress and egress PW
segments as per the procedures defined in [4].
Muley et al. Expires March 14, 2010 [Page 15]
Internet-Draft Preferential Forwarding Status Bit October 2009
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.
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
'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 operational Down state
locally, and could use an alternate PW which is operationally UP,
it must perform the following:
Muley et al. Expires March 14, 2010 [Page 16]
Internet-Draft Preferential Forwarding Status Bit October 2009
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 an operational Down state
locally, and could not use an alternate PW which is operationally
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 operationally UP, the receiving
endpoint must perform the following:
i. Activate the PW.
ii. Send an update status notification message with the
'preferential forwarding' status bit clear and the
'request switchover' bit reset on the newly active PW ,
and send an update status notification message with the
'preferential forwarding' status bit set in the
previously active PW.
iii. Upon receiving a status notification message with the
'request switchover' bit set on a PW different from the
currently active one, and the requested PW is
Muley et al. Expires March 14, 2010 [Page 17]
Internet-Draft Preferential Forwarding Status Bit October 2009
operationally Down, the receiving endpoint MUST ignore
the request.
7. Operational 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 remote 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 mapping the operational status between a PW and an
AC in a PW service must follow the rules in [7] with the following
modifications.
7.1. AC Defect State Entry/Exit
A PE enters the AC receive (or transmit) defect state for a PW when
one or more of the conditions specified for this PW type in [7] 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 redundancy set when required by the PW type
in [7].
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 redundancy set when required by
the PW type in [7].
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 [7] are met for all PWs in the redundancy set.
When a PE enters the PW receive (or transmit) defect state for a PW
service, it must send a reverse (or forward) defect indication over
one or more of the PWs in the redundancy set if the PW failure was
detected by this PE without receiving a forward defect indication
from the remote PE [7].
Muley et al. Expires March 14, 2010 [Page 18]
Internet-Draft Preferential Forwarding Status Bit October 2009
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 redundancy set if applicable.
8. Applicability and Backward Compatibility
The mechanism defined in this document is applicable to applications
where standby state signaling of a PW or PW group is required.
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, will ignore
these status bits if they are received from a peer PE.
9. Security Considerations
This document uses the LDP extensions that are needed for protecting
pseudo-wires. It will have the same security properties as in the
PWE3 control protocol [2].
10. MIB Considerations
This document makes the following update to the PwOperStatusTC
textual convention in RFC5542 [8]:
PwOperStatusTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicates the operational status of the PW.
- up(1): Ready to pass packets.
- down(2): PW signaling is not yet finished, or
indications available at the service
level indicate that the PW is not
passing packets.
Muley et al. Expires March 14, 2010 [Page 19]
Internet-Draft Preferential Forwarding Status Bit October 2009
- testing(3): AdminStatus at the PW level is set to
test.
- dormant(4): The PW is not in a condition to pass
packets but is in a 'pending' state,
waiting for some external event.
- notPresent(5): Some component is missing to accomplish
the setup of the PW. It can be
configuration error, incomplete
configuration, or a missing H/W component.
- lowerLayerDown(6): One or more of the lower-layer interfaces
responsible for running the underlying PSN
is not in OperStatus 'up' state."
SYNTAX INTEGER {
up(1),
down(2),
testing(3),
dormant(4),
notPresent(5),
lowerLayerDown(6)
}
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".
Muley et al. Expires March 14, 2010 [Page 20]
Internet-Draft Preferential Forwarding Status Bit October 2009
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. Major Contributing Authors
The editors would like to thank Matthew Bocci, Pranjal Kumar Dutta,
Giles Heron, Marc Lasserre, Luca Martini, Thomas Nadeau, Jonathan
Newton, Hamid Ould-Brahim, and Olen Stokes, who made a major
contribution to the development of this document.
Matthew Bocci
Alcatel-Lucent
Email: matthew.bocci@alcatel-lucent.com
Pranjal Kumar Dutta
Alcatel-Lucent
Email: pdutta@alcatel-lucent.com
Giles Heron
BT
giles.heron@gmail.com
Marc Lasserre
Alcatel-Lucent
Email: mlasserre@alcatel-lucent.com
Luca Martini
Cisco Systems, Inc.
Email: lmartini@cisco.com
Thomas Nadeau
BT
tom.nadeau@bt.com
Jonathan Newton
Cable & Wireless
Email: Jonathan.Newton@cw.com
Hamid Ould-Brahim
Nortel
Email: hbrahim@nortel.com
Muley et al. Expires March 14, 2010 [Page 21]
Internet-Draft Preferential Forwarding Status Bit October 2009
Olen Stokes
Extreme Networks
Email: ostokes@extremenetworks.com
13. Acknowledgments
The authors would like to thank Vach Kompella, Kendall Harvey,
Tiberiu Grigoriu, John Rigby, Prashanth Ishwar, Neil Hart, Kajal
Saha, Florin Balus, Philippe Niger, Dave McDysan, and Roman
Krzanowski for their valuable comments and suggestions.
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.
14.2. Informative References
[4] Martini, L., et al., "Segmented Pseudo Wire", draft-ietf-pwe3-
segmented-pw-13.txt, August 2009.
[5] Muley, P., et al., "Pseudowire (PW) Redundancy", draft-ietf-
pwe3-redundancy-02.txt", October 2009.
[6] Bryant, S., et al., "Pseudo Wire Emulation Edge-to-Edge (PWE3)
Architecture", RFC 3985, March 2005
[7] Aissaoui, M., et al., "Pseudo Wire (PW) OAM Message Mapping",
draft-ietf-pwe3-oam-msg-map-11.txt, June 2009.
[8] Nadeau, T., Zelig, D., Nicklass, O., "Definitions of Textual
Conventions for Pseudowire (PW) Management", RFC5542, May 2009
Muley et al. Expires March 14, 2010 [Page 22]
Internet-Draft Preferential Forwarding Status Bit October 2009
[9] Dutta, P., Lasserre, M., Stokes, O., "LDP Extensions for
Optimized MAC Address Withdrawal in H-VPLS", draft-ietf-l2vpn-
vpls-ldp-mac-opt-00.txt, April 2009
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 the scenarios
described in the PW redundancy requirements and framework document
[5].
15.1. One Multi-homed CE with single SS-PW redundancy
The following figure illustrates an application of single segment
pseudowire redundancy.
|<-------------- 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 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 [5]).
Muley et al. Expires March 14, 2010 [Page 23]
Internet-Draft Preferential Forwarding Status Bit October 2009
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
operational 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 operationally down. PE2 matches the local and
remote preferential forwarding status of "active" and operational
status "Up" 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 operational status "Up" and select
PW2 as the new active pseudo-wire 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 operational status of the AC
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 Active/Standby status is driven by the AC forwarding state
as determined by the AC dual-homing protocol used.
Muley et al. Expires March 14, 2010 [Page 24]
Internet-Draft Preferential Forwarding Status Bit October 2009
15.2. Multiple Multi-homed CEs with single SS-PW redundancy
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- 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.
PE1 advertises the preferential status "active" and operational
status "UP" 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" where as operational
status "UP" for pseudowires PW2 and PW3 to PE3 and PE4. PE3
advertises preferential status "standby" where as operational status
"UP" for pseudo-wires PW1 and PW3 to PE1 and PE2. PE4 advertise the
preferential status "active" and operational status "UP" for pseudo-
wires PW2 and PW4 to PE2 and PE1 respectively. The method of
deriving Active/Standby status of the AC is outside the scope of
this document. Thus by matching the local and remote preferential
forwarding status of "active" and operational status "Up" of
pseudowire, the PE nodes determine which PW should be in the Active
state. In this case it is PW4 that will be selected.
Muley et al. Expires March 14, 2010 [Page 25]
Internet-Draft Preferential Forwarding Status Bit October 2009
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 operationally down. PE2 and PE4
match the local and remote preferential forwarding status of
"active" and operational status "Up" 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 operational
status "Up" and select PW2 as the new active pseudo-wire 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. and 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 March 14, 2010 [Page 26]
Internet-Draft Preferential Forwarding Status Bit October 2009
Native |<-----------Pseudo Wire----------->| 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.
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
pseudo-wire. This application requires support for MS-PW with
segments of the same type as described in [4].
The operation in this case is the same as in the case of SS-PW as
described in Section 15.1. . The only difference is that the S-PE
nodes need to relay the PW status notification containing both the
operational and forwarding status to the T-PE nodes.
Muley et al. Expires March 14, 2010 [Page 27]
Internet-Draft Preferential Forwarding Status Bit October 2009
15.4. Single Homed CE with MS-PW redundancy
The following is an application of the independent mode of operation
along with the optional request switchover procedures in order to
provide N:1 PW protection. A revertive behavior to a primary PW is
shown as an example of configuring and using the primary/secondary
procedures described in sections 5.1. and 5.2. .
Native |<------------Pseudo Wire------------>| 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-4 Single homed CE with multi-segment pseudo-wire 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. 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 operational 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 operationally UP, T-PE1 and T-PE2
will use PW1 to forward user packets.
Muley et al. Expires March 14, 2010 [Page 28]
Internet-Draft Preferential Forwarding Status Bit October 2009
If PW1 fails, then the T-PE detecting the failure will send a status
notification to the remote T-PE with a "PW Down" bit set as well as
the 'preferential forwarding' status bit set on PW1. It will also
clear 'preferential forwarding' status bit on PW2 as it is the next
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 operational status of "Up" 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 operational status
bits. In this case, T-PE1 and/or T-PE2 can invoke the optional
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.
On recovery of primary PW1, PW1 is selected to forward traffic
and the secondary PW, PW2, is set to standby.
15.5. 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.
Muley et al. Expires March 14, 2010 [Page 29]
Internet-Draft Preferential Forwarding Status Bit October 2009
|<-PSN1-->| |<-PSN2-->|
V V V V
+-----+ +--------+
|MTU-s|=========|PE1-rs |========
|..Active PW group.... | H-VPLS-core
| |=========| |=========
+-----+ +--------+
|.|
|.| +--------+
|.|===========| |==========
|...Standby PW group |.H-VPLS-core
=============| PE2-rs|==========
+--------+
Figure 15-5 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
example, the primary/secondary procedures,as defined in Section 5.2.
, are used but this can be based on any other policy.
Whenever MTU-s performs a switchover, it sends a wildcard
Notification Message to PE2-rs for the Standby PW group containing PW
Status TLV with PW Standby 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. 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
[6] 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
Muley et al. Expires March 14, 2010 [Page 30]
Internet-Draft Preferential Forwarding Status Bit October 2009
Author's Addresses
Praveen Muley
Alcatel-lucent
701 E. Middlefiled 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 March 14, 2010 [Page 31]
