RFC 6073
Segmented Pseudowire
Segmented Pseudowire 🎀 (part 1 of 10)
okay bestie, this is RFC 6073, and it's giving standards track 💅 It's the IETF's official spec, so every single word matters.
Here's the title block: the number is RFC 6073, the category is Standards Track, the ISSN is 2070-1721, and the date is January 2011. The authors are L. Martini, C. Metz (Cisco Systems, Inc.), T. Nadeau (LucidVision), and M. Bocci and M. Aissaoui (Alcatel-Lucent). Nothing in the title block says it obsoletes or updates anything 🫶
Abstract ✨
okay so the big idea is that you can hook up pseudowires (PWs) across different Packet Switched Network (PSN) domains, or between two or more separate PW control plane domains. A control plane domain uses one common control plane protocol, or one instance of that protocol, for a given PW 🦋
Why would you even do this? 🤔 Lowkey because those domains might belong to independent autonomous systems, the PSN technology might be heterogeneous, or a PW might need to get aggregated at one specific PSN point. The real tea is that the PW packet data units just get switched from one PW to another, and the PW payload stays exactly the same 🧚
Status of This Memo ✨
this one is giving official 💅 It's an Internet Standards Track document 🌸
It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 📚
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6073 🔗
Copyright Notice 🌈
The copyright is Copyright (c) 2011 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, which you can find at http://trustee.ietf.org/license-info. Those rules are the ones in effect on the date of publication, so please read them carefully, because they spell out your rights and restrictions for this doc 🙈 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as the Simplified BSD License describes 🔥
The doc may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who hold the copyright on some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭 So unless you get a proper license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🍓
Table of Contents 🧚
1. Introduction ....................................................4
2. Specification of Requirements ...................................5
3. Terminology .....................................................5
4. General Description .............................................6
5. PW Switching and Attachment Circuit Type ........................9
6. Applicability ...................................................9
7. MPLS-PW to MPLS-PW Switching ...................................10
7.1. Static Control Plane Switching ............................10
7.2. Two LDP Control Planes Using the Same FEC Type ............11
7.2.1. FEC 129 Active/Passive T-PE Election Procedure .....11
7.3. LDP Using FEC 128 to LDP Using the Generalized FEC 129 ....12
7.4. LDP SP-PE TLV .............................................12
7.4.1. PW Switching Point PE Sub-TLVs .....................14
7.4.2. Adaptation of Interface Parameters .................15
7.5. Group ID ..................................................16
7.6. PW Loop Detection .........................................16
8. MPLS-PW to L2TPv3-PW Control Plane Switching ...................16
8.1. Static MPLS and L2TPv3 PWs ................................17
8.2. Static MPLS PW and Dynamic L2TPv3 PW ......................17
8.3. Static L2TPv3 PW and Dynamic LDP/MPLS PW ..................17
8.4. Dynamic LDP/MPLS and L2TPv3 PWs ...........................17
8.4.1. Session Establishment ..............................18
8.4.2. Adaptation of PW Status message ....................18
8.4.3. Session Tear Down ..................................18
8.5. Adaptation of L2TPv3 AVPs to Interface Parameters .........19
8.6. Switching Point TLV in L2TPv3 .............................20
8.7. L2TPv3 and MPLS PW Data Plane .............................20
8.7.1. Mapping the MPLS Control Word to L2TP ..............21
9. Operations, Administration, and Maintenance (OAM) ..............22
9.1. Extensions to VCCV to Support MS-PWs ......................22
9.2. OAM from MPLS PW to L2TPv3 PW .............................22
9.3. OAM Data Plane Indication from MPLS PW to MPLS PW .........22
9.4. Signaling OAM Capabilities for Switched Pseudowires .......23
9.5. OAM Capability for MS-PWs Demultiplexed Using MPLS ........23
9.5.1. MS-PW and VCCV CC Type 1 ...........................24
9.5.2. MS-PW and VCCV CC Type 2 ...........................24
9.5.3. MS-PW and VCCV CC Type 3 ...........................24
9.6. MS-PW VCCV Operations .....................................24
9.6.1. VCCV Echo Message Processing .......................25
9.6.2. Detailed VCCV Procedures ...........................27
10. Mapping Switched Pseudowire Status ............................31
10.1. PW Status Messages Initiated by the S-PE .................32
10.1.1. Local PW2 Transmit Direction Fault ................33
10.1.2. Local PW1 Transmit Direction Fault ................34
10.1.3. Local PW2 Receive Direction Fault .................34
10.1.4. Local PW1 Receive Direction Fault .................34
10.1.5. Clearing Faults ...................................34
10.2. PW Status Messages and SP-PE TLV Processing ..............35
10.3. T-PE Processing of PW Status Messages ....................35
10.4. Pseudowire Status Negotiation Procedures .................35
10.5. Status Dampening .........................................35
11. Peering between Autonomous Systems ............................35
12. Congestion Considerations .....................................36
13. Security Considerations .......................................36
13.1. Data Plane Security ......................................36
13.1.1. VCCV Security Considerations ......................36
13.2. Control Protocol Security ................................37
14. IANA Considerations ...........................................38
14.1. L2TPv3 AVP ...............................................38
14.2. LDP TLV TYPE .............................................38
14.3. LDP Status Codes .........................................38
14.4. L2TPv3 Result Codes ......................................38
14.5. New IANA Registries ......................................39
15. Normative References ..........................................39
16. Informative References ........................................40
17. Acknowledgments ...............................................42
18. Contributors ..................................................421. Introduction ✨
Okay bestie, so the PWE3 Architecture [RFC3985] is where the signaling and encapsulation techniques for setting up Single-Segment Pseudowires (SS-PWs) between a pair of terminating PEs live 💅. Multi-Segment Pseudowires (MS-PWs) are most useful in two general cases:
- i. In some cases it's not possible, desirable, or feasible to establish a PW control channel between the terminating source and destination PEs 🙈. At a minimum, PW control channel establishment needs knowledge of, and reachability to, the remote (terminating) PE IP address. The local (terminating) PE might not have access to that info because of topology, operational, or security constraints.
- Example: the inter-AS L2VPN scenario, where the terminating PEs live in different provider networks (ASes) and it's the practice to cryptographically sign all control traffic exchanged between two networks. An SS-PW could technically work, but that would need cryptographic signatures on ALL terminating source and destination PE nodes. An MS-PW lets the providers confine key administration to just the PW switching points connecting the two domains.
- Second example, in a single AS where the PW setup path between the terminating PEs is computed by an external entity. Say there's a full mesh of PWE3 control channels between PE-A, PE-B, and PE-C. A client-layer L2 connection tunneled through a PW is needed between terminating PE-A and PE-C. The external entity computes a PW setup path that goes through PE-B. This results in two discrete PW segments being built: one between PE-A and PE-B, and one between PE-B and PE-C. For the client-layer L2 connection between terminating PE-A and terminating PE-C to succeed, PE-B has to perform the PWE3 switching process.
- Third example, with PWs in hierarchical IP/MPLS networks. Access networks connected to a backbone use PWs to carry customer payloads between customer sites served by the same access network, and up to the edge of the backbone, where they can be terminated or switched onto a succeeding PW segment crossing the backbone. Using PWE3 switching between the access and backbone networks can potentially reduce the PWE3 control channels and routing information processed by the access network T-PEs.
- It should be noted that PWE3 switching does not help in any way to reduce the amount of PW state supported by each access network T-PE. 🫶
- ii. In some applications, the signaling protocol and encapsulation on each segment of the PW are different 🌈. The terminating PEs are connected to networks using different PW signaling and encapsulation protocols. In that case, it's not possible to use an SS-PW. An MS-PW, with the appropriate signaling protocol interworking performed at the PW switching points, can enable PW connectivity between the terminating PEs in this scenario.
If you want the detailed requirements story for MS-PWs, it's all in [RFC5254] 📚.
There are four different mechanisms to establish PWs:
- Static configuration of the PW (MPLS or Layer 2 Tunneling Protocol version 3 (L2TPv3))
- LDP using FEC 128 (PWid FEC Element)
- LDP using FEC 129 (Generalized PWid FEC Element)
- L2TPv3
Here's the lowkey important bit: while MS-PWs are made up of PW segments, each segment can't function on its own, because the PW service is always instantiated across the complete MS-PW 🧚. So no PW segments can be signaled or be operational until the complete MS-PW is signaled all at once. Main character energy, but make it a whole chain 🔗.
2. Specification of Requirements 💜
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 [RFC2119]. Those are the official BCP 14 words, and they carry real weight here, so read them as the spec means them 🎀.
3. Terminology 📖
- PW Terminating Provider Edge (T-PE). A PE where the customer-facing attachment circuits (ACs) are bound to a PW forwarder. A Terminating PE is present in the first and last segments of a MS-PW. This incorporates the functionality of a PE as defined in [RFC3985].
- Single-Segment Pseudowire (SS-PW). A PW set up directly between two T-PE devices. The PW label is unchanged between the originating and terminating T-PEs.
- 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 MUST terminate on a T-PE. 🔥
- PW Segment. A part of a single-segment or multi-segment PW, which traverses one PSN tunnel in each direction between two PE devices, T-PEs and/or S-PEs (switching PE).
- 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. It therefore includes a PW switching point for an MS-PW. A PW switching point is never the S-PE and the T-PE for the same MS-PW. A PW switching point runs necessary protocols to set up and manage PW segments with other PW switching points and terminating PEs. An S-PE can exist anywhere a PW must be processed or policy applied. It is therefore not limited to the edge of a provider network. 👑
- MS-PW path. The set of S-PEs that will be traversed in sequence to form the MS-PW. 🦋
4. General Description ✨
okay so a pseudowire (PW) is basically a mechanism that carries the essential bits of an emulated service from one PE to one or more other PEs, going over a PSN 🦋 (see Figure 1 and [RFC3985]). Lots of providers have already deployed PWs to move their existing L2VPN services (think Frame Relay, ATM, or Ethernet) onto a PSN, or to build brand-new ones. iconic behaviour 💅
PWs can span multiple domains, whether those belong to the same provider or different ones. In those setups, PW control channels (that's targeted LDP and L2TPv3) and the PWs themselves will cross AS boundaries 🌸
Inter-AS L2VPN functionality is already supported, and several techniques that use MPLS encapsulation and LDP signaling have been documented [RFC4364]. It's also pretty straightforward to get the same inter-AS L2VPN functionality using L2TPv3 🎀. In this document, we define a methodology for switching a PW between different Packet Switched Network (PSN) domains, or between two or more distinct PW control plane domains. main character energy ✨
|<-------------- Emulated Service ---------------->|
| |
| |<-------- Pseudowire ------>| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
native service native serviceFigure 1: PWE3 Reference Model
okay so there are two methods for switching a PW between two PW domains 🧚. In the first method (Figure 2), the two separate control plane domains terminate on different PEs.
|<-------Multi-Segment Pseudowire------->|
| PSN PSN |
AC | |<-1->| |<-2->| | AC
| V V V V V V |
| +----+ +-----+ +----+ +----+ |
+----+ | | |=====| | | |=====| | | +----+
| |-------|......PW1.......|--AC1--|......PW2......|-------| |
| CE1| | | | | | | | | | | |CE2 |
| |-------|......PW3.......|--AC2--|......PW4......|-------| |
+----+ | | |=====| | | |=====| | | +----+
^ +----+ +-----+ +----+ +----+ ^
| PE1 PE2 PE3 PE4 |
| ^ ^ |
| | | |
| PW switching points |
| |
| |
|<-------------------- Emulated Service ---------------->|Figure 2: PW Switching Using AC Reference Model
In Figure 2, pseudowires that live in two separate PSNs get stitched together using native service attachment circuits 💜. PE2 and PE3 only run the control plane for the PSN they're directly attached to. At PE2 and PE3, PW1 and PW2 are connected using attachment circuit AC1, while PW3 and PW4 are connected using attachment circuit AC2.
Native |<-----Multi-Segment Pseudowire------>| Native
Service | PSN PSN | Service
(AC) | |<-Tunnel->| |<-Tunnel->| | (AC)
| V V 1 V V 2 V V |
| +----+ +-----+ +----+ |
+----+ | |TPE1|==========|SPE1 |==========|TPE2| | +----+
| |------|.....PW.Seg't1....X....PW.Seg't3.....|-------| |
| CE1| | | | | | | | | |CE2 |
| |------|.....PW.Seg't2....X....PW.Seg't4.....|-------| |
+----+ | | |==========| |==========| | | +----+
^ +----+ +-----+ +----+ ^
| Provider Edge 1 ^ Provider Edge 2 |
| | |
| | |
| PW switching point |
| |
|<----------------- Emulated Service --------------->|Figure 3: MS-PW Reference Model
In Figure 3, SPE1 runs two separate control planes: one toward TPE1 and one toward TPE2 🔥. The PW switching point (S-PE) is configured to connect PW Segment 1 and PW Segment 3 together, which completes the multi-segment PW between TPE1 and TPE2. PW Segment 1 and PW Segment 3 MUST be of the same PW type, but PSN Tunnel 1 and PSN Tunnel 2 need not be the same technology. In that latter case, if the PW gets switched to a different technology, the PEs must adapt the PDU encapsulation between the different PSN technologies. When PSN Tunnel 1 and PSN Tunnel 2 are the same technology, the PW PDU doesn't need to be modified, and PDUs are switched between the pseudowires at the PW label level 🫶.
It should be noted that it's possible to adapt one PSN technology to a different one, for example MPLS over an IP encapsulation or Generic Routing Encapsulation (GRE) [RFC4023]. That's outside the scope of this document, though 🙈. Further, one could perform an interworking function on the PWs themselves at the S-PE, allowing conversion from one PW type to another. That's also outside the scope of this document.
This document describes procedures for building multi-segment pseudowires using manual configuration of the switching point PE1 🍓.
Other documents may build on this base specification to automate the configuration and selection of S-PE1. All elements of establishing end-to-end MS-PWs, including routing and signaling, are out of scope of this document, and any discussion in this document serves purely as examples. It should also be noted that a PW can traverse multiple PW switching points along its path (it's written as "it's" in the original, so keep an eye on that), and the edge PEs will not require any specific knowledge of how many S-PEs the PW has traversed, though this may be reported for troubleshooting purposes 🔍.
The general approach taken for MS-PWs is to connect the individual control planes by passing along any signaling information immediately upon reception. First, the S-PE is configured to switch a PW segment from a specific peer to another PW segment destined for a different peer. No control messages are exchanged yet, because the S-PE doesn't have enough information to actually initiate the PW setup messages. However, if a session doesn't already exist, a control protocol (LDP/L2TP) session MAY be setup. In this model, MS-PW setup starts from the T-PE devices. Once the T-PE is configured, it sends the PW control setup messages. These messages are received by the S-PE and immediately used to form the PW setup messages for the next SS-PW of the MS-PW 🌈.
5. PW Switching and Attachment Circuit Type 🦄
The PWs in each PSN are established independently, with each PSN being treated as a separate PW domain. For example, in Figure 2 for the case of MPLS PSNs, PW1 is set up between PE1 and PE2 using the LDP targeted session described in [RFC4447], and at the same time a separate pseudowire, PW2, is set up between PE3 and PE4. The ACs for PW1 and PW2 at PE2 and PE3 MUST be configured so that they are the same PW type, e.g., ATM Virtual Channel Connection (VCC), Ethernet VLAN, etc. 💖
6. Applicability ✨
The general applicability of MS-PWs and their relationship to L2VPNs is described in [RFC5659]. The applicability of a PW type, as specified in the relevant RFC for that encapsulation (for example [RFC4717] for ATM), applies to each segment. This section describes further applicability considerations 🎀.
As with SS-PWs, the performance of any segment will be limited by the performance of the underlying PSN. The performance may be further degraded by the emulation process, and that degradation may increase further when traversing multiple PW segments. Furthermore, the overall performance of an MS-PW is no better than the worst-performing segment of that MS-PW 😭.
Since different PSN types may be able to achieve different maximum performance objectives, it is necessary to carefully consider which PSN types are used along the path of an MS-PW 👑.
7. MPLS-PW to MPLS-PW Switching 🌸
Referencing Figure 3, T-PE1 set up PW Segment 1 using the LDP targeted session described in [RFC4447]. At the same time, a separate pseudowire, PW Segment 3, is set up to T-PE2. Each PW is configured independently on the PEs, but on S-PE1, PW Segment 1 is connected to PW Segment 3. PDUs are then switched between the pseudowires at the PW label level. Hence, the data plane doesn't need any special knowledge of the specific pseudowire type. A simple standard MPLS label swap operation is sufficient to connect the two PWs, and in this case the PW adaptation function cannot be used. However, when pushing a new PSN label, the Time to Live (TTL) SHOULD be set to 255, or some other locally configured fixed value ⭐.
This process can be repeated as many times as necessary. The only limitation on the number of S-PEs traversed is imposed by the TTL field of the PW MPLS label. The setting of the TTL of the PW MPLS label is a matter of local policy on the originating PE, but it SHOULD be set to 255. However, if the PW PDU contains an Operations, Administration, and Maintenance (OAM) packet, then the TTL can be set to the required value, as explained later in this document 🧚♀️.
There are three different mechanisms for MPLS-to-MPLS PW setup:
-i. Static configuration of the PW
-ii. LDP using FEC 128
-iii. LDP using the generalized FEC 129This results in four distinct PW switching situations that are significantly different and must be considered in detail 💅:
-i. Switching between two static control planes
-ii. Switching between a static and a dynamic LDP control plane
-iii. Switching between two LDP control planes using the same FEC
type
-iv. Switching between LDP using FEC 128 and LDP using the
generalized FEC 1297.1. Static Control Plane Switching
Okay bestie, let's talk about the simplest case first 🦋. If there are two static control planes, the S-PE MUST be configured to direct the MPLS packets from one PW into the other. There's no control protocol involved at all, so it's very chill 🧚
Now the mixed case: when one side is a simple static PW configuration and the other side is a dynamic LDP FEC 128 or generalized PW FEC, the static control plane should be considered similar to an attachment circuit (AC) in the reference model of Figure 1. The switching point PE SHOULD signal the appropriate PW status if it detects a failure in sending or receiving packets over the static PW segment. 🚨
Here's the catch 💀: if there's no PW status communication mechanism when the PW is statically configured, the status passed along to the dynamic LDP PW is limited to local interface failures. In this case the S-PE PE acts a lot like a T-PE, taking on an active signaling role. That means the S-PE will immediately send the LDP Label Mapping message if the static PW is deemed to be UP. ✨
7.2. Two LDP Control Planes Using the Same FEC Type
The S-PE SHOULD assume an initial passive role 🌸. Here's the vibe: when independent PWs are configured on the switching point, the Label Switching Router (LSR) does NOT advertise the LDP PW FEC mapping until it has received at least one of the two PW LDP FECs from a remote PE. Why? Because the switching point LSR doesn't know a priori what the interface parameter field in the initial FEC advertisement will contain 🙈
If one of the S-PEs doesn't accept an LDP Label Mapping message, then a Label Release message may be sent back to the originator T-PE, depending on the cause of the error. Also, LDP liberal label retention mode still applies, so if a PE is simply not configured yet, the label mapping is stored for future use. Lowkey so considerate 🫶 An MS-PW is declared UP only when all the constituent SS-PWs are UP.
The Pseudowire Identifier (PWid), as defined in [RFC4447], is a unique number between each pair of PEs. Hence, each SS-PW that forms an MS-PW may have a different PWid. For the generalized PW FEC, the Attachment Group Identifier (AGI) / Source Attachment Identifier (SAI) / Target Attachment Identifier (TAI) may also have to be different for some, or sometimes all, SS-PWs. Main character energy for every single SS-PW 👑
7.2.1. FEC 129 Active/Passive T-PE Election Procedure
Okay so when an MS-PW is signaled using FEC 129, each T-PE might independently start signaling the MS-PW 😭. If the MS-PW path is not statically configured, the signaling could end up trying to set up each direction of the MS-PW through different S-PEs. Nobody wants that chaos 💅 So if an operator wants to avoid this situation, one of the T-PEs MUST start the PW signaling (active role), while the other waits to receive the LDP label mapping before sending the respective PW LDP Label Mapping message (passive role). When the MS-PW path is not statically configured, the active T-PE (the Source T-PE) and the passive T-PE (the Target T-PE) MUST be identified before signaling is initiated for a given MS-PW.
The determination of which T-PE takes the active role SHOULD be done as follows 🎀:
The SAII and TAII are compared as unsigned integers. If the SAII is larger, then the T-PE assumes the active role. Simple, iconic 🔥
The selection process that decides which T-PE assumes the active role MAY be superseded by manual provisioning. In that case, one of the T-PEs MUST be set to the active role, and the other one MUST be set to the passive role. Operator has the final say, periodt 💜
7.3. LDP Using FEC 128 to LDP Using the Generalized FEC 129
When a PE is using the generalized FEC 129, there are two distinct roles it can assume: active and passive 🧚. A PE that assumes the active role will send the LDP PW setup message, while a passive role PE will simply reply to an incoming LDP PW setup message. The S-PE will always remain passive until a PWid FEC 128 LDP message is received, which will cause the corresponding generalized PW FEC LDP message to be formed and sent. And if a generalized FEC PW LDP message is received while the switching point PE is in a passive role, the corresponding PW FEC 128 LDP message will be formed and sent. It's giving back-and-forth translation 🌈
PWids need to be mapped to the corresponding AGI/TAI/SAI and vice versa. This can be done by local S-PE configuration, or by some other means, such as some form of auto discovery. Those other means are outside the scope of this document, so we're not going there today 🍓
7.4. LDP SP-PE TLV
The edge-to-edge PW might traverse several switching points, each in separate administrative domains 🌍. For management and troubleshooting reasons, it's useful to record information about the switching points at the S-PEs that the PW traverses. This is done using a PW Switching Point PE TLV (SP-PE TLV) ✨.
Sending the SP-PE TLV is OPTIONAL; however, the PE or S-PE MUST process the TLV upon reception. The "U" bit MUST be set for backward compatibility with T-PEs that do not support the MS-PW extensions described in the document 🦋. The SP-PE TLV MAY appear only once for each switching point traversed, and it cannot be of length zero. The SP-PE TLV is appended to the PW FEC at each S-PE, and the order of the SP-PE TLVs in the LDP message MUST be preserved. The SP-PE TLV is necessary to support some of the Virtual Circuit Connectivity Verification (VCCV) functions for MS-PWs. See Section 9.5 for more details. The SP-PE TLV is encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| SP-PE TLV (0x096D) | SP-PE TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " " " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field means 📖:
- SP-PE TLV Length
Specifies the total length of all the following SP-PE TLV fields in octets.
- Sub-TLV Type
Encodes how the Value field is to be interpreted.
- Length
Specifies the length of the Value field in octets.
- Value
Octet string of Length octets that encodes information to be interpreted as specified by the Type field.
PW Switching Point PE sub-TLV Types are assigned by IANA according to the process defined in Section 14 (IANA Considerations) below 🎀.
For local policy reasons, a particular S-PE can filter out all SP-PE TLVs in a Label Mapping message that traverses it, and not include its own SP-PE TLV. In this case, from any upstream PE, it will appear as if this particular S-PE is the T-PE. This might be necessary, depending on local policy, if the S-PE is at the service provider administrative boundary. It should also be noted that because there are no SP-PE TLVs describing the path beyond the S-PE that removed them, VCCV will only work as far as that S-PE. Ngl that's a plot twist 💀
7.4.1. PW Switching Point PE Sub-TLVs
The SP-PE TLV contains sub-TLVs that describe various characteristics of the S-PE traversed. The SP-PE TLV MUST contain the appropriate mandatory sub-TLVs specified below. The definitions of the PW Switching Point PE sub-TLVs are as follows 🌸:
- PWid of last PW segment traversed.
This is only applicable if the last PW segment traversed used LDP FEC 128 to signal the PW. This sub-TLV type contains a PWid in the format of the PWid described in [RFC4447]. It's just a 32-bit unsigned integer number.
- PW Switching Point description string.
An OPTIONAL description string of text up to 80 characters long. Human-readable text MUST be provided in the UTF-8 character set using the Default Language [RFC2277].
- Local IP address of PW Switching Point.
The local IPv4 or IPv6 address of the PW Switching Point. This is an OPTIONAL Sub-TLV. In most cases, this will be the local LDP session IP address of the S-PE.
- Remote IP address of the last PW Switching Point traversed or of the T-PE.
The IPv4 or IPv6 address of the last PW Switching Point traversed or of the T-PE. This is an OPTIONAL Sub-TLV. In most cases, this will be the remote IP address of the LDP session. This Sub-TLV SHOULD only be included if there are no other SP-PE TLVs present from other S-PEs, or if the remote IP address of the LDP session does not correspond to the "Local IP address of PW Switching Point" TLV value contained in the last SP-PE TLV. 🧐
- The FEC element of last PW segment traversed.
This is only applicable if the last PW segment traversed used LDP FEC 129 to signal the PW.
The FEC element of the last PW segment traversed is encoded in the following format 🧩:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- L2 PW address of the PW Switching Point (recommended format).
This sub-TLV type contains an L2 PW address of PW Switching Point in the format described in Section 3.2 of [RFC5003]. This includes the AII type field and length, as well as the L2 PW address with the AC ID field set to zero. 🎉
7.4.2. Adaptation of Interface Parameters 💅
okay bestie, so [RFC4447] defines a bunch of interface parameters, and the Network Service Processing (NSP) uses them to adapt the PW to the attachment circuit (AC) 🎀. They're only used at the endpoints, and they MUST be passed unchanged across the S-PE. BUT (plot twist 👀) the following interface parameters MAY be modified as follows:
0x03Optional Interface Description string This Interface parameter MAY be modified or altogether removed from the FEC element depending on local configuration policies.0x09Fragmentation indicator This parameter MAY be inserted in the FEC by the switching point if it is capable of re-assembly of fragmented PW frames according to [RFC4623].0x0CVCCV parameter This Parameter contains the Control Channel (CC) type and Connectivity Verification (CV) type bit fields. The CV type bit field MUST be reset to reflect the CV type supported by the S-PE. The CC type bit field MUST have bit 1 "Type 2: MPLS Router Alert Label" set to 0. The other bit fields MUST be reset to reflect the CC type supported by the S-PE. 🧚
7.5. Group ID ✨
The Group ID (GR ID) is used to reduce the number of status messages that need to be sent by the PE advertising the PW FEC. ngl this is such a clean trick 🫶 The GR ID has local significance only, and therefore MUST be mapped to a unique GR ID allocated by the S-PE.
7.6. PW Loop Detection 🔁
A switching point PE SHOULD inspect the PW Switching Point PE TLV, to verify that its own IP address does not appear in it. If the PE's IP address appears in a received PW Switching Point PE TLV, the PE SHOULD break the loop and send a label release message with the following error code:
Value E Description
0x0000003A 0 PW Loop DetectedIf an S-PE along the MS-PW removed all SP-PE TLVs, as mentioned above, this loop detection method will fail. 💀 that's the one gap, so be careful out there 😭
8. MPLS-PW to L2TPv3-PW Control Plane Switching 🦋
Both MPLS and L2TPv3 PWs may be static or dynamic. That gives us four possibilities when switching between L2TPv3 and MPLS, and honestly it's giving main character energy 👑
- i. Switching between static MPLS and L2TPv3 PWs
- ii. Switching between a static MPLS PW and a dynamic L2TPv3 PW
- iii. Switching between a static L2TPv3 PW and a dynamic LDP/MPLS PW
- iv. Switching between a dynamic LDP/MPLS PW and a dynamic L2TPv3 PW
8.1. Static MPLS and L2TPv3 PWs 🍓
In the case of two static control planes, the S-PE MUST be configured to direct packets from one PW into the other. There is no control protocol involved in this case, so no drama 🙈 The configuration MUST include which MPLS PW Label maps to which L2TPv3 Session ID (and associated Cookie, if present) as well as which MPLS Tunnel Label maps to which PE destination IP address.
8.2. Static MPLS PW and Dynamic L2TPv3 PW 🌸
When a statically configured MPLS PW is switched to a dynamic L2TPv3 PW, the static control plane should be considered identical to an attachment circuit (AC) in the reference model of Figure 1. The switching point PE SHOULD signal the appropriate PW status if it detects a failure in sending or receiving packets over the static PW. Because the PW is statically configured, the status communicated to the dynamic L2TPv3 PW will be limited to local interface failures. In this case, the S-PE behaves in a very similar manner to a T-PE, assuming an active role. It's a T-PE lookalike, iconic ✨
8.3. Static L2TPv3 PW and Dynamic LDP/MPLS PW 🌈
When a statically configured L2TPv3 PW is switched to a dynamic LDP/MPLS PW, then the static control plane should be considered identical to an attachment circuit (AC) in the reference model of Figure 1. The switching point PE SHOULD signal the appropriate PW status (via an L2TPv3 Set-Link-Info (SLI) message) if it detects a failure in sending or receiving packets over the static PW. Because the PW is statically configured, the status communicated to the dynamic LDP/MPLS PW will be limited to local interface failures. In this case, the S-PE behaves in a very similar manner to a T-PE, assuming an active role. Same energy as 8.2, just a different flavour 🍭
8.4. Dynamic LDP/MPLS and L2TPv3 PWs 💜
When switching between dynamic PWs, the switching point always assumes an initial passive role. Thus, it does not initiate an LDP/MPLS or L2TPv3 PW until it has received a connection request (Label Mapping or Incoming-Call-Request (ICRQ)) from one side of the node. Note that while MPLS PWs are made up of two unidirectional Label Switched Paths (LSPs) bonded together by FEC identifiers, L2TPv3 PWs are bidirectional in nature, setup via a three-message exchange (ICRQ, Incoming-Call-Reply (ICRP), and Incoming-Call-Connected (ICCN)). Details of Session Establishment, Tear Down, and PW Status signaling are detailed below.
8.4.1. Session Establishment 🤝
When the S-PE receives an L2TPv3 ICRQ message, the identifying AVPs included in the message are mapped to FEC identifiers and sent in an LDP Label Mapping message. Conversely, if an LDP Label Mapping message is received, it is either mapped to an ICRP message or causes an L2TPv3 session to be initiated by sending an ICRQ.
Following are two example exchanges of messages between LDP and L2TPv3. The first is a case where an L2TPv3 T-PE initiates an MS-PW; the second is a case where an MPLS T-PE initiates an MS-PW.
PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP)
AC "Up"
L2TPv3 ICRQ --->
LDP Label Mapping --->
AC "Up"
<--- LDP Label Mapping
<--- L2TPv3 ICRP
L2TPv3 ICCN --->
<-------------------- MS-PW Established ------------------>
PE 1 (MPLS/LDP) PW Switching Node PE3 (L2TPv3)
AC "Up"
LDP Label Mapping --->
L2TPv3 ICRQ --->
<--- L2TPv3 ICRP
<--- LDP Label Mapping
L2TPv3 ICCN --->
AC "Up"
<-------------------- MS-PW Established ------------------>8.4.2. Adaptation of PW Status Message 🚦
L2TPv3 uses the SLI message to indicate an interface status change (such as the interface transitioning from "Up" or "Down"). MPLS/LDP PWs either signal this via an LDP Label Withdraw or the PW Status Notification message defined in Section 4.4 of [RFC4447]. The LDP status TLV bit SHOULD be mapped to the L2TPv3 equivalent Extended Circuit Status Values TLV specified in [RFC5641].
8.4.3. Session Tear Down 🫧
L2TPv3 uses a single message, Call-Disconnect-Notify (CDN), to tear down a pseudowire. The CDN message translates to a Label Withdraw message in LDP. Following are two example exchanges of messages between LDP and L2TPv3. The first is a case where an L2TPv3 T-PE initiates the termination of an MS-PW; the second is a case where an MPLS T-PE initiates the termination of an MS-PW.
PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP)
AC "Down"
L2TPv3 CDN --->
LDP Label Withdraw --->
AC "Down"
<-- LDP Label Release
<--------------- MS-PW Data Path Down ------------------>
PE 1 (MPLS LDP) PW Switching Node PE3 (L2TPv3)
AC "Down"
LDP Label Withdraw --->
L2TPv3 CDN -->
<-- LDP Label Release
AC "Down"
<---------------- MS-PW Data Path Down ------------------>8.5. Adaptation of L2TPv3 AVPs to Interface Parameters 🎯
[RFC4447] defines several interface parameters that MUST be mapped to the equivalent AVPs in L2TPv3 setup messages. Here's the mapping list, bestie:
- Interface MTU The Interface MTU parameter is mapped directly to the L2TP "Interface Maximum Transmission Unit" AVP defined in [RFC4667].
- Max Number of Concatenated ATM cells This interface parameter is mapped directly to the L2TP "ATM Maximum Concatenated Cells AVP" described in Section 6 of [RFC4454].
- PW Type The PW Type defined in [RFC4446] is mapped to the L2TPv3 "Pseudowire Type" AVP defined in [RFC3931].
- PWid (FEC 128) For FEC 128, the PWid is mapped directly to the L2TPv3 "Remote End ID" AVP defined in [RFC3931].
- Generalized FEC 129 SAI/TAI Section 4.3 of [RFC4667] defines how to encode the SAI and TAI parameters. These can be mapped directly.
Other interface parameter mappings are unsupported when switching between LDP/MPLS and L2TPv3 PWs. 🙅♀️ so don't even try it
8.6. PW Switching Point PE TLV in L2TPv3 🧩
When translating between LDP and L2TPv3 control messages, the PW Switching Point PE TLV described earlier in this document is carried in a single variable-length L2TP AVP present in the ICRQ and ICRP messages, and optionally in the ICCN message.
The L2TP "PW Switching Point AVP" is Attribute Type 101. The AVP MAY be hidden (the L2TP AVP H-bit may be 0 or 1), the length of the AVP is 6 plus the length of the series of Switching Point PE sub-TLVs included in the AVP, and the AVP MUST NOT be marked Mandatory (the L2TP AVP M-bit MUST be 0). Lowkey a lot of rules in one sentence, but we got this 💅
8.7. L2TPv3 and MPLS PW Data Plane 🌊
When switching between an MPLS and L2TP PW, packets are sent in their entirety from one PW to the other, replacing the MPLS label stack with the L2TPv3 and IP header or vice versa.
Section 5.4 of [RFC3985] discusses the purpose of the various shim headers necessary for enabling a pseudowire over an IP or MPLS PSN. For L2TPv3, the Payload Convergence and Sequencing function is carried out via the Default L2-Specific Sublayer defined in [RFC3931]. For MPLS, these two functions (together with PSN Convergence) are carried out via the MPLS Control Word. Since these functions are different between MPLS and L2TPv3, interworking between the two may be necessary.
The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers, which in some cases are not necessary to be present at all. For example, an Ethernet PW with sequencing disabled will generally not require an MPLS Control Word or L2TP Default L2-Specific Sublayer to be present at all. In this case, Ethernet frames are simply sent from one PW to the other without any modification beyond the MPLS and L2TP/IP encapsulation and decapsulation.
The following section offers guidelines for how to interwork between L2TP and MPLS for those cases where the Payload Convergence, Sequencing, or PSN Convergence functions are necessary on one or both sides of the switching node. 🦋
8.7.1. Mapping the MPLS Control Word to L2TP ✨
okay bestie, so here's how the MPLS Control Word is laid out, left to right 🎀:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Reserved | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+now let's go through the notes, they're giving detail 🧚
- i. These bits are always zero in an MPLS PW PDU 🌸 so there's no need to map them to L2TP.
- ii. These six bits may be used for Payload Convergence, and what they do depends on the PW type 💅. For ATM, the first four are defined in [RFC4717], and they map straight across to the bits in [RFC4454]. For Frame Relay, these bits tell you how to set the bits in the Frame Relay header. Those bits have to be regenerated for L2TP, because L2TP carries the Frame Relay header intact 🦋.
- iii. L2TP works out its payload length from IP, so this Length field doesn't need to be carried directly to L2TP 🙈. It will have to be calculated and inserted for MPLS when necessary.
- iv. The Default L2-Specific Sublayer has a sequence number with different semantics from the MPLS Control Word 😭. That difference means you can't just carry the sequence number through the switching point and call it a day, so sequencing across the MS-PW doesn't work that way. Instead, sequence numbers MAY be supported by checking the sequence numbers of packets as they arrive at the switching point, then regenerating a new sequence number in the right format for the PW on egress ✨. If this kind of sequence interworking isn't supported at the switching node, and a T-PE asks for sequencing of all packets via the L2TP control channel during session setup, then the switching node SHOULD NOT let the session be established. It does that by sending a CDN message with Result Code set to 31 "Sequencing not supported" 🚫.
9. Operations, Administration, and Maintenance (OAM) 🦋
9.1. Extensions to VCCV to Support MS-PWs
okay so single-segment pseudowires get signaled with the Virtual Circuit Connectivity Verification (VCCV) parameter 🔍. It lives in the interface parameter field of the PWid FEC TLV, or in the interface parameter sub-TLV of the Generalized PWid FEC TLV, as described in [RFC5085]. When there's a switching point between PE nodes, it's required to keep VCCV working end-to-end across that switching point, and to let you trace the path of the MS-PW across any number of segments 🛤️.
This document gives you a way to do both of those things 💖. It works by reusing the existing VCCV Control Word (CW) and decrementing the TTL of the PW label at each S-PE on the path of the MS-PW 🌈.
9.2. OAM from MPLS PW to L2TPv3 PW
so when an MS-PW has SS-PWs that use L2TPv3, the MPLS PW OAM MUST be terminated at the S-PE that connects the L2TPv3 and MPLS segments 🫶. Status info received on one PW segment can then be used to generate the right status messages on the next segment. For L2TPv3, the status bits in the circuit status AVP defined in Section 5.4.5 of [RFC3931], plus the Extended Circuit Status Values defined in [RFC5641], can be mapped directly to the PW status bits defined in Section 5.4.3 of [RFC4447] ✨.
VCCV messages are specific to the MPLS data plane, so they can't be used for an L2TPv3 PW segment 🙅♀️. That means the S-PE MUST NOT send the VCCV parameter in the interface parameter field of the PWid FEC TLV, or the sub-TLV interface parameter of the Generalized PWid FEC TLV. It might be possible to translate VCCV messages from L2TPv3 PW segments to MPLS PW segments and back again, but that's left for further study 🔮.
9.3. OAM Data Plane Indication from MPLS PW to MPLS PW
as we said above, the S-PE MUST perform a standard MPLS label swap operation on the MPLS PW label 🔁. By the rules in [RFC3032], the PW label TTL MUST be decreased at every S-PE. Once the PW label TTL hits 0, the packet gets sent to the control plane to be processed 🧠. So by controlling the TTL value on the PW label, you can pick exactly which S-PE responds to the VCCV packet 🎯. iconic, honestly.
9.4. Signaling OAM Capabilities for Switched Pseudowires
it's the same vibe as SS-PW here: MS-PW VCCV capabilities get signaled using the VCCV parameter in the interface parameter field of the PWid FEC TLV, or in the sub-TLV interface parameter of the Generalized PWid FEC TLV, as described in [RFC5085] 💜.
in Figure 3, T-PE1 uses that VCCV parameter to tell the far-end T-PE2 which VCCV capabilities T-PE1 supports 📣. It's the exact same parameter it would use if T-PE1 and T-PE2 were connected directly. S-PE2 is a PW switching point, so as part of the adaptation function for interface parameters, it processes the VCCV parameter locally and then passes it along to T-PE2 🔄. If there are multiple S-PEs on the path between T-PE1 and T-PE2, each one does the same processing and passes the VCCV parameter along 🧚.
the local processing removes any CC Types that the originating T-PE specified but the S-PE doesn't support 🧹. For example, say T-PE1 says it supports CC Types 1, 2, and 3. If the S-PE doesn't do Router Alert CC Type 2, it removes that one, leaves the rest of the TLV alone, and passes the modified VCCV parameter to the next S-PE on the path 💅.
the far end T-PE (T-PE2) gets a VCCV parameter that only lists the CC Types supported by the initial T-PE (T-PE1) and by all the S-PEs along the PW path 🌸.
9.5. OAM Capability for MS-PWs Demultiplexed Using MPLS
the VCCV parameter ID is defined as follows in [RFC4446] 🍓:
Parameter ID Length Description
0x0c 4 VCCVand here's the format of the VCCV parameter field 👑:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0c | 0x04 | CC Types | CV Types |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and the bits for CC Types work like this 🔥:
Bit 0 (0x01) - Type 1: PWE3 Control Word with 0001b as
first nibble as defined in [RFC4385]
Bit 1 (0x02) - Type 2: MPLS Router Alert Label
Bit 2 (0x04) - Type 3: MPLS Demultiplexor PW Label with
TTL == 1 (Type 3).9.5.1. MS-PW and VCCV CC Type 1
VCCV CC Type 1 can be used for MS-PWs 🎀. But if the CW is enabled on user packets, VCCV CC Type 1 MUST be used, following the rules in [RFC5085]. When you use CC Type 1 for MS-PWs, the PE sending the VCCV packet MUST set the TTL to the right value to reach the destination S-PE 🎯. If the packet is headed for the T-PE, though, the TTL can be set to any value that's enough for the packet to reach the T-PE 🫶.
9.5.2. MS-PW and VCCV CC Type 2
VCCV CC Type 2 is not supported for MS-PWs 🙅♀️, so the S-PE MUST remove it from a VCCV parameter field.
9.5.3. MS-PW and VCCV CC Type 3
VCCV CC Type 3 can be used for MS-PWs 💖. However, if the CW is enabled, VCCV Type 1 is preferred, following the rules in [RFC5085]. Also, when you use the VCCV Type 3 TTL method, the PE sets the PW label TTL to the value needed to reach the target PE ⏱️. If you skip that, the VCCV packet might get forwarded over the AC to the Customer Premise Equipment (CPE) 😭.
9.6. MS-PW VCCV Operations
this document specifies four VCCV operations 🌈:
- i. End-to-end MS-PW connectivity verification 🧭. This checks that the MS-PW is connected from the source T-PE to the destination T-PE. To do it, the sending T-PE has to include the FEC used on the last segment of the MS-PW to the destination T-PE in the VCCV-Ping echo request. That info is either configured at the sending T-PE, or it comes from processing the matching sub-TLVs of the optional SP-PE TLV, as described below.
- ii. Partial MS-PW connectivity verification 🧩. This checks the connectivity of any contiguous subset of the MS-PW segments, from the source T-PE or a source S-PE to a destination S-PE or T-PE. Again, the FEC used on the last segment being tested must be included in the VCCV-Ping echo request message. The sending T-PE or S-PE figures this out the same way as in (i) above.
- iii. MS-PW path verification 🕵️♀️. This checks the path of the MS-PW, as returned by the SP-PE TLV, against the actual data path. The sending T-PE or S-PE iteratively sends a VCCV echo request to each S-PE along the MS-PW path, using the FEC for the matching MS-PW segment in the SP-PE TLV. If the SP-PE TLV info is correct, you'll get back a VCCV echo reply showing that this is a valid router for the FEC 🥰. But if the SP-PE TLV info is wrong, this operation only finds the first incorrect switching point, not the real path beyond that point 🚨. This operation can't be used when the MS-PW is statically configured, or when the SP-PE TLV isn't supported. The processing of the PW Switching Point PE TLV for this operation is described below. This operation is OPTIONAL.
- iv. MS-PW path trace 🗺️. This traces the data path of the MS-PW using FECs included in the Target FEC stack TLV [RFC4379] that come back from S-PEs or T-PEs in an echo reply message. The sending T-PE or S-PE uses that info to recursively test each S-PE along the MS-PW path, all in one operation, kind of like LSP trace 🧵. This one can find the actual data path of the MS-PW, and it works for both statically configured and signaled MS-PWs. Support for this operation is OPTIONAL.
the operations above rely on the intermediate S-PEs and/or the destination T-PE to include the PW Switching Point PE TLV during MS-PW setup, or to include the Target FEC stack TLV in the VCCV echo reply message 🫧. But for various reasons, like privacy or security of the S-PE/T-PE, the source T-PE might not get that info. In those cases, manual configuration of the FEC MAY still be used 🔐.
9.6.1. VCCV Echo Message Processing 💌
Okay so the big challenge for the control plane is building a VCCV echo request with enough info to actually reach the S-PE or T-PE you're aiming for, like the target FEC 128 PW sub-TLV of the downstream PW segment the packet is headed to. 😭 It gets even messier when the MS-PW spans different providers and Autonomous Systems. Literally chaos. 🌀
Like, in Figure 3, T-PE1 has the FEC 128 for its own segment (PW segment 1), but it doesn't readily have what it needs to compose the FEC 128 for the next segment (PW segment 3) if it wants to send a VCCV echo request to T-PE2. The methods in the subsections below are how we get around that. 🦋
9.6.1.1. Sending a VCCV Echo Request
When you're doing a partial or end-to-end connectivity or path verification, the sender of the echo request needs the FEC of the last segment to the target S-PE/T-PE node. 🎀 You can either configure that manually or grab it by inspecting the matching sub-TLVs of the PW Switching Point PE TLV. Pick your vibe. ✨
The necessary SP-PE sub-TLVs are:
Type Description
0x01 PWid of last PW segment traversed
0x03 Local IP address of PW Switching Point
0x04 Remote IP address of last PW Switching Point traversed or
of the T-PEWhen you're doing an OPTIONAL MS-PW path trace operation, the T-PE automatically learns the target FEC by probing the S-PEs of the MS-PW path one by one. 🧚 It uses the FEC returned in the Target FEC stack of the previous VCCV echo reply to keep going. Iconic self-discovery behavior. 💅
9.6.1.2. Receiving a VCCV Echo Request
When a VCCV echo request lands, the control plane on the S-PEs (or the target node of each segment of the MS-PW) validates it and replies with an echo reply carrying a return code of 8 (label switched at stack depth). That return code basically says "hi, I'm an S-PE, not the egress router for the MS-PW." 🫶
S-PEs that want to reveal their downstream next-hop in a trace operation should put the FEC of the downstream PW segment in the Target FEC stack of the echo reply (as per Sections 3.2 and 4.5 of [RFC4379]). Real talk, the formatting is strict: FEC 128 PWs MUST use the format shown in Section 3.2.9 of [RFC4379] for the sub-TLV in the Target FEC stack, while FEC 129 PWs MUST use the format shown in Section 3.2.10 of [RFC4379] for the sub-TLV in the Target FEC stack. 📏 Also, an S-PE MUST NOT include this FEC information in the reply if it's been configured not to for administrative reasons or for the reasons explained previously. Don't spill the tea if you're not supposed to. 🤫
If the node is the T-PE or the egress node of the MS-PW, it replies to the echo request with a return code of 3 (Egress Router). 👑
9.6.1.3. Receiving a VCCV Echo Reply
What the node does with an echo reply depends on the VCCV mode of operation described above. 🌸 See Section 9.5.2 for the detailed procedures. It's giving "read the next section first" energy. 📖
9.6.2. Detailed VCCV Procedures 🔍
Okay there are two similar methods for verifying the MS-PW path: Path Trace and Path Verification. 💜 Path Trace doesn't use the LDP control plane to get info about the path you're verifying, so it's a great fit if parts of the MS-PW are statically configured SS-PWs. Path Verification relies on info from the LDP control plane, so it gives you a better check on the current forwarding behavior compared to the LDP signaled forwarding info of the MS-PW path. ✨ The catch: if there are statically signaled SS-PWs in the MS-PW path, that path info isn't available and has to be programmed manually. Plan accordingly, bestie. 🧠
9.6.2.1. End-to-End Connectivity Verification between T-PEs
In Figure 3, if T-PE1, S-PE, and T-PE2 support Control Word, the PW control plane automatically negotiates the use of the CW. 🌈 VCCV CC Type 3 works correctly whether or not the CW is enabled on the PW. However, VCCV Type 1 (which can be use for end-to-end verification only) is only supported if the CW is enabled. Lowkey picky, but that's the rule. 🙈
At the S-PE, the data path operations are an outer label pop, an inner label swap, and a new outer label push. 🦋 There's no requirement for the S-PE to inspect the CW, so you can verify end-to-end connectivity of the multi-segment pseudowire by doing all of these steps:
-i. The T-PE forms a VCCV-Ping echo request message with the FEC matching that of the last PW segment to the destination T-PE.
-ii. The T-PE sets the inner PW label TTL to the exact value that lets the packet reach the far-end T-PE. (That value is determined by counting the number of S-PEs from the control plane information.) Alternatively, if CC Type 1 is supported, the packet can be encapsulated according to CC Type 1 in [RFC5085].
-iii. The T-PE sends a VCCV packet that follows the exact same data path at each S-PE as the one taken by data packets. 🛣️
-iv. The S-PE may perform an outer label pop, if Penultimate Hop Popping (PHP) is disabled, and it performs an inner label swap with TTL decrement and a new outer label push.
-v. There's no requirement for the S-PE to inspect the CW. 🙃
-vi. The VCCV packet is diverted to VCCV control processing at the destination T-PE. 🎯
-vii. The destination T-PE replies using the specified reply mode, i.e., reverse PW path or IP path. 💖
9.6.2.2. Partial Connectivity Verification from T-PE
To trace only part of the multi-segment pseudowire, you can use the TTL of the PW label to force the VCCV message to 'pop out' at an intermediate node. 🧚♀️ When the TTL expires, the S-PE can tell the packet is a VCCV packet either by checking the CW or, if the CW isn't in use, by checking for a valid IP header with UDP destination port 3503. Then the packet should be diverted to VCCV processing. 🍓
In Figure 3, if T-PE1 sends a VCCV message with the TTL of the PW label equal to 1, the TTL expires at the S-PE. T-PE1 can then verify the first segment of the pseudowire. Lowkey genius. 🧠
The VCCV packet is built according to [RFC4379], Section 3.2.9 for FEC 128, or Section 3.2.10 for FEC 129. All the info needed to build the VCCV LSP ping packet is collected by inspecting the S-PE TLVs. 📦
Note that this use of the TTL is subject to the caution expressed in [RFC5085]. If a penultimate LSR between S-PEs, or between an S-PE and a T-PE, manipulates the PW label TTL, the VCCV message may not emerge from the MS-PW at the correct S-PE. Yikes, so be careful. 😬
9.6.2.3. Partial Connectivity Verification between S-PEs
Assuming all nodes along an MS-PW support the Control Word CC Type 3, VCCV between S-PEs can be done using the PW label TTL, just like above. 🌷 In Figure 3, the S-PE can verify the path between itself and T-PE2 by sending a VCCV message with the PW label TTL set to 1. In a more complex network with multiple S-PEs, an S-PE can verify connectivity with an S-PE two segments away by sending a VCCV message with the PW label TTL set to 2. So basically, an S-PE can diagnose connectivity problems by successively increasing the TTL. 📈 All the info needed to build the proper VCCV echo request packet (as described in [RFC4379], Sections 3.2.9 or 3.2.10) is obtained automatically from the LDP label mapping that contains the S-PE TLVs. Automatic, no cap. ✨
9.6.2.4. MS-PW Path Verification
Here's an example: in Figure 3, a VCCV trace can be run on the MS-PW originating from T-PE1 with one single operational command. 🎀 The following process happens:
-i. T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC containing the pseudowire information of the first segment (PW1 between T-PE1 and S-PE) to the S-PE for validation. If FEC Stack Validation is enabled, the request may also include an additional sub-TLV, such as LDP Prefix and/or RSVP LSP, depending on the type of transport tunnel the segmented PW is riding on. 🚇
-ii. The S-PE validates the echo request with the FEC. Since it's a switching point between the first and second segment, it builds an echo reply with a return code of 8 and sends that echo reply back to T-PE1. 🔁
-iii. T-PE1 builds a second VCCV echo request based on the info from the control plane (SP-PE TLV). It then increments the TTL and sends it out to T-PE2. Note that the VCCV echo request packet is switched at the S-PE data path and forwarded to the next downstream segment without any involvement from the control plane. Hands-off, we love to see it. 🙌
-iv. T-PE2 receives and validates the echo request with the FEC. Since T-PE2 is the destination node or the egress node of the MS-PW, it replies to T-PE1 with an echo reply with a return code of 3 (Egress Router). 👑
-v. T-PE1 receives the echo reply from T-PE2. T-PE1 knows T-PE2 is the destination of the MS-PW because the echo reply has a return code of 3. The trace process is complete. 🥳
If no echo reply is received, or an error code is received from a particular PE, the trace process MUST stop immediately, and packets MUST NOT be sent further along the MS-PW. Full stop, no exceptions. 🛑
For more detail on the format of the VCCV echo packet, check [RFC5085] and [RFC4379]. The TTL here refers to that of the inner (PW) label TTL. 💅
9.6.2.5. MS-PW Path Trace ✨
okay so picture Figure 3 🦋. a VCCV trace can be run on the MS-PW starting at T-PE1 with one single operational command 💅. the following OPTIONAL process happens:
- T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC containing the pseudowire information of the first segment (PW1 between T-PE1 and S-PE) to S-PE for validation. If FEC Stack Validation is enabled, the request may also include an additional sub-TLV such as LDP Prefix and/or RSVP LSP, dependent on the type of transport tunnel the segmented PW is riding on 🚗
- the S-PE validates the echo request with the FEC 🔍
- the S-PE builds an echo reply with a return code of 8 and sends the echo reply back to T-PE1. it appends the FEC 128 information for the next segment along the MS-PW to the VCCV echo reply packet using the Target FEC stack TLV (as per Sections 3.2 and 4.5 of [RFC4379]) 🎀
- T-PE1 builds a second VCCV echo request based on the information from the FEC stack TLV in the previous VCCV echo reply. then it increments the TTL and sends it out to T-PE2. ngl this part is so cool: the VCCV echo request packet is switched at the S-PE data path and forwarded to the next downstream segment without any involvement from the control plane 🧚
- T-PE2 receives and validates the echo request with the FEC. since T-PE2 is the destination node or the egress node of the MS-PW, it replies to T-PE1 with an echo reply with a return code of 3 (Egress Router) 👑
- T-PE1 receives the echo reply from T-PE2. T-PE1 knows T-PE2 is the destination of the MS-PW because the echo reply has a return code of 3. the trace process is completed 🌈
if no echo reply comes back, or an error code shows up from a particular PE, the trace process MUST stop immediately, and packets MUST NOT be sent further along the MS-PW. no exceptions bestie 🙈
for more detail on the format of the VCCV echo packet, check out [RFC5085] and [RFC4379]. the TTL here refers to that of the inner (PW) label TTL 💜
10. Mapping Switched Pseudowire Status 🦋
in the PW switching with attachment circuits case (Figure 2), PW status messages that indicate PW or attachment circuit faults MUST be mapped to fault indications or OAM messages on the connecting AC as defined in [PW-MSG-MAP] 🔗
in the PW control plane switching case (Figure 3), there is no attachment circuit at the S-PE, but the two PWs are connected together. the status of the PWs is forwarded unchanged from one PW to the other by the control plane switching function, no cap 💅. still, it may sometimes be necessary to communicate the fault status of one of the locally attached PW segments at an S-PE. for LDP, this can be done by sending an LDP notification message containing the PW status TLV, plus an OPTIONAL PW Switching Point PE TLV, like this 🌸:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Status (0x0300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Status Code=0x00000028 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type=0 | PW Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Status TLV | PWid FEC or Generalized ID FEC|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| PWid FEC or Generalized ID FEC (contd.) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| SP-PE TLV (0x096D) | SP-PE TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+only one SP-PE TLV can be present in this message. the message is then relayed by each S-PE unchanged 🔁. the T-PE decodes the status message and the included SP-PE TLV to detect exactly where the fault occurred 🕵️♀️. at the T-PE, if there is no SP-PE TLV in the LDP status notification, then the status message can be assumed to have originated at the remote T-PE 💅
the merging of the received LDP status and the local status for the PW segments at an S-PE goes like this:
- when the local status for both PW segments is UP, the S-PE passes any received AC or PW status bits unchanged. that means the status notification TLV is unchanged, but the PWid in the case of a FEC 128 TLV is set to the value of the PW segment of the next hop 🎀
- when the local status for any of the PW segments is at fault, the S-PE always sends the local status bits, regardless of whether the received status bits from the remote node indicated that an upstream fault has cleared. AC status bits are passed along unchanged 🫶
10.1. PW Status Messages Initiated by the S-PE 🌸
the PW fault directions are defined like so 🧭:
+-------+
---PW1 Receive---->| |-----PW2 Transmit---->
S-PE1 | S-PE2 | S-PE3
<--PW1 Transmit----| |<----PW2 Receive------
+-------+
Figure 4: S-PE and PW Transmission/Reception Directionswhen the S-PE detects a local fault, a PW status message is sent in both directions along the PW. since there are no attachment circuits on an S-PE, only these status messages are relevant:
0x00000008 - Local PSN-facing PW (ingress) Receive Fault
0x00000010 - Local PSN-facing PW (egress) Transmit Faulteach S-PE needs to store only two 32-bit PW status words for each PW segment: one for local failures and one for remote failures (normally received from another PE). the first failure sets the appropriate bit in the 32-bit status word, and each subsequent failure gets ORed into the appropriate PW status word. when the PW status word stores remote failures, this rule works out to a logical OR operation with the first failure received on that PW segment 🧠
it should be noted that remote failures received on an S-PE are just passed along the MS-PW unchanged, while local failures detected at an S-PE are signaled on both PW segments 📣
a T-PE can receive multiple failures from S-PEs along the MS-PW. however, only the failure from the remote closest S-PE gets stored (last PW status message received). the PW status word received is just ORed to any existing remote PW status already stored on the T-PE 🌈
given that there are two PW segments at a particular S-PE for a particular MS-PW (referring to Figure 4), there are four possible failure cases:
- PW2 Transmit direction fault
- PW1 Transmit direction fault
- PW2 Receive direction fault
- PW1 Receive direction fault
once a PW status notification message is initiated at an S-PE for a particular PW status bit, any further status message for the same status bit (received from an upstream neighbor) is processed locally and not forwarded until the S-PE's original status error state is cleared 🔒
each S-PE along the MS-PW MUST store any PW status messages transiting it. if more than one status message with the same PW status bit set is received by a T-PE or S-PE, only the last PW status message is stored 📦
10.1.1. Local PW2 Transmit Direction Fault 💜
when this failure occurs, the S-PE takes these actions:
- send a PW status message to S-PE3 containing
"0x00000010 - Local PSN-facing PW (egress) Transmit Fault". - send a PW status message to S-PE1 containing
"0x00000008 - Local PSN-facing PW (ingress) Receive Fault". - store
0x00000010in the local PW status word for the PW segment toward S-PE3.
10.1.2. Local PW1 Transmit Direction Fault 🦋
when this failure occurs, the S-PE takes these actions:
- send a PW status message to S-PE1 containing
"0x00000010 - Local PSN-facing PW (egress) Transmit Fault". - send a PW status message to S-PE3 containing
"0x00000008 - Local PSN-facing PW (ingress) Receive Fault". - store
0x00000010in the local PW status word for the PW segment toward S-PE1.
10.1.3. Local PW2 Receive Direction Fault 🍓
when this failure occurs, the S-PE takes these actions:
- send a PW status message to S-PE3 containing
"0x00000008 - Local PSN-facing PW (ingress) Receive Fault". - send a PW status message to S-PE1 containing
"0x00000010 - Local PSN-facing PW (egress) Transmit Fault". - store
0x00000008in the local PW status word for the PW segment toward S-PE3.
10.1.4. Local PW1 Receive Direction Fault 🧚
when this failure occurs, the S-PE takes these actions:
- send a PW status message to S-PE1 containing
"0x00000008 - Local PSN-facing PW (ingress) Receive Fault". - send a PW status message to S-PE3 containing
"0x00000010 - Local PSN-facing PW (egress) Transmit Fault". - store
0x00000008in the local PW status word for the PW segment toward S-PE1.
10.1.5. Clearing Faults ✨
remote PW status fault clearing messages received by an S-PE only get forwarded if there are no corresponding local faults on that S-PE. (local faults always supersede remote faults, periodt 👑)
once the local fault has cleared, and there is no corresponding remote fault (same PW status bit set), a PW status message is sent out to the adjacent PEs to clear the fault 🫧
when a PW status fault clearing message is forwarded, the S-PE always sends the SP-PE TLV associated with the PE that cleared the fault 🎀
10.2. PW Status Messages and SP-PE TLV Processing 💅
when a PW status message is received that includes an SP-PE TLV, the SP-PE TLV information MAY be stored, along with the contents of the PW status Word, according to the procedures described above 🌷. the SP-PE TLV stored is always the SP-PE TLV associated with the PE that set that particular last fault. if subsequent PW status messages for the same PW status bit are received, the SP-PE TLV overwrites the previously stored SP-PE TLV 🔁
10.3. T-PE Processing of PW Status Messages 🎀
okay so the whole PW switching setup is built on one idea: the T-PE handles PW LDP messages the same way it would if it were helping set up a regular PW segment 💅. BUT a T-PE that's part of an MS-PW SHOULD be able to process the SP-PE TLV 🧚. Otherwise, handling PW status messages and other PW setup messages is exactly what [RFC4447] describes. no cap, it's giving continuity 💖
10.4. Pseudowire Status Negotiation Procedures ✨
so the PW status signaling method from [RFC4447] SHOULD be transparent to the switching point 🫶. the switch just sits there looking pretty and doesn't get in the way 🦋
10.5. Status Dampening 🌸
okay this one is a little spicy 🌶️. when the PW control plane switching method crosses an administrative boundary, you might need to stop a flood of status changes from getting passed across that boundary 😭. the fix is basically the same trick people use for BGP route advertisement dampening 🔥. the details of this OPTIONAL algorithm are up to whoever implements it and are outside the scope of this document, so it's a "you do you" situation 💅
11. Peering between Autonomous Systems 🌈
the procedures in this document can be used to provision and manage MS-PWs that cross AS boundaries 👑. fancier stuff involving auto-discovery and ordered PWE3 MS-PW signaling is coming later in a separate document 👀, so stay tuned bestie ✨
12. Congestion Considerations 🌊
every PSN carrying the PW might get congested, periodt 😩. the congestion considerations in [RFC3985] apply to PW segments too 💜. each PW segment handles any congestion the PW traffic runs into on its own, separate from the other MS-PW segments 🧚. it's possible that sharing congestion knowledge between segments and with the T-PEs could lead to more efficient edge-to-edge congestion mitigation 🔥. but any specific congestion mitigation methods are outside the scope of this document and left for further study 🙈
13. Security Considerations 💀
okay this section is SERIOUS and I'm here for it 😤. this document specifies the LDP, L2TPv3, and VCCV extensions needed to set up and maintain pseudowires 🎀. the whole point of pseudowires is to encapsulate Layer 2 frames and carry them from one end of a pseudowire to the other 🦋. so we talk about security for both the data plane and the control plane in the sections below 💖. the guidelines and security considerations in [RFC5920] also apply to MS-PW when the PSN is MPLS 🔐
13.1. Data Plane Security 🛡️
data plane security stuff from [RFC4447], [RFC3931], and [RFC3985] applies to this extension without any changes ✨
13.1.1. VCCV Security Considerations 🔍
the VCCV technology for MS-PW gives the service provider a way to verify the data path of a specific PW 👀. it works by sending a packet to a specific PE and getting an answer that either confirms what the packet contained or says it's wrong 💅. it's super similar to the ICMP ping and TTL expired methods people already use for IP networks 🧚
here's the tea ☕. when you use VCCV Type 3 on a PW where the CW isn't enabled, a packet crafted with a TTL greater than the number of hops along the MS-PW path could be a problem 😱. same goes if an S-PE on the path mis-processes the TTL 💀. then the packet could mistakenly get forwarded out of the attachment circuit as a native PW packet 🙈. the CE would most likely treat it as an error packet, but if that possibility isn't acceptable to you, enable the CW so a VCCV packet can never be mistakenly forwarded to the AC 🔒🫶
13.2. Control Protocol Security 🔐
general security considerations for using LDP are in Section 5 of RFC 5036 💜. security considerations for the L2TPv3 control plane are in [RFC3931] 🦋. these considerations also apply when LDP or L2TPv3 is used to set up PWs ✨
okay this part is so important 😭. a pseudowire connects two attachment circuits, so LDP connections must not get accepted from just anywhere 🚫. otherwise a local attachment circuit might end up connected to some random remote attachment circuit 💀. so an incoming session request MUST NOT be accepted unless its IP source address is known to be the source of an "eligible" peer 🛑. the set of eligible peers could be pre-configured (either as a list of IP addresses or as a list of address/mask combinations), or it could be discovered dynamically through an auto-discovery protocol that is itself trusted 🔑. (fyi, if the auto-discovery protocol isn't trusted, the set of "eligible peers" it produces can't be trusted either 🙃)
even if a connection request looks like it's coming from an eligible peer, the source address could have been spoofed 👻. so some means of preventing source address spoofing must be in place 🛡️. for example, if all the eligible peers are in the same network, source address filtering at that network's border routers could rule out spoofing entirely 🧱
for a greater degree of security, the LDP authentication option from Section 2.9 of [RFC5036], or the Control Message Authentication option of [RFC3931], MAY be used 🔐✨. this gives integrity and authentication for the control messages and eliminates the possibility of source address spoofing 💪. using the message authentication option doesn't give you privacy, but privacy of control messages usually isn't considered super important 🤷♀️. both the LDP and L2TPv3 message authentication options rely on pre-shared keys, which makes them hard to deploy when the set of eligible neighbors is decided by an auto-configuration protocol 😩
the protocol in this document relies on the LDP MD5 authentication key option from Section 2.9 of [RFC5036] to provide integrity and authentication for the LDP messages and protect against source address spoofing 🔑. this relies on pre-shared keys, which typically brings some fragility 🥲. but for MS-PW specifically, the number of links leaving an organization will be limited in practice, so relying on pre-shared keys should be manageable 💅🌸
when the Generalized PWid FEC Element is used, a particular peer might be one of the eligible peers but still not the right one to connect to the particular attachment circuit identified by that instance of the Generalized ID FEC element 🙈. still, since the peer is known to be one of the eligible peers, that would be a configuration error rather than a security problem 🧐. even so, it may be advisable for a PE to associate each of its local attachment circuits with a set of eligible peers, instead of having just one set of eligible peers for the whole PE 🧚💖
14. IANA Considerations 📋
14.1. L2TPv3 AVP 🦋
this document uses a new L2TP parameter 💅. IANA already maintains the "Control Message Attribute Value Pairs" registry defined by [RFC3438] ✨. the following new value has been assigned 👑:
101 PW Switching Point AVP14.2. LDP TLV TYPE 🌷
this document uses a new LDP TLV type 💜. IANA already maintains the "TLV TYPE NAME SPACE" registry defined by RFC 5036 🫶. the following value has been assigned 🎀:
TLV type Description
0x096D Pseudowire Switching Point PE TLV14.3. LDP Status Codes 🚨
this document uses a new LDP status code 🔥. IANA already maintains the "STATUS CODE NAME SPACE" registry defined by RFC 5036 🧚. the following value has been assigned ⭐:
Assignment E Description
0x0000003A 0 PW Loop Detected14.4. L2TPv3 Result Codes 🌈
this document uses a new L2TPv3 Result Code for the CDN message, as assigned by IANA in the "Result Code AVP (Attribute Type 1) Values" registry 🎀. here's the registry info 📖:
Registry Name: Result Code AVP (Attribute Type 1) Values Defined
Result Code values for the CDN message are:
Assignment Description
31 Sequencing not supported14.5. New IANA Registries 💖
IANA has set up a registry called "Pseudowire Switching Point PE sub-TLV Type" 🦋. these are 8-bit values 🔢. type values 1 through 6 are defined in this document 🫶. type values 7 through 64 are to be assigned by IANA using the "Expert Review" policy defined in [RFC5226] 👀. type values 65 through 127, plus 0 and 255, are to be allocated using the IETF consensus policy defined in RFC 5226 🧠. type values 128 through 254 are reserved for vendor proprietary extensions and are to be assigned by IANA using the "First Come First Served" policy defined in RFC 5226 🏷️
the type values are assigned like this 💅:
Type Length Description
0x01 4 PWid of last PW segment traversed
0x02 variable PW Switching Point description string
0x03 4/16 Local IP address of PW Switching Point
0x04 4/16 Remote IP address of last PW Switching Point
traversed or of the T-PE
0x05 variable FEC Element of last PW segment traversed
0x06 12 L2 PW address of PW Switching Point15. Normative References 📚
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
- [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. 🌍
- [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 🦋
- [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. 🌐
- [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 🔍
- [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. 🎀
- [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 📋
- [RFC4447] 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. 💖
- [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007. 🧩
- [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007. 🔗
- [RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. ✅
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 📝
- [RFC5641] McGill, N. and C. Pignataro, "Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values", RFC 5641, August 2009. ⭐
16. Informative References ✨
Okay bestie, here are the informative references 📚🎀 These are the docs the spec leans on for background. They're not required reading to implement, but they're super useful if you want the full picture.
- [PW-MSG-MAP] Aissaoui, M., Busschbach, P., Morrow, M., Martini, L., Stein, Y(J)., Allan, D., and T. Nadeau, "Pseudowire (PW) OAM Message Mapping", Work in Progress, October 2010. 🦋
- [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. 💜
- [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002. 🌸
- [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. ✨
- [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. 🧚
- [RFC4454] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May 2006. 🫶
- [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006. 💅
- [RFC4667] Luo, W., "Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)", RFC 4667, September 2006. 🌈
- [RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and G. Koleyni, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717, December 2006. 🍓
- [RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008. 👑
- [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009. ⭐
- [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. 🔥
17. Acknowledgments 🙈
The authors wanted to give a shoutout to Satoru Matsushima, Wei Luo, Neil Mcgill, Skip Booth, Neil Hart, Michael Hua, and Tiberiu Grigoriu 🫶💖 Literally couldn't have done it without them.
18. Contributors 🎀
These people also contributed text to this document, so they get their flowers too 💐
Contributor one:
Florin Balus
Alcatel-Lucent
701 East Middlefield Rd.
Mountain View, CA 94043
US
EMail: florin.balus@alcatel-lucent.comMike Duckett
Bellsouth
Lindbergh Center, D481
575 Morosgo Dr
Atlanta, GA 30324
US
EMail: mduckett@bellsouth.netAuthors' Addresses 💜
Here's where you can find the authors, slay 💅
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO 80112
US
EMail: lmartini@cisco.comChris Metz
Cisco Systems, Inc.
EMail: chmetz@cisco.comThomas D. Nadeau
EMail: tnadeau@lucidvision.comMatthew Bocci
Alcatel-Lucent
Grove House, Waltham Road Rd
White Waltham, Berks SL6 3TN
UK
EMail: matthew.bocci@alcatel-lucent.co.ukMustapha Aissaoui
Alcatel-Lucent
600, March Road,
Kanata, ON
Canada
EMail: mustapha.aissaoui@alcatel-lucent.com📦 where this page comes from
- ietf: rfc6073 2011-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms