RFC 6870
Pseudowire Preferential Forwarding Status Bit
RFC 6870: Pseudowire Preferential Forwarding Status Bit 🎀
- Series: Internet Engineering Task Force (IETF) 🌸
- Authors: P. Muley, Ed. and M. Aissaoui, Ed. 💅
- Organization: Alcatel-Lucent
- Category: Standards Track ✨
- Date: February 2013
- ISSN: 2070-1721
- Updates: RFC 4447 🔥
Abstract 🦋
okay so this doc is about how two redundant pseudowires (PWs) can tell each other which one is the active one and which one is standby 💖 A set of Redundant PWs gets configured between Provider Edge (PE) nodes in single-segment pseudowire (SS-PW) setups, or between Terminating Provider Edge (T-PE) nodes in Multi-Segment Pseudowire (MS-PW) setups.
so the PE/T-PE nodes need a way to say "hey, this one is the PW I want you to use for forwarding." 🫶 That's where a brand new status bit comes in. It indicates Preferential Forwarding status, which is either active or standby, for each PW in a redundant set. iconic 👑
there's also a second status bit 🧚 which lets the peer PE nodes coordinate a switchover operation of the PW. teamwork makes the dream work!!
finally, this doc updates RFC 4447 by adding details about how to handle 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). If you want more info on Internet Standards, check Section 2 of RFC 5741 📚
Info about the current status of this document, any errata, and how to give feedback on it is available at http://www.rfc-editor.org/info/rfc6870. 🌈
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, because 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 they are provided without warranty as described in the Simplified BSD License. 🎀
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 ..............331. Introduction 💫
okay bestie, this doc gives us the extensions to the Pseudowire (PW) control plane so it can support the protection schemes of the PW redundancy applications described in RFC 6718, "Pseudowire (PW) Redundancy" [8]. it's giving protection, it's giving reliability 🛡️
it specifies a new PW status bit, plus the procedures that Provider Edge (PE) nodes follow to tell each other the Preferential Forwarding state of each PW in the redundant set. that state is either 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]. on top of that, this doc specifies a second status bit so peer PE nodes can coordinate a switchover of the PW from active to standby, or vice versa 🔄
because of these new status bits, this doc updates RFC 4447 in two ways 💅 First, it clarifies the rules for processing status bits that RFC 4447 never originally defined. Second, it defines that a status bit can indicate a status other than a fault, or can indicate an instruction to the peer PE. more details are in Section 8 🧚
Section 15 shows in detail how the mechanisms in this doc get used to achieve the protection schemes from the applications described in [8]. the full picture, no cap 🌈
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]. these are the official rule words, so they carry real weight here 🫶
ok that's the first chunk, bestie 💜 more is coming in the next part, so stay tuned 🦋
2. Motivation and Scope ✨
okay so the PW setup and maintenance protocol has these status codes in the PW Status TLV 🎀 that tell you the vibe of 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
0x00000010 - Local PSN-facing PW (egress) Transmit FaultThe applications defined in [8] let you set up 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 whole point of PW redundancy is to keep end-to-end connectivity for the emulated service alive by activating the correct PW whenever an AC, a PE, or a PW fails 🦋. The correct PW is the one that gives you end-to-end connectivity from Customer Edge (CE) to CE so packets keep flowing. Literally the main character of the story 👑.
A PE node picks which PW to activate at any given time to forward user packets ✨. That choice looks at the local state of the PW and AC, and also the remote state of the PW and AC, as shown in the PW status bits it got from the peer PE node 🫶.
When nothing is broken, all PWs are up both locally and remotely, so a PE node needs to pick a single PW to forward user packets on. That one is called the active PW 🌸. Everything else is in standby and must not be used to forward user packets 🙈.
So both ends of the service pick the same PW for forwarding, this document defines a brand new status bit: the Preferential Forwarding status bit 💅. It also defines the procedures PE nodes follow to tell their peer PE node the Preferential Forwarding state of a PW 🔥.
There is also a second status bit, the Request Switchover status bit, which lets peer PE nodes coordinate a switchover operation of the PW if the application needs it 🧚.
Together, the mechanisms in this document get you the following protection capabilities defined in [8] 🌈:
a. 1:1 protection, where a specific subset of a path for an emulated service, made of a standby PW and/or AC, protects another specific subset of a path for the emulated service, made 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. N:1 protection, where N specific subsets of a path for an emulated service, each made of a standby PW and/or AC, protect a specific subset of a path for the emulated service, made of an active PW and/or AC 🍓.
c. A mechanism that lets PW endpoints coordinate the switchover to a given PW using an explicit request/acknowledgment switchover procedure. This works alongside the independent mode of operation and is described in Section 6.3. 6.3. It can be invoked manually by the user, which gives you a manual switchover capability. It can also be invoked automatically to fix a situation where the PW endpoints could not match the two directions of the PW 🎀.
d. A locally configured precedence that decides which PW gets picked 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 can be configured through, 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 rest 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 picks the primary PW over a secondary PW. In other words, the primary PW has implicitly the lowest precedence value. Also, a PE node reverts to the primary PW immediately after it comes back up or after a delay expires, which is revertive protection switching 😭🫶.
1+1 protection (where one specific subset of a path for an emulated service, made of a standby PW and/or AC, protects another specific subset of a path for the emulated service, and traffic is permanently duplicated at the ingress node on both the currently active and standby subsets of the paths) is not supported 💀. Not me being like "wait, that's a no" 🙅♀️.
The protection schemes above are provided using the following operational modes 🦋:
- An independent mode of operation, where each PW endpoint node uses its own local rule to pick which PW it wants 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 ✨.
- A master/slave mode, where one PW endpoint, the master endpoint, picks and dictates to the other endpoint(s), the slave endpoint(s), which PW to activate. This is described in Section 5.2 🧚.
Note that this document specifies the mechanisms to support PW redundancy where a set of redundant PWs terminate on either a PE (for an SS-PW) or on a T-PE (for an MS-PW) 💖. PW redundancy scenarios where the redundant set of PW segments terminates on a Switching Provider Edge (S-PE) are still 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., 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. 💅
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 picks 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 Redundancy5. Modes of Operation 🧚
There are two modes of operation for the use of the PW Preferential Forwarding status bits 🔥:
- independent mode 🦋
- master/slave mode 👑
5.1. Independent Mode ✨
okay so in independent mode, each PW endpoint node picks for itself which PWs are allowed to become active and which ones aren't 🧚. Then it advertises the matching active or standby Preferential Forwarding status for each PW. Each PW endpoint compares the local and remote status bits, and it uses the PW that is up at both endpoints and that advertised active Preferential Forwarding status at both the local and remote endpoints 💅.
In this mode, the Preferential Forwarding status shows each endpoint's preferred forwarding state, but the actual forwarding state of the PW comes from comparing 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 works like this:
- For a PW using the PWid ID Forwarding Equivalence Class (PWid FEC) [2], the PW with the lowest PWid value is selected.
- 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 ofAGI::SAII::TAII, while the PE with the highest system IP address MUST use the unsigned integer form ofAGI::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, so 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 🍓:
- 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.
- 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 🌸.
- 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 so that tiebreaking works with 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. Even so, 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 also scenarios where each PE needs to advertise active Preferential Forwarding status on a single PW in the redundant set. To make sure 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 because of a misconfiguration 💀. If 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 too, so that it clears 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 don't 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 that case, the behavior of the receiving endpoint is outside the scope of this document 🎀.
So, in this mode of operation, the following definitions of active and standby PW states apply:
- 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 👑.
- 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 they 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 it is responsible for selecting which PW both endpoints must use to forward user traffic 🫅.
The master indicates the forwarding state in the PW Preferential Forwarding status bit. The other endpoint node, the slave, MUST follow the decision of the master node based on the received status bits. In other words, the Preferential Forwarding status bit sent by the master node indicates the actual forwarding state of the PW at the master node 💖.
There is a single PE master PW endpoint node and one or many PE PW endpoint slave nodes. The assignment of master/slave roles to the PW endpoints is performed by local configuration. Note that the behavior described in this section assumes correct configuration of the master and slave endpoints. This document does not define a mechanism to detect errors in the configuration, and misconfiguration might lead to protection switchover failing to work correctly 🙃. Furthermore, this document does not specify the procedures for a backup master node. In deployments where PE node protection is required, it 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. The master does not forward user traffic to any other PW in the redundant set to the slave node, and it 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:
- 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.
- If the PW endpoint is configured with one PW as primary and one or more PWs as secondary, it MUST select the primary PW in preference to all secondary PWs. If a primary PW is not available, it MUST use the secondary PW with the lowest precedence value. If the primary PW becomes available, a PW endpoint MUST revert to it immediately or after the expiration of a configurable delay 🌷.
The slave endpoint(s) are required to act on the status bits received from the master. When the received status bit transitions from active to standby, a slave node MUST stop forwarding over the previously active PW. When the received status bit transitions from standby to active for a given PW, the slave node MUST start forwarding user traffic over this PW 🏃♀️.
In this mode of operation, the following definitions of active and standby PW states apply:
- Active State
A PW is considered to be in active state when the PW labels are exchanged between its two endpoints, 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 🦋.
- 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 they 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 ✨
okay bestie, this section is where the signaling gets spicy 🔥 It extends PW status signaling and explains how to process those extensions. The big new addition is the PW Preferential Forwarding status bit, which rides along in the PW Status TLV from RFC 4447 [2] 💅
The PW Preferential Forwarding bit, when it's set, lets one PE tell the far-end PE whether it prefers or actually uses active or standby forwarding for the PW 🫶 What that signal means depends on whether the PW is running in master/slave or independent mode, so keep that in mind as we go 🧚
6.1. PW Standby Notification Procedures in Independent Mode 🦋
PEs with PW endpoints pick which PW they want to forward on, all on their own, depending on the application. Example applications are described in [8] 👀 Then they advertise the matching preferred active/standby forwarding state for each PW. Active Preferential Forwarding is signaled by clearing the PW Preferential Forwarding status bit in the PW Status TLV. Standby Preferential Forwarding is signaled by setting it. This advertisement happens in the initial label mapping message, and again in a later notification message whenever the forwarding state transitions because the application had a state change.
Each PW endpoint compares the updated local and remote status and effectively activates the PW. That PW is up at both endpoints and 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. This part is so important 😭
When a PW is in active state, the PEs can forward user packets, OAM packets, and other control plane packets over the PW. Main character energy ✨
When a PW is in standby state, the PEs MUST NOT forward user packets over the PW, but they MAY forward PW OAM packets and specific control plane packets. Not every packet gets benched 🙈
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 remote slave endpoint about the event. The slave endpoint then carries out the matching action when it receives the PW state change notification. Very clear communication, iconic 💖
If the slave receives a PW Preferential Forwarding bit set in the PW Status TLV, that means the PW at the master end is not used for forwarding and is staying in the standby state. The PW MUST NOT be used for forwarding at the slave endpoint. Clearing the PW Preferential Forwarding bit in the PW Status TLV means the PW at the master endpoint is used for forwarding and is in active state. The receiving slave endpoint MUST activate the PW if it was previously not used for forwarding. Yes, it's a whole vibe 🌈
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 (both defined in [2]), MAY be used to signal PWs in groups. The goal is to minimize the number of LDP status messages that MUST be sent 🧮 When PWs are provisioned with this grouping, a termination point sends a single "wildcard" notification message to denote this change in status for all affected PWs. That status message contains either the 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. Groups of PWs, all in one text 🍓
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's way easier to describe PW state changes as a state machine, so here's Table 1 🦋 The PW state machine is explained in detail for the two defined states, and the behavior is presented as a state transition table. The same state machine applies to PW groups too.
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 Mode6.3. Coordination of PW Switchover 🔁
Some PW redundancy applications need PE nodes to coordinate the switchover to a PW, so that both endpoints 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. Their paths are diverse and get switched at different S-PE nodes. Only one of these MS-PWs is active at any given time, and 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. Only one queen at a time 👑
The trigger for one endpoint to request a switchover of the MS-PW can be an operational event. For example, a failure that leaves the endpoints unable to find a common PW for which both endpoints advertise an active Preferential Forwarding status bit. The other trigger is an administrative maintenance operation run by the network operator to move traffic away from the nodes or links currently used by the active PW 🛠️
Unlike master/slave mode, the endpoint requesting the switchover needs explicit acknowledgment from the peer endpoint that the request can be honored before it switches to another PW. Also, any of the endpoints can make the request to switch over. Everyone gets a turn 💅
This document specifies a second status bit, which a PE uses to request that its peer PE switch over to use a different active PW. This bit is called the Request Switchover status bit 🎯 The Preferential Forwarding status bit keeps being used by each endpoint to indicate its current local settings for the active/standby state of each PW in the redundant set. In other words, as in independent mode, it tells the far-end which PW is being used to forward packets and which one is being put in standby. That means it can also serve 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 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. Both sides have to be on the same page 📋
S-PEs nodes MUST relay the PW status notification containing the existing status bits, as well as the new Preferential Forwarding and Request Switchover status bits, between ingress and egress PW segments, as per the procedures defined in [4] 🧚
6.3.1. Procedures at the Requesting Endpoint 🙋
a. The requesting endpoint sends a Status TLV in the LDP notification message with the Request Switchover bit set on the PW it wants 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. So the Preferential Forwarding status bit still reflects the PW that's currently in use 🦋
c. The requesting endpoint starts a timer while it waits 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. Plot twist 🎭
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 it 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 on 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.
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 it 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. Late acks are still acks, bestie 🫶✨
6.3.2. Procedures at the Receiving Endpoint ✨
okay so this is the receiving side of the switchover handshake 🫶 when a status notification comes in with the Request Switchover bit set on a PW that isn't the active one, AND that requested PW is up, the receiving endpoint MUST do two things:
a. Activate the PW, then send an update status notification with the Preferential Forwarding status bit clear and the Request Switchover bit reset on the newly active PW, and send another update status notification with the Preferential Forwarding status bit set on the previously active PW. the handoff is giving clean choreography 💅
iii. if a status notification comes in with the Request Switchover bit set on a PW that's different from the currently active one but that PW is down, the receiving endpoint MUST ignore the request. no point switching to something that's dead, bestie 💀
7. Status Mapping 🦋
okay so the PW Status TLV is basically the group chat's status update, and its generation and processing MUST follow the procedures in [2] (RFC 4447). it gets sent on the active PW AND the standby PWs so the local PE always knows what's up with the remote AC and PW states. no surprises, periodt ✨
if an S-PE node in a MS-PW is generating or processing the PW Status TLV, it MUST follow the procedures in [4] 🌸
and figuring out how to determine and map PW and AC states MUST follow the rules in [5], with the following modifications. the vibe is "same rules, a few tweaks" 💜
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. ngl this is the "something's wrong with the customer side" moment 😭
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. everybody gets told, no one gets left on read 🫠
and 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. all clear, we're good now ✨
Let me correct that last note: the original says "all PWs" in lowercase, so here it is kept as written.
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. all clear, we're good now ✨
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. this is the "the whole squad is down" situation 💀
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]. so basically, if you spotted the drama yourself and nobody warned you, you gotta speak up 📣
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. clean slate, bestie 🧹
8. Applicability and Backward Compatibility 🎀
these mechanisms are for the situations where standby state signaling of a PW or PW group is required. both PWid FEC and Generalized PWid FEC are supported, but all PWs that are part of a redundant set MUST use the same FEC type. no mixing and matching, that's a whole mess 🙈
when the set uses the PWid FEC element, each PW is uniquely identified by its PW ID. when the redundant set uses the Generalized PWid FEC element, each PW MUST have a unique identifier that consists of the triplet AGI::SAII::TAII. every PW needs its own ID card 🪪
a PE implementation that uses the mechanisms in this document MUST negotiate the use of PW Status TLV between its T-LDP peers, as per [2] (RFC 4447). if the PW Status TLV turns out to be not supported by either endpoint after status negotiation, then the mechanisms specified in this document cannot be used. no TLV, no party 😭
a PE implementation that is compliant with [2] (RFC 4447) and that does not support generating or processing the Preferential Forwarding status bit or the Request Switchover status bit MUST ignore these status bits if a peer PE sets them. this document in fact updates RFC 4447 by prescribing the same behavior for any status bit not originally defined in RFC 4447. it's like a "not my business" rule, but make it official 💅
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. status bits are not just alarms anymore, they can be orders too 👑
9. Security Considerations 🔐
okay this one is SERIOUS, so no cap, read it twice 😭🔥
LDP extensions or 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 [2] (RFC 4447). 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. one weak link and the whole chain is cooked 💀
10. MIB Considerations 🌈
new MIB objects for supporting PW redundancy are going to be defined in a separate document. stay tuned, bestie ✨
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".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 for making a contribution to the development of this document. the squad is legendary 👑
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
Daniel Cohn
Orckit
daniel.cohn.ietf@gmail.com.13. Acknowledgments 💜
the authors want to give a huge shoutout to the following people 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. they're literally the reason this doc is so good 🥹✨
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.
[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.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]. it's the "see it in action" part, and it's giving real-world proof 🎬✨
A.1. One Multi-Homed CE with Single SS-PW Redundancy ✨
Okay bestie, this first one is the classic "one CE, two homes" setup 🏠💖 Here's the picture:
|<-------------- 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 RedundancyFigure 2 uses the independent mode of operation 🦋
CE1 is dual-homed to PE1 and to PE3 by attachment circuits. How that dual-homing works, and which protocols do it, is outside the scope of this document (see [8]) 🌸
Here, the AC from CE1 to PE1 is active, and the AC from CE1 to PE3 is standby. The redundancy protocol running on the ACs decides this. So in normal operation, PE1 and PE3 advertise an active and a standby Preferential Forwarding status bit to PE2, respectively. Those bits mirror the forwarding state of the two ACs to CE1, as set by the AC dual-homing protocol 💅 PE2 advertises a Preferential Forwarding status bit of active on both PW1 and PW2, because the AC to CE2 is single-homed. Since the local and remote UP/DOWN and Preferential Forwarding status for PW1 are both up and active, traffic flows over PW1 in both directions ✨
Now say the AC between CE1 and PE1 fails. The forwarding state of the AC on PE3 flips to active, and PE3 tells PE2 about its new active Preferential Forwarding status bit. Meanwhile PE1 sends a PW status notification message saying the AC between CE1 and PE1 is down. PE2 matches the local and remote Preferential Forwarding status of active and the status of "Pseudowire forwarding", then picks PW2 as the new active PW for sending traffic 🔥
What if PE1 itself goes down? PE3 notices and flips its AC to active. How PE3 figures out that PE1 is down is outside the scope of this document, so we're not going there 🙈 PE3 then announces its 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 for traffic. Also, PE2 might have noticed that the PW to PE1 went down via T-LDP Hello timeout or some other way. Still, it can't forward user traffic until it gets the updated status bit from PE3 💀
Note that in this example, PE2 usually has enough to switch to PW2 just from getting the AC status on the CE1-PE1 link. But the operator might want to trigger the switchover for admin reasons, like maintenance 🧚 So the Preferential Forwarding status bit is required to notify PE2 to trigger the switchover. That's the whole point of the bit here 👑
Note also that the primary/secondary procedures don't apply in this case, because the PW Preferential Forwarding status is driven by the AC forwarding state, as determined by the AC dual-homing protocol used 💜
A.2. Multiple Multi-Homed CEs with SS-PW Redundancy 🌈
Okay, this one has two CEs and two dual-homed setups going on at once, so buckle up 😭 Here's the diagram:
|<-------------- 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 RedundancyFigure 3 uses the independent mode of operation 🦋
CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed to PE3 and PE4. The dual-homing method and the protocols used are outside the scope of this document. The PSN tunnels aren't shown in this figure, just to keep things clean 🫶 But you can assume each PW shown gets encapsulated in its own separate PSN tunnel 🌸
Let's say the AC from CE1 to PE1 is active, and the AC from CE1 to PE2 is standby. Also, the AC from CE2 to PE3 is standby, and the AC from CE2 to PE4 is active. How the active/standby status of each AC gets decided is outside the scope of this document 💅
PE1 advertises Preferential Forwarding status active and UP/DOWN status "Pseudowire forwarding" for PW1 and PW4, which connect to PE3 and PE4. That status reflects the forwarding state of the AC attached to PE1 ✨ PE2 advertises Preferential Forwarding status standby and UP/DOWN status "Pseudowire forwarding" for PW2 and PW3, heading to PE3 and PE4. PE3 advertises Preferential Forwarding status standby and UP/DOWN status "Pseudowire forwarding" for PW1 and PW3, going to PE1 and PE2. PE4 advertises Preferential Forwarding status active and UP/DOWN status "Pseudowire forwarding" for PW2 and PW4, going to PE2 and PE1, respectively. So the PE nodes figure out which PW should be active by matching the local and remote Preferential Forwarding status of active and UP/DOWN status "Pseudowire forwarding" across the pseudowires. In this case, PW4 is the one that gets picked 🏆
If the AC between CE1 and PE1 fails, the forwarding state of the AC on PE2 changes to active. PE2 then tells PE3 and PE4 about its newly changed Preferential Forwarding status bit of active. PE1 sends a PW status notification message saying 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 for sending traffic 🔥
What if PE1 goes down? PE2 notices the failure and flips its AC to active. How PE2 detects that PE1 is down is outside the scope of this document 🙈 PE2 then announces its 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 for traffic. Also, PE3 and PE4 might have noticed that the PW to PE1 went down via T-LDP Hello timeout or some other way. Still, they can't forward user traffic until they've received the updated status bit from PE2 💀
Here's why signalling is needed. Each dual-homing algorithm runs on its own set of nodes, namely {CE1, PE1, PE2} and {CE2, PE3, PE4}, and each one picks its active AC independently. So the active status of the AC has to be signalled, so the PE nodes can agree on a common active PW for end-to-end forwarding between CE1 and CE2, following the procedures in the independent mode 👑
Note that the primary/secondary procedures, as defined in Sections 5.1 and 5.2, don't apply in this use case. That's because the active/standby status is driven by the AC forwarding state, as determined by the AC dual-homing protocol used 💜
A.3. Multi-Homed CE with MS-PW Redundancy 🧚
Okay last one! This example is about MS-PW redundancy 🎀 Here's the picture:
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 RedundancyFigure 4 uses the independent mode of operation. It builds on 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 extend that resilient connectivity all the way to T-PE1 ✨ PW1 has two segments and is an active pseudowire, while PW2 also has two segments and is a standby pseudowire. This application needs support for MS-PW with segments of the same type as described in [4] 🫶
The operation here is the same as the SS-PW case in Section 15.1. The only difference is that the S-PE nodes have to relay the PW status notification, which carries both the UP/DOWN and forwarding status, to the T-PE nodes 💖
A.4. Multi-Homed CE with MS-PW Redundancy and S-PE Protection
okay bestie, this one is giving MS-PW redundancy with 1:1 PW protection 💅✨ here's the picture:
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
Figure 5 is doing 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 stretch that resilient connectivity all the way to T-PE1, just like in Section 15.3, with the extra bonus that this setup gives you S-PE node protection 🫶
So here's the cast: 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 they support CE2 multi-homing. PW3 and PW4 are secondary PWs and they support 1:1 PW protection. PW1, PW2, PW3, and PW4 have two segments each, and they get switched at S-PE1, S-PE2, S-PE3, and S-PE4, respectively. 🌸
It is possible that S-PE1 coincides with S-PE4 and/or SP-2 coincides with S-PE3, especially where the two PSN domains are interconnected via two nodes. The figure shows four separate S-PE nodes though, just for clarity 💜
The behavior here is exactly the same as the setup in Section 15.3, except that T-PE1 will always see a pair of PWs that are eligible for the active state. For example, that's the pair {PW1,PW3} when the AC between CE2 and T-PE2 is in active state. So it is important that both T-PE1 and T-PE2 implement a common mechanism to choose one of 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. no skipping this part, it's the whole vibe 😭🔥
A.5. Single-Homed CE with MS-PW Redundancy
this is an application of the independent mode of operation, together with the request switchover procedures, so you get N:1 PW protection 👑 a revertive behavior back to a primary PW is shown as the example of configuring and using the primary/secondary procedures from 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 is connected to PE2 in provider edge 2. There are three segmented PWs. First up, a primary PW, PW1, which is switched at S-PE1 and has the lowest precedence value of zero. Then a secondary PW, PW2, which is switched at S-PE2 and has a precedence of 1. And last, 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. literally that's the whole rule ✨
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 the Preferential Forwarding status bit as active on PW1, and as standby on PW2 and PW3, using a priority derived from the local precedence configuration. Assuming all PWs are up, T-PE1 and T-PE2 will use PW1 to forward user packets 🌈
Now the fun part, when PW1 fails. The T-PE that detects 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. On top of that, 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, since 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 the UP/DOWN status of "Pseudowire forwarding", and they 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. That can happen because of a mismatch in the configuration of the PW precedence in each T-PE. It can also happen because of a failure that stopped the endpoints from matching the active Preferential Forwarding status bit and the 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 that are about to be serviced. 🫶
In case the Request Switchover is sent by both endpoints simultaneously, both T-PEs send a status notification with the newly selected PW with the Request Switchover bit set, and then they wait for a response from the other endpoint. In that situation, the T-PE with the greater system address request is given precedence. This helps in synchronizing PWs in the event of a 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. the primary is back, bestie 🎀
A.6. PW Redundancy between H-VPLS MTU-s and PE-rs
this figure shows PW redundancy in H-VPLS, used to dual-home 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-rsA.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 the H-VPLS core on the other side of the network. MTU-s communicates the forwarding status of its member PWs to PE1-rs and PE2-rs, for a set of Virtual Switch Instances (VSIs) that have a common status of active/standby. It may be signaled using PW grouping with a common group-id in the PWid FEC element, or a Grouping TLV in the Generalized PWid FEC element, as defined in [2], so it scales 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 a PW Status TLV with the 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 it 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📦 where this page comes from
- ietf: rfc6870 2013-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms