RFC 8077
Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)
Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) 🎀
okay bestie, this is the title block and it's giving official standards energy 💅 Here's the tea:
- RFC number: 8077
- Title: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)
- Authors: L. Martini, Ed. and G. Heron, Ed., both from Cisco 🧚
- Category: Standards Track, and it's STD 84 🌈
- Date: February 2017
- Obsoletes: RFC 4447 and RFC 6723 💀
- Updates: none listed in the header
- ISSN: 2070-1721
Abstract ✨
okay so layer 2 stuff like Frame Relay, Asynchronous Transfer Mode, and Ethernet can be copied over an MPLS backbone like it's nothing 🦋 You wrap up the Layer 2 Protocol Data Units (PDUs) and send them through pseudowires (PWs). You can also use pseudowires for low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation on an MPLS-enabled network, which is so cool 🔥
This doc defines a protocol for setting up and maintaining those pseudowires by extending the Label Distribution Protocol (LDP) 💖 How the Layer 2 PDUs actually get encapsulated is covered in other documents, so that's a different chapter bestie 📚
This document is a rewrite of RFC 4447 so it can be published as an Internet Standard 👑
Status of This Memo 🌸
This is an Internet Standards Track document, so it's the real deal ✅
It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 🫶 If you want more info on Internet Standards, check out Section 2 of RFC 7841.
Want the current status, errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc8077 💜
Copyright Notice 🦋
Copyright (c) 2017 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), as they stand on the publication date. Please actually read these, bestie, because they explain your rights and restrictions for this document 🙈 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, and they come without warranty, as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The person or people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So without an adequate 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. Changes from RFC 4447 ...........................................6
3. Specification of Requirements ...................................6
4. The Pseudowire Label ............................................7
5. Details Specific to Particular Emulated Services ................9
5.1. IP Layer 2 Transport .......................................9
6. LDP .............................................................9
6.1. The PWid FEC Element .......................................9
6.2. The Generalized PWid FEC Element ..........................11
6.2.1. Attachment Identifiers .............................12
6.2.2. Encoding the Generalized PWid FEC Element ..........14
6.2.2.1. PW Interface Parameters TLV ...............15
6.2.2.2. PW Group ID TLV ...........................15
6.2.3. Signaling Procedures ...............................16
6.3. Signaling of Pseudowire Status ............................17
6.3.1. Use of Label Mapping Messages ......................17
6.3.2. Signaling PW Status ................................18
6.3.3. Pseudowire Status Negotiation Procedures ...........19
6.4. Interface Parameter Sub-TLV ...............................20
6.5. LDP Label Withdrawal Procedures ...........................21
7. Control Word ...................................................22
7.1. PW Types for Which the Control Word Is REQUIRED ...........22
7.2. PW Types for Which the Control Word Is NOT Mandatory ......22
7.3. Control-Word Renegotiation by Label Request Message .......24
7.4. Sequencing Considerations .................................25
7.4.1. Label Advertisements ...............................25
7.4.2. Label Release ......................................25
8. IANA Considerations ............................................26
8.1. LDP TLV TYPE ..............................................26
8.2. LDP Status Codes ..........................................26
8.3. FEC Type Name Space .......................................26
9. Security Considerations ........................................26
9.1. Data-Plane Security .......................................27
9.2. Control-Plane Security ....................................28
10. Interoperability and Deployment ...............................29
11. References ....................................................29
11.1. Normative References .....................................29
11.2. Informative References ...................................30
Acknowledgments ...................................................31
Contributors ......................................................32
Authors' Addresses ................................................35(Part 1 of 8 is done, part 2 is next!) 🧚
1. Introduction ✨
okay bestie, so [RFC4619], [RFC4717], [RFC4618], and [RFC4448] explain how to encapsulate a Layer 2 Protocol Data Unit (PDU) so it can travel over an MPLS-enabled network 🦋 these docs say a "pseudowire header" with a demultiplexer field gets prepended to the encapsulated PDU. the demultiplexer gets slapped on right before a packet goes out on a pseudowire, and when it lands at the far end, that field is how the receiver figures out which pseudowire it came in on 💖 if the packet needs to get from one pseudowire endpoint to the other, it might have to ride through a "Packet Switched Network (PSN) tunnel", which means another header gets added on top 🌸
[RFC4842] and [RFC4553] are the two methods for sending time-division multiplexing (TDM) digital signals (TDM circuit emulation) over a packet-oriented MPLS-enabled network 🧚 the circuit-oriented TDM world runs on the Synchronous Optical Network (SONET) [ANSI] / Synchronous Digital Hierarchy (SDH) [ITUG] transmission system. TDM traffic covers voice, data, and private leased-line service, so pseudowires have to fake the circuit characteristics of SONET/SDH payloads. the TDM signals and payloads get encapsulated for the pseudowire trip, and a pseudowire demultiplexer plus a PSN tunnel header get prepended to that encapsulation. it's giving layers, periodt 🎀
[RFC4553] covers low-rate TDM digital signals (TDM circuit emulation) over PSNs, and [RFC4842] covers high-rate TDM (SONET/SDH) transport in the same way 🍓 pseudowires have to emulate the circuit characteristics of the original T1, E1, T3, E3, SONET, or SDH signals. [RFC4553] does it by packing an arbitrary but constant amount of TDM data into each packet, and the other method encapsulates TDM structures instead 💜
In this document, we specify the use of the MPLS Label Distribution Protocol (LDP) [RFC5036] as the protocol for setting up and maintaining pseudowires. we're basically defining new TLVs, Forwarding Equivalence Class (FEC) elements, parameters, and codes for LDP 😭 these let LDP identify pseudowires and signal their attributes. we also explain how a pseudowire endpoint uses those TLVs to bind a demultiplexer field value to a pseudowire, and how it tells the remote endpoint about that binding. then there are procedures for reporting pseudowire status changes, passing extra info about the pseudowire when needed, and releasing bindings. all of this is meant to work no matter which version of IP is used for LDP signaling ✨
Here's the big thing: in this protocol, the pseudowire demultiplexer field is an MPLS label 👑 so the packets moving from one end of the pseudowire to the other are MPLS packets, and they have to go through an MPLS tunnel. the exception is when the pseudowire endpoints sit right next to each other and penultimate hop popping behavior is in use, because then the MPLS tunnel might not be needed 🙈 any kind of PSN tunnel works, as long as it can carry MPLS packets through. the PSN tunnel can be an MPLS LSP or any other tunnel that carries MPLS packets. how to set up and maintain those MPLS tunnels is out of scope for this doc 🦋
This document only deals with setting up and maintaining point-to-point pseudowires. point-to-multipoint and multipoint-to-point pseudowires are not discussed, so don't come for them here 💅
QoS-related issues are not discussed in this document 🫶
Okay, the reference models below are derived from [RFC3985] to support the PW emulated services. look at how it all stacks up 🌈
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
|Attachment| |<-- PSN Tunnel -->| |Attachment|
| Circuit V V V V Circuit |
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
+-----------------+ +-----------------+
|Emulated Service | |Emulated Service |
|(e.g., TDM, ATM) |<==== Emulated Service ===>|(e.g., TDM, ATM) |
+-----------------+ +-----------------+
| Payload | | Payload |
| Encapsulation |<====== Pseudowire =======>| Encapsulation |
+-----------------+ +-----------------+
|PW Demultiplexer | |PW Demultiplexer |
| PSN Tunnel, |<======= PSN Tunnel ======>| PSN Tunnel, |
| PSN & Physical | | PSN & Physical |
| Layers | | Layers |
+-------+---------+ ___________ +---------+-------+
| / \ |
+===============/ PSN \================+
\ /
\_____________/Figure 2: PWE3 Protocol Stack Reference Model
For this doc, PE1 (Provider Edge 1) is the ingress router and PE2 is the egress router 🧚 a Layer 2 PDU comes in at PE1, gets encapsulated there, gets transported and decapsulated at PE2, and then goes out of PE2. easy peasy 💖
2. Changes from RFC 4447 💅
the changes here are mostly small fixes to spelling and grammar, plus some clarifications to the text 🌸 they were either noted as errata to [RFC4447] or caught by the editors, so nothing dramatic 🙈
Also, Section 7.3 ("Control-Word Renegotiation by Label Request Message") got added, and it obsoletes [RFC6723] 👑 the diagram of C-bit handling procedures got removed too. there's a new note in Section 6.3.2 that clarifies the C-bit is part of the FEC ✨
A reference to [RFC7358] was also added, to show the use of downstream unsolicited mode for distributing PW FEC label bindings. this works independently of the negotiated label advertisement mode of the LDP session 🦋
3. 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]. 🫶
4. The Pseudowire Label ✨
Okay so, picture this: we want to send Layer 2 PDUs from ingress LSR PE1 to egress LSR PE2, and there's an MPLS-enabled network in the middle 🌸. We're assuming there's an MPLS tunnel from PE1 to PE2. PE1 can get a packet delivered to PE2 by wrapping it in an "MPLS tunnel header" and sending it out to one of its adjacencies. The tunnel is an MPLS Label Switched Path (LSP), so putting on the tunnel encapsulation just means pushing an MPLS label on. Simple, iconic 💅.
We're also presupposing that a huge number of pseudowires can ride through one MPLS tunnel. That means the network core never has to keep state for each individual pseudowire, which is literally the dream 🧚. We are not presupposing that the MPLS tunnels are point to point. The pseudowires are point to point, but the tunnels can be multipoint to point. We also aren't assuming PE2 can even tell which MPLS tunnel a received packet came through. For example, if the tunnel is an LSP and penultimate hop popping is used, the packet shows up at PE2 with zero info about the tunnel 🙈.
So when PE2 gets a packet over a pseudowire, it has to be able to figure out that it really came over a pseudowire, and it has to match that packet to a specific pseudowire. How? It looks at the MPLS label that works as the pseudowire demultiplexer field, shown in Figure 2. We're calling that the "PW label" 🎀.
When PE1 sends a Layer 2 PDU to PE2, it builds an MPLS packet by adding the PW label, which becomes the first entry of the label stack. If the PSN tunnel is an MPLS LSP, PE1 also pushes another label (the tunnel label) on as the second entry. The PW label doesn't show up again until the MPLS packet reaches PE2, and PE2 decides what to do with the packet based on the PW label. Main character energy 👑.
If the payload is, say, an ATM Adaptation Layer 5 (AAL5) PDU, the PW label will usually line up with one particular ATM Virtual Circuit (VC) at PE2. So PE2 needs to be able to work out from the PW label which outgoing interface to use, along with the VPI/VCI (Virtual Path Identifier / Virtual Circuit Identifier) value for the AAL5 PDU. If the payload is a Frame Relay PDU, PE2 needs to get the outgoing interface and the Data Link Connection Identifier (DLCI) value from the PW label. If the payload is an Ethernet frame, PE2 needs the outgoing interface, and maybe the VLAN identifier, from the PW label. This whole process is unidirectional, and it gets repeated independently for bidirectional operation 🦋.
When you're using the PWid FEC Element, it is REQUIRED that the same PW ID and PW type get assigned for a given circuit in both directions. The Group ID (see below) MUST NOT be required to match in both directions. The transported frame MAY be modified when it reaches the egress router. If the header of the transported Layer 2 frame does get modified, that MUST happen at the egress LSR only. And note that the PW label must always sit at the bottom of the packet's label stack, and labels MUST be allocated from the per-platform label space 💖.
Now, this document doesn't specify how the MPLS tunnel label, or any other labels that might sit above the PW label on the stack, get distributed. Any acceptable MPLS label distribution method will do 🌈. What this document does specify is a protocol for assigning and distributing the PW label, and that protocol is LDP, extended as described in the rest of this document. An LDP session has to be set up between the pseudowire endpoints. LDP MUST exchange PW FEC label bindings in downstream unsolicited mode, independent of the negotiated label advertisement mode of the LDP session, following the specifications in [RFC7358]. LDP's "liberal label retention" mode SHOULD be used. However, every LDP procedure that's specified in [RFC5036] and also applies to this protocol MUST be implemented. Don't skip any 🫶.
This document requires that a receiving LSR MUST respond to a Label Request message with either a Label Mapping for the requested label or a Notification message explaining why it can't satisfy the request. These procedures are in [RFC5036], Sections 3.5.7 ("Label Mapping Message") and 3.5.8 ("Label Request Message"). Heads up: sending these responses is a stricter requirement than what [RFC5036] asks for, but these response messages are REQUIRED to keep this protocol working correctly ⭐.
Static assignment of PW labels is also allowed, and implementations of this protocol SHOULD provide support for static assignment. PW encapsulation is always symmetrical in both directions of traffic along a specific PW, whether or not the PW uses an LDP control plane 🍓.
This document covers every procedure you need to set up and maintain pseudowires for "unswitched" point-to-point services, where each endpoint is provisioned with the identity of the other endpoint. It also has protocol mechanisms that can support switched services and other provisioning models. But how to use those mechanisms for those other models and services isn't described in this document, so that's a different story 🔥.
5. Details Specific to Particular Emulated Services
5.1. IP Layer 2 Transport
This mode carries IP packets over a pseudowire. The encapsulation is based on [RFC3032]. The PW control word MAY be inserted between the MPLS label stack and the IP payload. How IP packets get encapsulated for forwarding on the Attachment Circuit is implementation specific. It's part of the native service processing (NSP) function [RFC3985], and it's outside the scope of this document 💜.
6. LDP
The PW label bindings are distributed using the LDP downstream unsolicited mode described in [RFC5036]. The PEs will establish an LDP session using the Extended Discovery mechanism described in Sections 2.4.2 and 2.5 of [RFC5036] 🌸.
An LDP Label Mapping message contains a FEC TLV, a Label TLV, and zero or more optional parameter TLVs.
The FEC TLV tells you what the label means. In this context, the FEC TLV is what identifies the particular pseudowire that a given label is bound to. This specification defines two new FEC TLVs for identifying pseudowires. When you set up a particular pseudowire, you only use one of these FEC TLVs. Which one depends on the service being emulated and on the provisioning model being supported ✨.
LDP lets each FEC TLV hold a set of FEC elements. For setting up and maintaining pseudowires, though, each FEC TLV MUST contain exactly one FEC element 🎀.
The LDP base specification has several kinds of label TLVs, including the Generic Label TLV, as specified in Section 3.4.2.1 of [RFC5036]. For setting up and maintaining pseudowires, the Generic Label TLV MUST be used 💅.
6.1. The PWid FEC Element
The PWid FEC Element may be used whenever both pseudowire endpoints have been provisioned with the same 32-bit identifier for the pseudowire 🦋.
For this purpose, a new type of FEC element is defined. The FEC element type is 0x80, and it's laid out 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWid (0x80) |C| PW type |PW info length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Parameter Sub-TLV |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field means:
- Control word bit (
C): this flags whether a control word is present. The values are:
C = 1 control word present on this PW.
C = 0 no control word present on this PW.For more, see Section 7 ("Control Word") 🙈.
- PW type: a 15-bit quantity with a value representing the type of PW. Assigned Values are specified in "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)" [RFC4446] 🍓.
- PW info length: the length, in octets, of the PW ID field and the Interface Parameter Sub-TLV field. If this value is 0, then it references all PWs using the specified Group ID, and there's no PW ID present and no Interface Parameter Sub-TLVs either 🌈.
- Group ID: an arbitrary 32-bit value representing a group of PWs, used to create groups in the PW space. The Group ID is meant to act as a port index or a virtual tunnel index. To keep config simple, a particular PW Group ID at ingress could be part of a Group ID assigned to the virtual tunnel for transport to the egress router. The Group ID is super useful for sending wildcard label withdrawals or PW wildcard status Notification messages to remote PEs when a physical port fails 💀.
- PW ID: a non-zero, 32-bit connection ID that, together with the PW type, identifies a particular PW. Note that the PW ID and the PW type MUST be the same at both endpoints 🫶.
- Interface Parameter Sub-TLV: a variable length TLV used to provide interface-specific parameters, such as Attachment Circuit MTU.
Here's the tea ☕: because the Interface Parameter Sub-TLV is part of the FEC, the rules of LDP make it impossible to change the interface parameters once the pseudowire has been set up. So the interface parameters field must not be used to pass along information, like status information, that might change during the pseudowire's life. Optional parameter TLVs should be used for that purpose 🔥.
Using the PWid FEC, each of the two pseudowire endpoints independently starts the setup of a unidirectional LSP. An outgoing LSP and an incoming LSP get bound together into a single pseudowire if they have the same PW ID and PW type. Bestie, that's the whole pairing trick 👑✨.
6.2. The Generalized PWid FEC Element ✨
okay so the PWid FEC Element works fine if the PW has a unique 32-bit value assigned to it and each endpoint has been set up with that value 🔐. The Generalized PWid FEC Element is the glow-up for when you need the PW endpoints to be uniquely identified, with the PW itself being identified as a pair of endpoints 💖. The endpoint identifiers are also structured so the remote endpoints can be auto-discovered, instead of you having to configure them by hand. Iconic, right? 🦋
The "Generalized PWid FEC Element" is FEC type 0x81 🎀.
The Generalized PWid FEC Element has nothing that matches the Group ID from the PWid FEC Element 🙈. Instead, the Group ID job is handled by a separate optional LDP TLV, the PW Group ID TLV, which you can read about in Section 6.2.2.2 🌸. The interface parameters field is also gone from this one. Its role is taken over by the optional PW Interface Parameters TLV, described in Section 6.2.2.1 💅.
6.2.1. Attachment Identifiers 🧚
As discussed in [RFC3985], a pseudowire can be thought of as connecting two "forwarders" 🌈. The protocol that sets up a pseudowire must let the forwarder at one end identify the forwarder at the other end. The field the protocol uses to identify forwarders is called the "Attachment Identifier", or "AI" for short 🫶. In the PWid FEC, the PWid field is the AI. In this section we define a more general, structured, variable-length form of AI 👑.
Every Forwarder in a PE needs an Attachment Identifier (AI), either through configuration or through some algorithm ⭐. The Attachment Identifier has to be unique within the PE router where the Forwarder lives. And the combination <PE router IP address, AI> has to be globally unique 🔥.
Sometimes it's really handy to treat a bunch of Forwarders as members of a "group", where PWs can only be set up between members of that group 🍓. In that case it makes sense to identify each Forwarder relative to its group, so an Attachment Identifier is made of an Attachment Group Identifier (AGI) plus an Attachment Individual Identifier (AII) 💜.
You can think of an Attachment Group Identifier as a VPN-id or a VLAN identifier, basically some attribute shared by all the Attachment PWs (or pools of them) that are allowed to connect 🎀.
How you build the AGI and AII fields that identify the pseudowire endpoints is outside the scope of this spec 🙈. Different applications and provisioning models need different kinds of AGI and AII fields. Whoever specifies each application and/or model has to include the rules for building its AGI and AII fields 📝.
As we said before, a (bidirectional) pseudowire is really a pair of unidirectional LSPs, one in each direction 🦋. If a pseudowire connects PE1 with PE2, the PW direction from PE1 to PE2 looks like this:
<PE1, <AGI, AII1>, PE2, <AGI, AII2>>,and the PW direction from PE2 to PE1 looks like this:
<PE2, <AGI, AII2>, PE1, <AGI, AII1>>.Here's the tea: the AGI has to be the same at both endpoints, but the AII will usually be different at each one 💅. So from a particular PE's point of view, each pseudowire has a local "Source AII" and a remote "Target AII" ✨. The pseudowire setup protocol can carry all three of these:
- Attachment Group Identifier (AGI)
- Source Attachment Individual Identifier (SAII)
- Target Attachment Individual Identifier (TAII)
If the AGI is non-null, the Source AI (SAI) is the AGI together with the SAII, and the Target AI (TAI) is the TAII together with the AGI 🌸. If the AGI is null, then the SAII and TAII are the SAI and TAI, respectively 🧚.
What the SAI and TAI mean is a local matter at each endpoint 🫶.
Joining two unidirectional LSPs into one bidirectional pseudowire depends on the SAI and the TAI 💖. Every application and/or provisioning model that uses the Generalized PWid FEC has to spell out the rules for doing that join 🔥.
6.2.2. Encoding the Generalized PWid FEC Element 💜
FEC element type 0x81 is used 🎀. The FEC element gets encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Gen PWid (0x81)|C| PW Type |PW info length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This document doesn't specify the AII and AGI type field values 🙈. Specifying the type values for a given application is part of that application's spec. IANA assigned these values using the method defined in [RFC4446] 📝.
The SAII, TAII, and AGI are just carried as octet strings 🌈. The Length byte tells you the size of the Value field. You can send the null string by setting the Length byte to 0 ✨. If an application doesn't need all three of these sub-elements, it MUST send all the sub-elements anyway, but set the Length to 0 for the unused ones 🔥.
The PW information length field holds the combined length of the SAII, TAII, and AGI, in octets 💖. If this value is 0, the element references all PWs that use the specific Group ID (the one given in the PW Group ID TLV) 🦋. In that case there are no other FEC element fields (AGI, SAII, etc.) present, and no PW Interface Parameters TLVs either 🫶.
Heads up: whether a given field counts as AGI, SAII, or TAII depends on where it shows up in the order 👀. The Type field tells you what kind of AGI, SAII, or TAII it is 💜. When you compare two occurrences of an AGI (or SAII or TAII), they count as identical if their Type, Length, and Value fields each match the other's 🎀.
6.2.2.1. PW Interface Parameters TLV 🌸
This TLV MUST only be used when sending the Generalized PWid FEC 🚫. It specifies interface-specific parameters 🔧. Specific parameters MUST be used, when they apply, to check that the PEs and the ingress and egress ports at the edges of the circuit have the capabilities they need to work together 🤝.
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| PW Intf P. TLV (0x096B) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+For a more detailed look at this field, check out Section 6.4 ("Interface Parameter Sub-TLV") 🧚.
6.2.2.2. PW Group ID TLV 💅
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| PW Group ID TLV (0x096C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The PW Group ID is an arbitrary 32-bit value that stands for an arbitrary group of PWs 🍓. It's used to make group PWs. For example, a PW Group ID can work as a port index and get assigned to every PW that leads to that port 🔌. With the PW Group ID, a PE can send "wildcard" label withdrawals, or "wildcard" status Notification messages, to remote PEs when a physical port fails 💥.
Note Well: The PW Group ID is different from and has no relation to the Attachment Group Identifier. Don't mix them up, bestie! 🙅♀️
The PW Group ID TLV isn't part of the FEC, and it won't be advertised except in the PW FEC advertisement 📣. The advertising PE MAY use the wildcard withdraw semantics, but the remote PEs MUST implement support for wildcard messages 🌟. This TLV MUST only be used when sending the Generalized PWid FEC 🚫.
To send a wildcard command (status or withdraw) 🫶:
- Set the PW Info Length to 0 in the Generalized PWid FEC Element.
- Send only the PW Group ID TLV with the FEC (no AGI/SAII/TAII is sent).
6.2.3. Signaling Procedures ✨
okay so before PE1 can even start signaling PE2, it needs to know PE2's address and a TAI 🧚 this info can be configured by hand, or PE1 can learn it automatically through some auto-discovery procedure. either way, it's giving organized 💅
the egress PE (PE1) is the one that knows about the ingress PE, so PE1 kicks things off by sending a Label Mapping message to PE2. that message carries the FEC TLV with the Generalized PWid FEC Element (type 0x81), and the element holds the AGI, SAII, and TAII info. it's the whole group chat in one message 🫶
when PE2 gets that Label Mapping message, it reads it as a request to set up a PW whose endpoint (on PE2's side) is the Forwarder named by the TAI. how PE2 maps AIs to Forwarders is totally a local decision, so the signaling protocol doesn't care about it 🤷♀️ in some VPWS setups, the TAI might be a string naming a specific Attachment Circuit, like "ATM3VPI4VCI5", or it might be something like "Fred" that's tied to an Attachment Circuit through configuration. in VPLS, the AGI could be a VPN-id that picks out one VPLS instance 🌈
if PE2 can't map the TAI to any of its Forwarders, it sends a Label Release message back to PE1 with a Status Code of "Unassigned/Unrecognized TAI", and that's the end of processing for that Label Mapping message 💀
the FEC TLV in that Label Release is the same FEC TLV that came in with the Label Mapping message being released, minus the interface parameter TLV. the FEC TLV stays the same across all LDP messages for the same PW, so in a Label Release, the SAII is the remote peer's AII and the TAII is the sender's local AII 🦋
if the Label Mapping message has a valid TAI, PE2 still has to decide whether it wants to accept it. how it decides depends on what kind of Forwarder the TAI points to. the Label Mapping message can also get rejected for the usual LDP error conditions, which are detailed in [RFC5036] 🙈
if PE2 accepts the Label Mapping message, it needs to make sure a PW LSP gets set up in the other direction (PE1-->PE2). if it's already signaled for that PW LSP in that direction, there's nothing more to do ✨ otherwise, it has to start that signaling by sending a Label Mapping message to PE1. it's basically the same message PE2 just got, except the SAI and TAI are swapped 🔁
so a bidirectional PW is really two LSPs, and the FEC for one has its SAII and TAII reversed compared to the FEC for the other. two LSPs, one vibe 💜
6.3. Signaling of Pseudowire Status 🎀
6.3.1. Use of Label Mapping Messages
the PEs MUST send Label Mapping messages to their peers as soon as the PW is configured and administratively enabled, no matter what state the Attachment Circuit is in 💖 the PW label should not be withdrawn unless the operator administratively brings the pseudowire down (or the PW configuration gets deleted entirely). using the procedures in this section, a simple label withdraw method MAY also be supported as a legacy way of signaling PW status and AC status 🕰️ either way, if the label-to-PW binding isn't available, the PW MUST be considered to be in the down state 🌸
once the PW status negotiation procedures are done, if they end up choosing the label withdraw method for PW status communication, and one of the PEs doesn't support that method, then that PE must send a Label Release message to its peer with this error:
"Label Withdraw PW Status Method Not Supported"
if the label withdraw method is selected for the PW, the Label Mapping message only gets advertised while the Attachment Circuit is active ✨ the PW status signaling procedures in this section MUST be fully implemented 👑
6.3.2. Signaling PW Status
the PE devices use an LDP TLV to tell their remote peers about status. this PW Status TLV holds way more info than the simpler Label Withdraw message does 💅
the format of the PW Status TLV is:
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| PW Status (0x096A) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Status Code is a 4-octet bit field, as specified in "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)" [RFC4446]. the Length field tells you the length of the Status Code field in octets, which is 4 📏
each bit in the Status Code field can be set on its own, so more than one failure can be flagged at the same time 🚨 every fault gets cleared by sending an appropriate Notification message where that bit is cleared. the lowest bit (PW Not Forwarding) is only a generic failure signal for when there's a link-down event that none of the other bits cover 🌧️
the Status TLV gets carried to the remote PW peer inside an LDP Notification message, as described in [RFC5036]. here's how the Notification message for PW Status is laid out:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWid FEC TLV or Generalized ID FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Group ID TLV (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Status TLV status code is set to 0x00000028, "PW status", to say that PW status is coming 📣 this notification isn't tied to any particular message, so the Message ID field is set to 0 🙃
the PW FEC TLV SHOULD NOT include the Interface Parameter Sub-TLVs, because they're ignored in this message. the PW FEC TLV MUST include the C-bit, where it applies, since the C-bit is part of the FEC 🎀 when a PE's Attachment Circuit runs into an error, the PW Notification message lets the PE send one "wildcard" status message. it uses a PW FEC TLV with only the Group ID set to flag the change for every affected PW connection at once 🌈 that status message either holds the PW FEC TLV with only the Group ID set, or the Generalized FEC TLV with only the PW Group ID TLV.
like we said earlier, the Group ID field of the PWid FEC Element, or the PW Group ID TLV used with the Generalized PWid FEC Element, can send a status notification for any arbitrary set of PWs 🧠 this procedure is OPTIONAL, and if you implement it, the LDP Notification message should look like this: if the PWid FEC Element is used, the PW information length field is set to 0, the PW ID field isn't there, and the Interface Parameter Sub-TLVs aren't there either. if the Generalized FEC Element is used, the AGI, SAII, and TAII aren't there, the PW information length field is set to 0, the PW Group ID TLV is included, and the PW Interface Parameters TLV is left out 🫧 for this document, we're calling this the "wildcard PW status notification procedure". all PEs that implement this design are REQUIRED to accept such a Notification message, but they're not required to send one 💜
6.3.3. Pseudowire Status Negotiation Procedures
when a PW is first set up, the PEs MUST attempt to negotiate use of the PW Status TLV 🤝 here's how that goes: a PE that supports the PW Status TLV MUST include it in the initial Label Mapping message, right after the PW FEC and the Interface Parameter Sub-TLVs. the PW Status TLV then gets used for the whole lifetime of the pseudowire 💖 here's the diagram:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ PWid FEC or Generalized PWid FEC +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Parameters |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Generic Label (0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW Status (0x096A) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+plot twist 😭 if the initial Label Mapping message for a PW includes a PW Status TLV, but the Label Mapping message from the remote PE doesn't have one, or the remote PE doesn't support the PW Status TLV, the PW falls back to the label withdraw method for signaling PW status. and if the remote peer doesn't support the PW Status TLV, it just ignores it automatically, because the I (ignore) bit is set in the TLV 🫠 so the PW Status TLV won't show up in the matching FEC advertisement from the remote LDP peer, and that's exactly what causes the behavior above.
if the PW Status TLV isn't present right after the FEC TLV in the initial PW Label Mapping message a PE receives, the PW Status TLV won't be used at all. both PEs supporting the pseudowire then fall back to the label withdraw procedure for signaling status changes 🔄
if negotiation ends up using the PW Status TLV, then the actual PW status comes from the PW Status TLV that was sent in the initial PW Label Mapping message. after that, any updates to PW status are carried over the Notification message ✨🦋
6.4. Interface Parameter Sub-TLV ✨
okay so this field is where the interface-specific details live 💅 When it applies, it MUST be used to check that the PEs and the ingress and egress ports at the edges of the circuit actually have the capabilities to work together 🫶 Here's the layout:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Length field counts the whole interface parameter, including the Sub-TLV Type and Length fields themselves 🎀 If you run into unknown interface parameters, keep going! They MUST be silently ignored 🙈
The Interface Parameter Sub-TLV Type values are specified in "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)" [RFC4446].
- Interface MTU sub-TLV type 📏
This one is a 2-octet value giving the MTU in octets. It's the Maximum Transmission Unit, excluding encapsulation overhead, of the egress packet interface that will transmit the decapsulated PDU received from the MPLS-enabled network. It only applies to PWs transporting packets and is REQUIRED for those PW types. If this parameter doesn't match in both directions of a specific PW, that PW MUST NOT be enabled 🚫
- Optional Interface Description string sub-TLV type 🌸
This one is an arbitrary, OPTIONAL interface description string used to send a human-readable admin note about the interface to the remote PE. It's OPTIONAL and works for all PW types. The length is variable, anywhere from 0 to 80 octets. Human-readable text MUST be provided in the UTF-8 charset using the Default Language [RFC2277] 💜
6.5. LDP Label Withdrawal Procedures 🧹
As mentioned above, the Group ID field of the PWid FEC Element, or the PW Group ID TLV used with the Generalized PWid FEC Element, can be used to withdraw all PW labels associated with a particular PW group. This procedure is OPTIONAL. If you implement it, the LDP Label Withdraw message should look like this: when the PWid FEC Element is used, the PW information length field is set to 0, the PW ID field isn't present, the Interface Parameter Sub-TLVs aren't present, and the Label TLV isn't present. When the Generalized FEC Element is used, the AGI, SAII, and TAII aren't present, the PW information length field is set to 0, the PW Group ID TLV is included, the PW Interface Parameters TLV isn't present, and the Label TLV isn't present. For this document, this is called the "wildcard withdraw procedure". All PEs implementing this design are REQUIRED to accept such withdraw messages, but they aren't required to send them 🥹 Also, the PW Group ID TLV only applies to PWs using the Generalized ID FEC Element, while the Group ID only applies to the PWid FEC Element.
The Interface Parameter Sub-TLVs, or TLV, MUST NOT be present in any LDP PW Label Withdraw or Label Release message. A wildcard Label Release message MUST include only the Group ID or PW Group ID TLV. A Label Release message initiated by a PE router must always include the PW ID 🎯
7. Control Word 🍓
7.1. PW Types for Which the Control Word Is REQUIRED 🔒
The Label Mapping messages sent to set up these PWs MUST have C=1. If a Label Mapping message for one of these types arrives with C=0, a Label Release message MUST be sent, with an "Illegal C-bit" status code. In that case, the PW will not be enabled ❌
7.2. PW Types for Which the Control Word Is NOT Mandatory 🤷♀️
If a system can send and receive the control word on PW types where it isn't mandatory, then each PW endpoint MUST be configurable with a parameter that says whether using the control word is PREFERRED or NOT PREFERRED. Every PW MUST have a default value for this parameter. This specification does NOT state what that default value should be 🤐
If a system is NOT capable of sending and receiving the control word on PW types where it isn't mandatory, it behaves exactly as if it were configured for the control word to be NOT PREFERRED ✨
If a Label Mapping message for the PW has already been received but no Label Mapping message for the PW has been sent yet, here's the procedure:
- i. If the received Label Mapping message has C=0, send a Label Mapping message with C=0. The control word is not used.
- ii. If the received Label Mapping message has C=1, and the PW is locally configured so the control word is preferred, send a Label Mapping message with C=1. The control word is used.
- iii. If the received Label Mapping message has C=1, and the PW is locally configured so the control word is not preferred or the control word isn't supported, act as if no Label Mapping message for the PW had been received (so keep reading the next paragraph).
If a Label Mapping message for the PW hasn't already been received (or the received one had C=1 and either local configuration says the control word is not preferred or it isn't supported), send a Label Mapping message where the C-bit matches the locally configured preference for the control word. In other words, set C=1 if you're locally configured to prefer the control word, and set C=0 if you're locally configured to prefer not using it, or if the control word isn't supported 💅
What happens next depends on the next control message received for that PW:
- i. A Label Mapping message with the same C-bit value as the Label Mapping message that was sent. PW setup is now complete, and the control word is used if C=1 but not used if C=0 🎉
- ii. A Label Mapping message with C=1, when the Label Mapping message that was sent had C=0. In this case, ignore the received Label Mapping message and keep waiting for the next control message for the PW.
- iii. A Label Mapping message with C=0, when the Label Mapping message that was sent had C=1. In this case, send a Label Withdraw message with a "Wrong C-bit" status code, followed by a Label Mapping message that has C=0. PW setup is now complete, and the control word is not used.
- iv. A Label Withdraw message with the "Wrong C-bit" status code. Treat it as a normal Label Withdraw message, but don't respond. Keep waiting for the next control message for the PW.
If a corresponding Label Withdraw or Release arrives at any point after a Label Mapping message has been received, the action taken is the same as for any Label Withdraw or Release messages that might be received at any time.
If both endpoints prefer the control word, this procedure will make sure it gets used. If either endpoint prefers not to use it, or doesn't support it, this procedure will make sure it isn't used. If one endpoint prefers the control word but the other doesn't, the one that prefers not to use it has no extra protocol to run. It just waits for a Label Mapping message with C=0 💖
7.3. Control-Word Renegotiation by Label Request Message 🔁
It's possible that after the PW C-bit negotiation procedure above is done, the local PE gets re-provisioned with a different control word preference. So once the control-word negotiation is complete, the procedure can be restarted like this:
- i. If the local PE previously sent a Label Mapping message, it MUST send a Label Withdraw message to the remote PE and wait until it has received a Label Release message from the remote PE.
- ii. The local PE MUST send a Label Release message to the remote PE for the specific label associated with the FEC that was advertised for this specific PW. Note: the Label Release and Label Withdraw steps above aren't required to happen in any specific sequence.
- iii. The local PE MUST send a Label Request message to the peer PE, and then MUST wait until it receives a Label Mapping message containing the remote PE's currently configured preference for the control word.
Once the remote PE has successfully processed the Label Withdraw and Label Release messages, it resets the C-bit negotiation state machine and its use of the control word to the locally configured preference 🔄
From this point on, the local and remote PEs follow the C-bit negotiation procedures from the previous section.
The C-bit renegotiation process above SHOULD NOT be interrupted until it's completed, or unpredictable results might occur 😬
7.4. Sequencing Considerations 🔢
When the router considers the sequence number field in the control word, it's important to keep the following details in mind when advertising labels 📝
7.4.1. Label Advertisements 🏷️
After a label has been withdrawn by the output router and/or released by the input router, care must be taken not to advertise (reuse) the same released label until the output router can be reasonably certain that old packets containing the released label no longer persist in the MPLS-enabled network ⏳
This precaution is required to stop the imposition router from restarting packet forwarding with a sequence number of 1 when it receives a Label Mapping message that binds the same FEC to the same label, if there are still older packets in the network with a sequence number between 1 and 32768. For example, if a packet with sequence number=n, where n is in the interval [1,32768], is traveling through the network, the disposition router could receive that packet after it re-advertises the label. Since the imposition router released the label, the disposition router SHOULD be expecting the next packet to arrive with a sequence number of 1. Receiving a packet with a sequence number equal to n could cause n packets to be potentially rejected by the disposition router, until the imposition router imposes a sequence number of n+1 into a packet 😭 Possible ways to avoid this are for the disposition router to always advertise a different PW label, or for the disposition router to wait a sufficient time before re-advertising a recently released label. This is only an issue when sequence number processing is enabled at the disposition router 🫶
7.4.2. Label Release 🫶
okay so, bestie, this one's about restarting. If the imposition router wants to start forwarding packets again with sequence number 1 🔄, it has two moves. First it sends a Label Release message to the disposition router, then it sends a Label Request message to that same router 💅. Clean restart, iconic.
Here's the important bit 👑: when sequencing is supported, any PW label advertised in response to a Label Request message MUST also consider the issues from Section 7.4.1 ("Label Advertisements") 🎀. no cap, that's not optional.
8. IANA Considerations 📋✨
8.1. LDP TLV TYPE 🎀
this doc adds several new LDP TLV types 💖. IANA already keeps a registry called "TLV Type Name Space", which RFC 5036 defines, and these values were assigned out of it:
TLV Type Description
=====================================
0x096A PW Status TLV
0x096B PW Interface Parameters TLV
0x096C PW Group ID TLV8.2. LDP Status Codes 🚦
same energy here, but for status codes. This doc adds several new LDP status codes, and IANA already maintains a registry titled "Status Code Name Space" (defined by RFC 5036) for them. These are the values that got assigned:
Range/Value E Description Reference
------------- ----- ---------------------- ---------
0x00000024 0 Illegal C-Bit [RFC8077]
0x00000025 0 Wrong C-Bit [RFC8077]
0x00000026 0 Incompatible bit-rate [RFC8077]
0x00000027 0 CEP-TDM mis-configuration [RFC8077]
0x00000028 0 PW Status [RFC8077]
0x00000029 0 Unassigned/Unrecognized TAI [RFC8077]
0x0000002A 0 Generic Misconfiguration Error [RFC8077]
0x0000002B 0 Label Withdraw PW Status [RFC8077]
Method Not Supported8.3. FEC Type Name Space 🧚
two new FEC element types, 0x80 and 0x81, come from the registry "Forwarding Equivalence Class (FEC) Type Name Space" for the Label Distribution Protocol (LDP) [RFC5036]. lowkey simple, but it matters ✨.
9. Security Considerations 🔐
okay, security time, and I'm not playing around 😭. This document specifies the LDP extensions needed to set up and maintain pseudowires. The whole point of pseudowires is to let Layer 2 frames get encapsulated in MPLS and carried from one end of a pseudowire to the other. So we have to think about security for both the data plane and the control plane 🛡️.
9.1. Data-Plane Security 🌸
for the data plane, these areas must be considered:
- MPLS PDU inspection
- MPLS PDU spoofing
- MPLS PDU alteration
- MPLS PSN protocol security
- Access Circuit security
- Denial-of-service prevention on the PE routers
okay so the expectation is that an MPLS PSN carrying pseudowire service should be at least as secure as the Layer 2 native networks it's imitating. That's the vibe people expect 💅. This means the MPLS-enabled network SHOULD be isolated from outside packet insertion, in such a way that it SHOULD NOT be possible to insert an MPLS packet into the network directly. To stop unwanted packet insertion, you also have to stop unauthorized physical access to the PSN, plus unauthorized administrative access to individual network elements 🚨.
As we said above, an MPLS-enabled network should not accept MPLS packets from its external interfaces (i.e., interfaces to CE devices or to other providers' networks) unless the top label of the packet was legitimately distributed to the system the packet is arriving from 🙅♀️. If the packet's incoming interface leads to a different Service Provider (SP) rather than a customer, there must also be an appropriate trust relationship, including trust that the other SP also has appropriate security measures in place 🤝.
The three main security problems with using an MPLS-enabled network to carry PWs are spoofing, alteration, and inspection 😱. First, the PE receiving PW PDUs might get a PDU that looks like it came from the PE sending the PW into the PSN, but the sending PE didn't actually transmit it. (The specified encapsulations don't by themselves let the decapsulator authenticate the encapsulator.) Second, the PW PDU could get altered between entering the PSN and leaving it. (The specified encapsulations don't by themselves assure the decapsulator of the packet's integrity.) Third, someone could see the PDU's contents while it's in transit through the PSN. (The specification encapsulations don't ensure privacy.) How much these issues matter in practice depends on the security requirements of the applications whose traffic goes through the tunnel, and on how secure the PSN itself is 🫶.
9.2. Control-Plane Security 🔒
general security considerations for LDP are in Section 5 of [RFC5036], and they also apply when LDP is used to set up pseudowires 💜.
A pseudowire connects two Attachment Circuits, so it's really important that LDP connections aren't accepted from just anywhere 🙈. Otherwise a local Attachment Circuit might end up connected to some random remote Attachment Circuit. So an incoming LDP session request MUST NOT be accepted unless its IP source address is known to be the source of an "eligible" LDP peer. The eligible set could be preconfigured (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. (Obviously, if the auto-discovery protocol isn't trusted, the eligible peers it produces can't be trusted either.)
Even if an LDP connection request looks like it's coming from an eligible peer, its source address might 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 source address spoofing 🧱.
The LDP MD5 authentication key option, described in Section 2.9 of [RFC5036], MUST be implemented, and for a greater degree of security, it must be used 🔑. This gives integrity and authentication for LDP messages and rules out source address spoofing. The MD5 option doesn't provide privacy, but privacy of LDP control messages usually isn't considered important. Because the MD5 option relies on pre-shared keys that get configured, it doesn't offer much protection against replay attacks. Also, that reliance on pre-shared keys may make it very difficult to deploy when the eligible neighbors are determined by an auto-configuration protocol 😩.
When the Generalized PWid FEC Element is used, a particular LDP peer might be one of the eligible LDP peers but still not be the right one to connect to the particular Attachment Circuit identified by that instance of the Generalized PWid FEC Element. But since the peer is known to be one of the eligible peers (as discussed above), that would be a configuration error rather than a security problem 🛠️. Still, it may be a good idea for a PE to associate each of its local Attachment Circuits with its own set of eligible peers, rather than having just one set of eligible peers for the PE as a whole 🌈.
10. Interoperability and Deployment 🤝✨
Section 2.2 of [RFC6410] lists four requirements an Internet Standard must meet. This section covers how this document meets those requirements 📝.
pseudowire tech was first deployed in 2001 and has been widely adopted by lots of carriers 🎉. [RFC7079] reports on a survey of PW implementations, with a special focus on control-word usage. [EANTC] describes a public multi-vendor interoperability test of MPLS and Carrier Ethernet equipment, which included testing Ethernet, ATM, and TDM pseudowires 🦋.
The errata against [RFC4447] are mostly editorial, and this document addresses them 💅.
Every feature in this specification has been implemented by multiple vendors 👑.
No IPR disclosures have been made to the IETF related to this document, to RFCs 4447 or 6723, or to the Internet-Drafts that became RFCs 4447 and 6723 🙌.
11. References 📚
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<http://www.rfc-editor.org/info/rfc3032>.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, DOI
10.17487/RFC4446, April 2006,
<http://www.rfc-editor.org/info/rfc4446>.
[RFC7358] Raza, K., Boutros, S., Martini, L., and N. Leymann, "Label
Advertisement Discipline for LDP Forwarding Equivalence
Classes (FECs)", RFC 7358, DOI 10.17487/RFC7358, October
2014, <http://www.rfc-editor.org/info/rfc7358>.11.2. Informative References 📚✨
Okay bestie, these are the informative references, the extra reading that gives the spec its backstory 🧠💅. Here's the full list:
- [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, DOI
10.17487/RFC2277, January 1998,<http://www.rfc-editor.org/info/rfc2277>. - [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI
10.17487/RFC3985, March 2005,<http://www.rfc-editor.org/info/rfc3985>. - [RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC 4842, DOI
10.17487/RFC4842, April 2007,<http://www.rfc-editor.org/info/rfc4842>. - [RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, DOI
10.17487/RFC4553, June 2006,<http://www.rfc-editor.org/info/rfc4553>. - [RFC4619] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, DOI
10.17487/RFC4619, September 2006,<http://www.rfc-editor.org/info/rfc4619>. - [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, DOI
10.17487/RFC4717, December 2006,<http://www.rfc-editor.org/info/rfc4717>. - [RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, DOI
10.17487/RFC4618, September 2006,<http://www.rfc-editor.org/info/rfc4618>. - [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI
10.17487/RFC4448, April 2006,<http://www.rfc-editor.org/info/rfc4448>. - [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, DOI
10.17487/RFC4447, April 2006,<http://www.rfc-editor.org/info/rfc4447>. - [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, DOI
10.17487/RFC6410, October 2011,<http://www.rfc-editor.org/info/rfc6410>. - [RFC6723] Jin, L., Ed., Key, R., Ed., Delord, S., Nadeau, T., and S. Boutros, "Update of the Pseudowire Control-Word Negotiation Mechanism", RFC 6723, DOI
10.17487/RFC6723, September 2012,<http://www.rfc-editor.org/info/rfc6723>. - [RFC7079] Del Regno, N., Ed., and A. Malis, Ed., "The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results", RFC 7079, DOI
10.17487/RFC7079, November 2013,<http://www.rfc-editor.org/info/rfc7079>. - [ANSI] American National Standards Institute, "Telecommunications - Synchronous Optical Network (SONET) - Basic Description Including Multiplex Structures, Rates, and Formats", ANSI T1.105, October 1995.
- [ITUG] International Telecommunications Union, "Network node interface for the synchronous digital hierarchy (SDH)", ITU-T Recommendation G.707, May 1996.
- [EANTC] European Advanced Networking Test Center, "MPLS and Carrier Ethernet: Service - Connect - Transport. Public Multi-Vendor Interoperability Test", February 2009.
Acknowledgments 🫶💖
The authors gave a huge shoutout to Vach Kompella, Vanson Lim, Wei Luo, Himanshu Shah, and Nick Weeds 🙌. They also wanted to thank the authors of RFC 6723, whose work got folded right into this document: Lizhong Jin, Raymond Key, Simon Delord, Tom Nadeau, and Sami Boutros ✨.
Contributors 🌸
The following people were either authors or contributing authors for RFC 4447. They're listed here to celebrate their work on that document 💜.
Nasser El-Aawar
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO 80021
United States of America
Email: nna@level3.netEric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
United States of America
Email: erosen@cisco.comDan Tappan
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
United States of America
Email: tappan@cisco.comToby Smith
Google
6425 Penn Ave. #700
Pittsburgh, PA 15206
United States of America
Email: tob@google.comDimitri Vlachos
Riverbed Technology
Email: dimitri@riverbed.comJayakumar Jayakumar
Cisco Systems Inc.
3800 Zanker Road, MS-SJ02/2
San Jose, CA 95134
United States of America
Email: jjayakum@cisco.comAlex Hamilton,
Cisco Systems Inc.
485 East Tasman Drive, MS-SJC07/3
San Jose, CA 95134
United States of America
Email: tahamilt@cisco.comSteve Vogelsang
ECI Telecom
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205
United States of America
Email: stephen.vogelsang@ecitele.comJohn Shirron
ECI Telecom
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205
United States of America
Email: john.shirron@ecitele.comAndrew G. Malis
Verizon
60 Sylvan Rd.
Waltham, MA 02451
United States of America
Email: andrew.g.malis@verizon.comVinai Sirkay
Reliance Infocomm
Dhirubai Ambani Knowledge City
Navi Mumbai 400 709
India
Email: vinai@sirkay.comVasile Radoaca
Nortel Networks
600 Technology Park
Billerica MA 01821
United States of America
Email: vasile@nortelnetworks.comChris Liljenstolpe
149 Santa Monica Way
San Francisco, CA 94127
United States of America
Email: ietf@cdl.asgaard.orgDave Cooper
Global Crossing
960 Hamlin Court
Sunnyvale, CA 94089
United States of America
Email: dcooper@gblx.netKireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
United States of America
Email: kireeti@juniper.netAuthors' Addresses 🦋🎀
Here's where you can find the editors 💅.
Luca Martini (editor)
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO 80202
United States of America
Email: lmartini@monoski.comGiles Heron (editor)
Cisco Systems
10 New Square
Bedfont Lakes
Feltham
Middlesex
TW14 8HA
United Kingdom
Email: giheron@cisco.com📦 where this page comes from
- ietf: rfc8077 2017-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms