From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6870.txt | 1963 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1963 insertions(+) create mode 100644 doc/rfc/rfc6870.txt (limited to 'doc/rfc/rfc6870.txt') 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] + -- cgit v1.2.3