summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6870.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6870.txt')
-rw-r--r--doc/rfc/rfc6870.txt1963
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc6870.txt b/doc/rfc/rfc6870.txt
new file mode 100644
index 0000000..fc0e50f
--- /dev/null
+++ b/doc/rfc/rfc6870.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) P. Muley, Ed.
+Request for Comments: 6870 M. Aissaoui, Ed.
+Updates: 4447 Alcatel-Lucent
+Category: Standards Track February 2013
+ISSN: 2070-1721
+
+ Pseudowire Preferential Forwarding Status Bit
+
+
+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 is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6870.
+
+
+
+
+
+
+
+
+
+Muley & Aissaoui Standards Track [Page 1]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muley & Aissaoui Standards Track [Page 2]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Requirements Language ......................................4
+ 2. Motivation and Scope ............................................4
+ 3. Terminology .....................................................7
+ 4. PE Architecture .................................................9
+ 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 ...................................16
+ 6.3. Coordination of PW Switchover .............................17
+ 6.3.1. Procedures at the Requesting Endpoint ..............18
+ 6.3.2. Procedures at the Receiving Endpoint ...............20
+ 7. Status Mapping .................................................20
+ 7.1. AC Defect State Entry/Exit ................................21
+ 7.2. PW Defect State Entry/Exit ................................21
+ 8. Applicability and Backward Compatibility .......................21
+ 9. Security Considerations ........................................22
+ 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 .............23
+ 12. Contributors ..................................................23
+ 13. Acknowledgments ...............................................24
+ 14. References ....................................................24
+ 14.1. Normative References .....................................24
+ 14.2. Informative References ...................................24
+ Appendix A. Applications of PW Redundancy Procedures .............26
+ A.1. One Multi-Homed CE with Single SS-PW Redundancy ...........26
+ A.2. Multiple Multi-Homed CEs with SS-PW Redundancy ............28
+ A.3. Multi-Homed CE with MS-PW Redundancy ......................30
+ A.4. Multi-Homed CE with MS-PW Redundancy and S-PE Protection ..31
+ A.5. Single-Homed CE with MS-PW Redundancy .....................32
+ A.6. PW Redundancy between H-VPLS MTU-s and PE-rs ..............33
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muley & Aissaoui Standards Track [Page 3]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+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 RFC 6718, "Pseudowire (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 a 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.
+
+ Section 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].
+
+1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [1].
+
+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 attachment
+ circuit (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
+
+
+
+
+Muley & Aissaoui Standards Track [Page 4]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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 that provides the
+ end-to-end connectivity from Customer Edge (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 which to forward user
+ packets. 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. It also defines the procedures
+ the PE nodes follow 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 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, protect a specific subset of a path for the emulated
+ service, consisting of an active PW and/or AC.
+
+
+
+
+Muley & Aissaoui Standards Track [Page 5]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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. 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. By configuration, implementations can designate 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 qualifies 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 effectively achieving revertive protection switching.
+
+ 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 and in
+ which traffic is permanently duplicated at the ingress node on both
+ the currently active and standby subsets of the paths) 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 that PW to the
+ remote endpoints. Only a PW that is up and that 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.
+
+
+
+Muley & Aissaoui Standards Track [Page 6]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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 an SS-PW, or on a T-PE, in the case of an MS-PW. PW
+ redundancy scenarios where the redundant set of PW segments
+ terminates on a Switching Provider Edge (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
+ Public Service Network (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 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 that has been configured (label mapping exchanged between
+ PEs) and is not showing any of the PW or AC status bits
+ specified in [7]. Such a PW is available for forwarding
+ traffic [8].
+
+ Down PW: A PW that either has not been fully configured or has been
+ configured and is showing any of the PW or AC status bits
+ 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 that 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.,
+
+
+
+Muley & Aissaoui Standards Track [Page 7]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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
+ that 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., an SS-PW PE, an MS-PW
+ T-PE, a Hierarchical VPLS (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
+ 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 of
+ the preceding and succeeding segments of the MS-PW. Therefore,
+ it 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. Therefore, it is 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.
+
+
+
+
+
+
+
+
+Muley & Aissaoui Standards Track [Page 8]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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 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 use based on the
+ criteria described in this document.
+
+ +----------------------------------------+
+ | PE Device |
+ +----------------------------------------+
+ Single | | Single | PW Instance
+ AC | + PW Instance X<===========>
+ | | |
+ | |----------------------|
+ <------>o | Single | PW Instance
+ | Forwarder + PW Instance X<===========>
+ | | |
+ | |----------------------|
+ | | Single | PW Instance
+ | + PW Instance X<===========>
+ | | |
+ +----------------------------------------+
+
+ Figure 1. PE Architecture for PW Redundancy
+
+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
+
+
+
+Muley & Aissaoui Standards Track [Page 9]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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
+ it operates as follows:
+
+ 1. For a PW using the PWid ID Forwarding Equivalence Class (PWid FEC)
+ [2], the PW with the lowest PWid value is selected.
+
+ 2. For a PW using the Generalized PWid FEC [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
+ Source Attachment Individual Identifier (SAII) and Target
+ Attachment Individual Identifier (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 that
+ 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 PWid 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.
+
+
+
+
+Muley & Aissaoui Standards Track [Page 10]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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 tiebreaking 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
+ 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 advertise 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 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 Targeted Label Distribution
+ Protocol (T-LDP) status messages between endpoints. In this case,
+ the behavior of the receiving endpoint is outside the scope of this
+ document.
+
+
+
+
+
+
+
+
+
+Muley & Aissaoui Standards Track [Page 11]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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, 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
+ 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 [11], 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 are outside the scope of this document. If the PW is a
+ spoke in H-VPLS, any Media Access Control (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 [10].
+
+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
+
+
+
+Muley & Aissaoui Standards Track [Page 12]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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 is recommended to use the independent mode of operation
+ as in the application described in Section 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.
+
+ 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; however, 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 comply with 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.
+
+
+
+
+
+Muley & Aissaoui Standards Track [Page 13]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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 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 are 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 [10].
+
+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 status bit 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
+ 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
+
+
+
+Muley & Aissaoui Standards Track [Page 14]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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.
+
+ When a PW is in active state, the PEs can forward user packets, OAM
+ packets, and other control plane 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 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 ID 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
+
+
+
+Muley & Aissaoui Standards Track [Page 15]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ PWid FEC TLV with only the Group ID or 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 ID 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
+ 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 & Aissaoui Standards Track [Page 16]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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
+
+6.3. Coordination of PW Switchover
+
+ There are PW redundancy applications that 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.
+
+
+
+Muley & Aissaoui Standards Track [Page 17]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ The trigger for sending a request to switchover by one endpoint of
+ the MS-PW can be an operational event. For example, a failure that
+ 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 acknowledgment 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 switch over.
+
+ This document specifies a second status bit that is used by a PE to
+ request that its peer PE switch over 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 that receives the
+ Request Switchover bit and that 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.
+
+ 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 to which it
+ desires to switch.
+
+ 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.
+
+
+
+
+Muley & Aissaoui Standards Track [Page 18]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ c. The requesting endpoint starts a timer while waiting for 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 switch over 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
+ acknowledgment 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 down state locally, and
+ could use an alternate PW that is up, it MUST perform the
+ following:
+
+ i. Abort the timer.
+
+ ii. Issue a new request to switchover to the alternate PW.
+
+ iii. Restart the timer.
+
+
+
+
+
+
+
+
+
+Muley & Aissaoui Standards Track [Page 19]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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 that 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 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, which is different from
+ the currently active PW but 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.
+
+
+
+Muley & Aissaoui Standards Track [Page 20]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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 that 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 that 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.3.1
+ (Section 8.3.2) in [5] are met for each of the PWs in the redundant
+ set.
+
+ 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 that are part of a redundant set MUST use the same FEC type.
+ When the set uses the PWid FEC element, each PW is uniquely
+ identified by its PW ID. When the redundant set uses the Generalized
+
+
+
+
+Muley & Aissaoui Standards Track [Page 21]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ PWid FEC element, each PW MUST have a unique identifier that 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 the PW Status TLV is found to be not
+ supported by either of its endpoints after status negotiation
+ procedures, then the mechanisms specified in this document cannot be
+ used.
+
+ A PE implementation that is compliant with RFC 4447 [2] and that 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 a 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 PWs must be implemented because
+ the status bits defined in this document have the same security
+ considerations as the PW setup and maintenance protocol defined in
+ RFC 4447 [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 has allocated these from the
+ "Pseudowire 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 & Aissaoui Standards Track [Page 22]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+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
+
+ 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
+
+
+
+Muley & Aissaoui Standards Track [Page 23]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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.
+
+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., Ed., Rosen, E., El-Aawar, N., Smith, T., and G.
+ Heron, "Pseudowire Setup and Maintenance Using the Label
+ Distribution Protocol (LDP)", RFC 4447, April 2006.
+
+ [3] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN
+ Service (VPLS) Using Label Distribution Protocol (LDP)
+ Signaling", RFC 4762, January 2007.
+
+ [4] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui,
+ "Segmented Pseudowire", RFC 6073, January 2011.
+
+ [5] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., Nadeau,
+ T., and Y(J). Stein, "Pseudowire (PW) Operations,
+ Administration, and Maintenance (OAM) Message Mapping", RFC
+ 6310, July 2011.
+
+14.2. Informative References
+
+ [6] Bocci, M. and S. Bryant, "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., Aissaoui, M., and M. Bocci, "Pseudowire Redundancy",
+ RFC 6718, August 2012.
+
+
+
+Muley & Aissaoui Standards Track [Page 24]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ [9] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-
+ to-Edge (PWE3) Architecture", RFC 3985, March 2005.
+
+ [10] Dutta, P., Balus, F., Calvignac, G., and O. Stokes "LDP
+ Extensions for Optimized MAC Address Withdrawal in H-VPLS",
+ Work in Progress, October 2011.
+
+ [11] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual
+ Circuit Connectivity Verification (VCCV): A Control Channel for
+ Pseudowires", RFC 5085, December 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muley & Aissaoui Standards Track [Page 25]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+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 "PW Redundancy" [8].
+
+A.1. One Multi-Homed CE with Single SS-PW Redundancy
+
+ The following figure illustrates an application of SS-PW 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 2. Multi-Homed CE with SS-PW Redundancy
+
+ The application in Figure 2 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 an 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
+ a 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
+ UP/DOWN status and Preferential Forwarding status for PW1 are up and
+ active, traffic is forwarded over PW1 in both directions.
+
+
+
+
+
+Muley & Aissaoui Standards Track [Page 26]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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 selects PW2 as the new active PW to which to send
+ traffic.
+
+ On failure of the 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 PW to which
+ to send traffic. 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 that, 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; 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 & Aissaoui Standards Track [Page 27]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+A.2. Multiple Multi-Homed CEs with 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 3. Multiple Multi-Homed CEs with SS-PW Redundancy
+
+ The application in Figure 3 makes use of the independent mode of
+ operation.
+
+ CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed to 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 and from CE1 to PE2 it
+ is standby; furthermore, assume that the AC from CE2 to PE3 is
+ standby and from CE2 to PE4 it is active. The method of deriving the
+ active/standby status of the AC is outside the scope of this
+ document.
+
+ PE1 advertises the Preferential Forwarding 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 Forwarding status
+ standby and UP/DOWN status "Pseudowire forwarding" for pseudowires
+ PW2 and PW3 to PE3 and PE4. PE3 advertises Preferential Forwarding
+ status standby and UP/DOWN status "Pseudowire forwarding" for
+ pseudowires PW1 and PW3 to PE1 and PE2. PE4 advertises the
+ Preferential Forwarding 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
+
+
+
+
+Muley & Aissaoui Standards Track [Page 28]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ "Pseudowire forwarding" of pseudowires, the PE nodes determine which
+ 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 PW to which
+ to send traffic.
+
+ On failure of the PE1 node, PE2 will detect the failure 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 PW to which to send traffic. 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 have 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 no primary/secondary procedures, as defined in Sections 5.1
+ and 5.2, 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muley & Aissaoui Standards Track [Page 29]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+A.3. Multi-Homed CE with MS-PW Redundancy
+
+ The following figure illustrates an application of MS-PW redundancy.
+
+ 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 4. Multi-Homed CE with MS-PW Redundancy
+
+ The application in Figure 4 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 an 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. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muley & Aissaoui Standards Track [Page 30]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+A.4. Multi-Homed CE with MS-PW Redundancy and S-PE Protection
+
+ The following figure illustrates an application of MS-PW redundancy
+ with 1:1 PW protection.
+
+ 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 5. Multi-Homed CE with MS-PW Redundancy and Protection
+
+ The application in Figure 5 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, 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.
+
+
+
+
+
+Muley & Aissaoui Standards Track [Page 31]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ 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 5 shows four separate
+ S-PE nodes for clarity.
+
+ The behavior of this setup is exactly the same as the setup in
+ Section 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.
+
+A.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. and 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 6. Single-Homed CE with MS-PW 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 and has the lowest precedence value of
+
+
+
+Muley & Aissaoui Standards Track [Page 32]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ zero; a secondary PW, PW2, which is switched at S-PE2 and has a
+ precedence of 1; and another secondary PW, PW3, which 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. The lower the precedence value, the 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, 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 that 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/acknowledgment procedures to synchronize the choice of PW
+ to forward on in both directions.
+
+ The trigger for sending a request to switch over 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 a response
+ from the other endpoint. In such a situation, the T-PE with greater
+
+
+
+
+
+Muley & Aissaoui Standards Track [Page 33]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ system address request is given precedence. This helps in
+ synchronizing PWs in the event of mismatch of precedence
+ configuration as well.
+
+ On recovery of the primary PW, PW1 is selected to forward traffic and
+ the secondary PW, PW2, is set to standby.
+
+A.6. PW Redundancy between H-VPLS MTU-s and PE-rs
+
+ The 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
+
+ A.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 the network. MTU-s communicates to PE1-rs and PE2-rs the
+ forwarding status of its member PWs for a set of Virtual Switch
+ Instances (VSIs) having common status active/standby. It may be
+
+
+
+Muley & Aissaoui Standards Track [Page 34]
+
+RFC 6870 PW Preferential Forwarding Status Bit February 2013
+
+
+ signaled using PW grouping with a common group-id in the PWid FEC
+ element or Grouping TLV in the 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 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 the state of the 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 the IEEE Ethernet
+ Bridges controlled by Rapid Spanning Tree Protocol (RSTP) 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 being sent: one by MTU-s and another one by PE-rs nodes.
+ Mechanisms to disable a 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, 94043, 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 & Aissaoui Standards Track [Page 35]
+