RFC 4447
Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)
Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) 🎀
- RFC: 4447
- Authors: L. Martini, Ed. (Cisco Systems, Inc.), E. Rosen (Cisco Systems, Inc.), N. El-Aawar (Level 3 Communications, LLC.), T. Smith (Network Appliance, Inc.), G. Heron (Tellabs)
- Category: Standards Track 💖
- Date: April 2006 🌸
- Network Working Group 🧚
Status of This Memo ✨
okay so this document is a standards track protocol spec for the whole Internet community, and it's basically asking everyone for feedback and suggestions 🫶 For where this protocol stands officially, go check the current "Internet Official Protocol Standards" (STD 1). And the good news is that distribution of this memo is unlimited 🦋
Copyright Notice 💜
Copyright (C) The Internet Society (2006).
Abstract 🌈
okay so picture this: Layer 2 services like Frame Relay, Asynchronous Transfer Mode, and Ethernet can be "emulated" over an MPLS backbone 🔥 You do it by wrapping up the Layer 2 Protocol Data Units (PDU) and sending them along "pseudowires". Pseudowires can also do low-rate Time Division Multiplexed circuit emulation and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network, so it's giving versatile 👑
This document defines a protocol for setting up and maintaining those pseudowires, and it does it by extending the Label Distribution Protocol (LDP) ✨ The procedures for actually encapsulating Layer 2 PDUs live in a set of companion documents, so you'll want to read those too 🍓
Table of Contents 🗂️
1. Introduction ....................................................3
2. Specification of Requirements ...................................5
3. The Pseudowire Label ............................................5
4. Details Specific to Particular Emulated Services ................7
4.1. IP Layer 2 Transport .......................................7
5. LDP .............................................................7
5.1. LDP Extensions .............................................8
5.2. The PWid FEC Element .......................................8
5.3. The Generalized PWid FEC Element ..........................10
5.3.1. Attachment Identifiers .............................11
5.3.2. Encoding the Generalized ID FEC Element ............13
5.3.2.1. Interface Parameters TLV ..................14
5.3.2.2. PW Grouping TLV ...........................14
5.3.3. Signaling Procedures ...............................15
5.4. Signaling of Pseudowire Status ............................16
5.4.1. Use of Label Mappings Messages .....................16
5.4.2. Signaling PW Status ................................17
5.4.3. Pseudowire Status Negotiation Procedures ...........18
5.5. Interface Parameters Sub-TLV ..............................19
6. Control Word ...................................................20
6.1. PW Types for Which the Control Word is REQUIRED ...........20
6.2. PW Types for Which the Control Word is NOT Mandatory ......21
6.3. LDP Label Withdrawal Procedures ...........................22
6.4. Sequencing Considerations .................................23
6.4.1. Label Advertisements ...............................23
6.4.2. Label Release ......................................24
7. IANA Considerations ............................................24
7.1. LDP TLV TYPE ..............................................24
7.2. LDP Status Codes ..........................................24
7.3. FEC Type Name Space .......................................25
8. Security Considerations ........................................25
8.1. Data-Plane Security .......................................25
8.2. Control-Plane Security ....................................26
9. Acknowledgements ...............................................27
10. Normative References ..........................................27
11. Informative References ........................................27
12. Additional Contributing Authors ...............................28
Appendix A. C-bit Handling Procedures Diagram .....................311. Introduction 🦋
okay so [FRAME], [ATM], [PPPHDLC], and [ETH] explain how to encapsulate a Layer 2 Protocol Data Unit (PDU) so it can travel over an MPLS-enabled network 💅 Those documents say you prepend a "pseudowire header" made of a demultiplexor field to the encapsulated PDU. The demultiplexor gets prepended before a packet is sent on a pseudowire, and when the packet shows up at the far end, the demultiplexor is what lets the receiver figure out which pseudowire it came in on 🧚 If the packet needs to get from one pseudowire endpoint to the other, it may have to go through a "Packet Switched Network (PSN) tunnel", and that means an extra header gets prepended too ✨
Next up, [CEP, SAToP] are the accompanying docs that cover moving time-division multiplexing (TDM) digital signals, aka TDM circuit emulation, over a packet-oriented MPLS-enabled network 🔥 The circuit-oriented TDM transmission system is the Synchronous Optical Network (SONET)[SDH]/Synchronous Digital Hierarchy (SDH) [ITUG] 💜 TDM traffic covers voice, data, and private leased-line service, so the pseudowires have to emulate the circuit characteristics of SONET/SDH payloads 😭 The TDM signals and payloads get encapsulated for pseudowire transport, and a pseudowire demultiplexor plus a PSN tunnel header gets prepended to that encapsulation 🌸
[SAToP] covers low-rate time-division multiplexing (TDM) digital signals (TDM circuit emulation) over PSNs, and [CEP] covers high-rate TDM (SONET/SDH) 🎀 For TDM traffic, the pseudowires must emulate the circuit characteristics of the original T1, E1, T3, E3, SONET, or SDH signals 👑 [SAToP] does this by encapsulating an arbitrary but constant amount of TDM data in each packet, and the other methods encapsulate TDM structures instead 🍓
In this document, we use the MPLS Label Distribution Protocol, LDP [RFC3036], to set up and maintain the pseudowires ✨ We define new TLVs, FEC elements, parameters, and codes for LDP so it can identify pseudowires and signal their attributes 💖 We also spell out how a pseudowire endpoint uses those TLVs to bind a demultiplexor field value to a pseudowire, and how it tells the remote endpoint about that binding 🫶 Plus we cover reporting pseudowire status changes, passing along extra pseudowire info when needed, and releasing the bindings 🦋
In the protocol described here, the pseudowire demultiplexor field is an MPLS label, so the packets sent from one end of the pseudowire to the other are MPLS packets, which must be transmitted through an MPLS tunnel 🌈 The exception is if the pseudowire endpoints are immediately adjacent and penultimate hop popping behavior is in use, because then the MPLS tunnel may not be necessary 🙈 Any sort of PSN tunnel works, as long as it can carry MPLS packets, and that includes an MPLS LSP or any other tunnel that can carry MPLS packets 💅 Setting up and maintaining those MPLS tunnels is outside the scope of this document 🧚
This document only deals with setup and maintenance of point-to-point pseudowires. Point-to-multipoint and multipoint-to-point pseudowires aren't discussed at all 🙅♀️
QoS-related issues are not discussed in this document 💀 The following two figures show the reference models derived from [RFC3985] that support the PW emulated services 👑
|<-------------- 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 service
Figure 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 ModelFor the purposes of this document, PE1 is the ingress router and PE2 is the egress router 🫶 A layer 2 PDU arrives at PE1 and gets encapsulated there, then it's transported and decapsulated at PE2, and transmitted out of PE2 💖
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] 🎀
3. The Pseudowire Label ✨
okay so picture this: you want to send Layer 2 PDUs from ingress LSR PE1 to egress LSR PE2, and the only thing in the middle is an MPLS-enabled network 🦋. We assume there's an MPLS tunnel from PE1 to PE2. That means PE1 can get a packet 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 adding the tunnel encapsulation is just pushing on an MPLS label. easy peasy 💅
we also assume a ton of pseudowires can ride through one MPLS tunnel 🌈 which means the network core never has to keep state for each individual pseudowire. iconic, right? but we don't assume the MPLS tunnels are point to point. the pseudowires are point to point, but the tunnels can be multipoint to point. and we don't assume PE2 can even tell which MPLS tunnel a received packet came through 🙈
(for example, if the MPLS tunnel is an LSP and penultimate hop popping is used, the packet shows up at PE2 with no info about the tunnel at all. wild, I know 💀)
when PE2 gets a packet over a pseudowire, it has to figure out two things: that the packet really did come over a pseudowire, and which pseudowire it belongs to 🎀 it does this by looking at the MPLS label in the pseudowire demultiplexor field shown in Figure 2. we're calling that the "PW label" 🫶
when PE1 sends a Layer 2 PDU to PE2, it makes 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 hits PE2, and PE2 decides what to do with the packet based on that PW label. the whole vibe is "trust the PW label" 👑
if the payload is, say, an ATM AAL5 PDU, the PW label usually matches one specific ATM VC at PE2. so PE2 needs to be able to work out from the PW label the outgoing interface and the VPI/VCI value for that AAL5 PDU 🦋 if the payload is a Frame Relay PDU, PE2 needs to work out the outgoing interface and the DLCI value from the PW label 🌸 and if it's an Ethernet frame, PE2 needs the outgoing interface and maybe the VLAN identifier 💜
this whole thing is one-way, and it gets repeated on its own for bi-directional operation 🔁 now here's the important bit: the same PW ID and PW type REQUIRED to be assigned for a given circuit in both directions. the group ID (more on that below) MUST NOT be required to match in both directions. the transported frame MAY get modified when it reaches the egress router. and if the header of the transported Layer 2 frame does get modified, that MUST happen at the egress LSR only 🔥 also, 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. no notes, bestie 🫶
this document doesn't say how to distribute the MPLS tunnel label or any other labels that might sit above the PW label on the stack. literally any acceptable MPLS label distribution method will do 🧚 what this document does specify is a protocol for assigning and distributing the PW label. that protocol is LDP, extended the way the rest of this document describes. an LDP session has to be set up between the pseudowire endpoints. LDP MUST be used in its "downstream unsolicited" mode. and LDP's "liberal label retention" mode SHOULD be used 💖
static assignment of PW labels is also allowed as an option, and implementations of this protocol SHOULD support static assignment 🍓
this document covers everything 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 💅 there are also protocol mechanisms in here that could 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 🌈
4. Details Specific to Particular Emulated Services ✨
4.1. IP Layer 2 Transport
this mode carries IP packets over a pseudowire 🦋 the encapsulation follows [RFC3032]. the PW control word MAY be inserted between the MPLS label stack and the IP payload 💜 how the 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 🌸
5. LDP 💖
the PW label bindings are distributed using the LDP downstream unsolicited mode described in [RFC3036] 🫶 the PEs will set up an LDP session using the Extended Discovery mechanism described in [LDP, sections 2.4.2 and 2.5].
an LDP Label Mapping message has an FEC TLV, a Label TLV, and zero or more optional parameter TLVs 🎀
the FEC TLV is what tells you what the label means 👑 here, the FEC TLV is used to identify the particular pseudowire that a particular label is bound to. this spec defines two new FEC TLVs for identifying pseudowires. when you set up a pseudowire, only one of those FEC TLVs gets used. which one depends on the service being emulated and the provisioning model being supported ✨
LDP lets each FEC TLV hold a set of FEC elements. but for setting up and maintaining pseudowires, each FEC TLV MUST contain exactly one FEC element 🔥
the LDP base spec has several kinds of label TLVs, including the Generic Label TLV, as specified in [RFC3036], section 3.4.2.1. for setting up and maintaining pseudowires, the Generic Label TLV MUST be used 💅
5.1. LDP Extensions
this document specifies no new LDP messages 🙈 it does specify these new TLVs for use with LDP:
TLV Specified in Section Defined for Message
===================================================================
PW Status TLV 5.4.2 Notification
PW Interface Parameters TLV 5.3.2.1 FEC
PW Grouping ID TLV 5.3.2.2 FECthere are also some new FEC element types:
FEC Element Type Specified in Section Defined for Message
===================================================================
0x80 5.2 FEC
0x81 5.3 FECand these new LDP error codes:
Status Code Specified in Section
====================================================================
"Illegal C-Bit" 6.1
"Wrong C-Bit" 6.2
"Incompatible bit-rate" [CEP]
"CEP/TDM mis-configuration" [CEP]
"PW status" 5.4.2
"Unassigned/Unrecognized TAI" 5.3.3
"Generic Misconfiguration Error" [SAToP]
"Label Withdraw PW Status Method Not Supported" 5.4.15.2. The PWid FEC Element 🎀
the PWid FEC element can be used whenever both pseudowire endpoints have been provisioned with the same 32-bit identifier for the pseudowire 🦋
so this is a brand new FEC element type 💜 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 🧚
- PW type: a 15-bit quantity with a value that represents the type of PW. the assigned values are listed in "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)" [IANA] 🌈
- Control word bit (C): this bit flags whether a control word is there:
C = 1 Control word present on this PW.
C = 0 No control word present on this PW.please check the section "C-Bit Handling Procedures" for the full scoop 💅
- PW information length: the length, in octets, of the PW ID field and the interface parameters sub-TLV. if this value is 0, 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 that represents 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 configuration simple, a particular PW ID at ingress could be part of the virtual tunnel for transport to the egress router 🦋
the Group ID is super useful for sending wild card label withdrawals, or PW wild card 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. the PW ID and the PW type MUST be the same at both endpoints 🫶
- Interface Parameter Sub-TLV: a variable-length TLV used to carry interface-specific parameters, such as the attachment circuit MTU 💖
bestie, pay attention here: the interface parameter sub-TLV is part of the FEC, so LDP's rules make it impossible to change the interface parameters once the pseudowire is set up 😭 which means the interface parameters field must not be used to pass information that might change during the life of the pseudowire, like status information. optional parameter TLVs should be used for that instead 🎀
using the PWid FEC, each of the two pseudowire endpoints independently starts setting up 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 💜
5.3. The Generalized PWid FEC Element 🎀
Okay so the PWid FEC can be used if a unique 32-bit value has been assigned to the PW and each endpoint has been set up with that value 🧚 The Generalized PWid FEC needs the PW endpoints to be uniquely identified, with the PW itself identified as a pair of endpoints. Bestie, the endpoint identifiers are also structured so that apps can auto-discover who the remote endpoints are, instead of someone typing them in by hand ✨
The "Generalized PWid FEC Element" is FEC type 0x81 💜
The Generalized PWid FEC Element doesn't have anything that matches the "Group ID" from the PWid FEC element 🙈 Instead, that job goes to a separate optional LDP TLV called the "PW Grouping TLV" (more on that below). The Interface Parameters field from the PWid FEC is also missing, because the optional Interface Parameters TLV takes over its job 💅
5.3.1. Attachment Identifiers
As discussed in [RFC3985], a pseudowire can be thought of as connecting two "forwarders" 🦋 The protocol that sets up a pseudowire has to let the forwarder at one end figure out who the forwarder is at the other end. We call the field the protocol uses for this an "attachment identifier", or "AI" for short. In the PWid FEC, the PWid field is the AI. In this section we define a more general AI that is structured and has variable length, which is so iconic 👑
Every Forwarder in a PE must be associated with an Attachment Identifier (AI), either through configuration or through some algorithm. The Attachment Identifier must be unique within the PE router where the Forwarder lives. The combination <PE router IP address, AI> must be globally unique 🌍
It's super common to treat a group of Forwarders as members of a particular "group", where PWs can only be set up between members of that group 🫶 In those cases it makes sense to identify each Forwarder relative to its group. So an Attachment Identifier ends up made of an Attachment Group Identifier (AGI) plus an Attachment Individual Identifier (AII) 💖
An Attachment Group Identifier can be thought of as a VPN-id, or a VLAN identifier, or 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, so no spoilers here 🙈 Different pseudowire apps and different provisioning models will need different kinds of AGI and AII fields. Whoever writes the spec for each app and/or model must include the rules for building those fields.
As we said before, a (bidirectional) pseudowire is made of a pair of unidirectional LSPs, one in each direction ⭐ If a particular pseudowire connects PE1 with PE2, the PW direction from PE1 to PE2 can be written as:
<PE1, <AGI, AII1>, PE2, <AGI, AII2>>,And the PW direction from PE2 to PE1 can be written as:
<PE2, <AGI, AII2>, PE1, <AGI, AII1>>.Note that the AGI must be the same at both endpoints, but the AII will generally be different at each endpoint 💅 So from the view of one particular PE, each pseudowire has a local one called the "Source AII" and a remote one called the "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, then 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 🧚
The meaning of the SAI and TAI is a local matter at each endpoint 🎀
Two unidirectional LSPs get joined into a single bidirectional pseudowire based on the SAI and the TAI. Each app and/or provisioning model that uses the Generalized ID FEC element must spell out the rules for doing that association 🔥
5.3.2. Encoding the Generalized ID FEC Element
FEC element type 0x81 is used. Here's how the FEC element gets encoded 💜
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 define the AII and AGI type field values 🙈 Picking the type values for a given app is part of that app's spec. IANA has assigned these values using the method defined in the [IANA] document.
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 app 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 ones it's not using ✨
The PW information length field holds the combined length of the SAII, TAII, and AGI, in octets. If this value is 0, then it references all PWs that use the specified grouping ID. In that case, there are no other FEC element fields (AGI, SAII, etc.) present, and no interface parameters TLVs either 💀
Okay, quick heads-up: whether a field counts as AGI, SAII, or TAII depends on where it shows up in the order 👀 The type field tells you which 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 🫶
5.3.2.1. Interface Parameters TLV
This TLV MUST only be used when sending the Generalized PW FEC. It specifies interface-specific parameters. When they apply, the specific parameters MUST be used to check that the PEs and the ingress and egress ports at the edges of the circuit have the capabilities they need to work with each other 💜
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 |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+You can find a more detailed description of this field in the section "Interface Parameters Sub-TLV", below 🌈
5.3.2.2. PW Grouping 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 Grouping ID TLV (0x096C)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The PW Grouping ID is an arbitrary 32-bit value that stands for an arbitrary group of PWs 🧚 It's used to create group PWs. For example, a PW Grouping ID can be used as a port index and assigned to all the PWs that lead to that port 🔌 Using the PW Grouping ID lets you send "wild card" label withdrawals, or "wild card" status notification messages, to remote PEs when a physical port fails 😭
Note Well: The PW Grouping ID is different from, and has no relation to, the Attachment Group Identifier. 🚨
The PW Grouping ID TLV isn't part of the FEC and won't be advertised except in the PW FEC advertisement. The advertising PE MAY use the wild card withdraw semantics, but the remote PEs MUST implement support for wild card messages. This TLV MUST only be used when sending the Generalized PW ID FEC 💅
To issue a wildcard command (status or withdraw):
- Set the PW Info Length to 0 in the Generalized ID FEC Element.
- Send only the PW Grouping ID TLV with the FEC (no AGI/SAII/TAII is sent). 🌸
5.3.3. Signaling Procedures ✨
Okay so, before PE1 can even start signaling PE2, it needs two things: the address of the remote PE2 and a TAI 🧚 PE1 must know both. Somebody could have configured that by hand, or it could have been learned dynamically through some autodiscovery procedure. Either way works, bestie 💖
The egress PE (PE1) is the one that knows about the ingress PE, so PE1 starts the setup by sending a Label Mapping Message to the ingress PE (PE2) 📨 That message has the FEC TLV, carrying the Generalized PWid FEC Element (type 0x81). The Generalized PWid FEC element holds the AGI, SAII, and TAII info. Iconic 💅
When PE2 gets a Label Mapping message like that, it reads it as a request to set up a PW whose endpoint at PE2 is the Forwarder identified by the TAI 🦋 How PE2 maps AIs to Forwarders is a local matter, so from the signaling protocol's point of view, it's PE2's business. In some Virtual Private Wire Services (VPWS) provisioning models, the TAI might be a string that names a particular Attachment Circuit, like "ATM3VPI4VCI5". Or it might be a string like "Fred" that configuration links to a particular Attachment Circuit 🌸 In VPLS, the AGI could be a VPN-id that identifies a particular VPLS instance 👑
If PE2 can't map the TAI to one of its Forwarders, PE2 sends a Label Release message to PE1 with a Status Code of "Unassigned/Unrecognized TAI" 🙈 and that's the end of processing for that Label Mapping message. Not me being rejected 💀
The FEC TLV in a Label Release message is the same as the FEC TLV from the Label Mapping being released, except without the interface parameter TLV. In general, 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 must decide whether to accept it. How it decides depends on the type of Forwarder that the TAI points to 🔥 And of course, the Label Mapping message can still get rejected because of the standard LDP error conditions detailed in [RFC3036].
If PE2 accepts the Label Mapping message, it has to make sure a PW LSP is set up in the opposite direction (PE1-->PE2) 🌈 If it has already signaled for the matching PW LSP in that direction, there's nothing more to do. Otherwise, it must start that signaling by sending a Label Mapping message to PE1. It's basically the same message PE2 received, except the SAI and TAI are swapped 🔁
So a bidirectional PW is two LSPs, where the FEC of one has the SAII and TAII reversed compared to the FEC of the other. Two LSPs, one vibe 🎀
5.4. Signaling of Pseudowire Status
5.4.1. Use of Label Mappings Messages
Okay, this part is about when PEs send Label Mapping Messages 💌 PEs MUST send Label Mapping Messages to their peers as soon as the PW is configured and administratively enabled, regardless of the attachment circuit state. The PW label should not be withdrawn unless the operator administratively configures the pseudowire down, or the PW configuration gets deleted entirely 🍓 Following 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 in the down state 📉
Once the PW status negotiation procedures are done, if they end up using 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 if the attachment circuit is active 💜 The PW status signaling procedures in this section MUST be fully implemented. No skipping, no ghosting 👻
5.4.2. Signaling PW Status
The PE devices use an LDP TLV to tell their remote peers about status 📣 This PW Status TLV has more info than the simpler Label Withdraw message, so it's the upgrade you want ✨
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 the PW IANA Allocations document [IANA]. The length 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 you can flag more than one failure at once 🚨 Each fault gets cleared by sending an appropriate Notification message where that bit is cleared. The lowest bit (PW Not Forwarding) only works as a generic failure indication, for when there's a link-down event that none of the other bits cover 🧯
The Status TLV goes to the remote PW peer through the LDP Notification message. The general format of the Notification Message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWId FEC TLV or Generalized ID FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Status TLV status code is set to 0x00000028, "PW status", which says that PW status follows 📬 Since this notification doesn't point at any particular message, the Message Id and Message Type fields get set to 0.
The PW FEC TLV SHOULD not include the interface parameter sub-TLVs, since they get ignored in this message's context 🙃 When a PE's attachment circuit runs into an error, the PW Notification Message lets the PE send one "wild card" status message. It uses a PW FEC TLV with only the group ID set, to show this change in status for every affected PW connection 🌍 That status message either contains the PW FEC TLV with only the group ID set, or the Generalized FEC TLV with only the PW Grouping ID TLV.
As mentioned above, the Group ID field of the PWid FEC element, or the PW Grouping ID TLV used with the Generalized ID FEC element, can send a status notification for any arbitrary sets of PWs 🧺 This procedure is OPTIONAL. If you do 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 present, and the interface parameter sub-TLVs aren't present. If 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 Grouping ID TLV is included, and the Interface Parameters TLV is omitted. For this document, that's called the "wild card PW status notification procedure". All PEs implementing this design are REQUIRED to accept such a notification message, but they're not required to send it 🫶
Accepting the wild card is mandatory, sending it is optional. Be the bestie who catches the message even if you never send one 💅
5.4.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: 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. Once that's in place, the PW Status TLV 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 ID FEC +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Parameters |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Generic Label (0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW Status (0x096A) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+If a PW Status TLV is in the initial Label Mapping message for a PW, and the Label Mapping message from the remote PE for that PW doesn't include a PW status TLV, or the remote PE doesn't support the PW Status TLV, then the PW reverts to the label withdraw method of signaling PW status 🔙 Note that if the remote peer doesn't support the PW Status TLV, it'll automatically ignore it, because the I (ignore) bit is set in the TLV 🙈 So the PW Status TLV just won't show up in the matching FEC advertisement from the remote LDP peer, and that gives exactly the behavior above.
If the PW Status TLV isn't present after the FEC TLV in the initial PW Label Mapping message a PE receives, the PW Status TLV won't get used. Both PEs supporting the pseudowire then revert to the label withdraw procedure for signaling status changes 🦋
If the negotiation ends up using the PW status TLV, then the actual PW status is whatever the PW status TLV sent within the initial PW Label Mapping message says. After that, updates to PW status come through the notification message 🎀
5.5. Interface Parameters Sub-TLV ✨
okay bestie, this field is where we check the interface-specific details 💅 When it applies, it MUST be used to validate that the PEs and the ingress and egress ports at the edges of the circuit have the necessary capabilities to interoperate with each other 🫶 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 interface parameter sub-TLV type values are specified in "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)" [IANA].
The Length field is the length of the interface parameter, including the parameter id and length field itself 🧚 Processing of the interface parameters should continue when unknown interface parameters are encountered, and they MUST be silently ignored. Totally chill, no drama 🌸
- Interface MTU sub-TLV type 📏 This is a 2-octet value indicating the MTU in octets. It's the Maximum Transmission Unit, excluding encapsulation overhead, of the egress packet interface that will be transmitting the decapsulated PDU that is received from the MPLS-enabled network. This parameter is applicable only to PWs transporting packets and is REQUIRED for these PW types. If this parameter does not match in both directions of a specific PW, that PW MUST NOT be enabled. Not vibing, so no PW for you 🙅♀️
- Optional Interface Description string sub-TLV type 📝 This arbitrary, and OPTIONAL, interface description string is used to send a human-readable administrative string describing the interface to the remote. This parameter is OPTIONAL and is applicable to all PW types. The interface description parameter string length is variable and can be from 0 to 80 octets. Human-readable text MUST be provided in the UTF-8 charset using the Default Language [RFC2277] 🌈
6. Control Word 🎀
6.1. PW Types for Which the Control Word is REQUIRED
The Label Mapping messages that are sent to set up these PWs MUST have c=1. When a Label Mapping message for a PW of one of these types is received and c=0, a Label Release message MUST be sent, with an "Illegal C-bit" status code. In this case, the PW will not be enabled. 🙅♀️
6.2. PW Types for Which the Control Word is NOT Mandatory
If a system is capable of sending and receiving the control word on PW types for which the control word is not mandatory, then each such PW endpoint MUST be configurable with a parameter that specifies whether the use of the control word is PREFERRED or NOT PREFERRED. For each PW, there MUST be a default value of this parameter. This specification does NOT state what the default value should be. 🤷♀️
If a system is NOT capable of sending and receiving the control word on PW types for which the control word is not mandatory, then it behaves exactly as if it were configured for the use of 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 yet been sent, then the procedure is as follows:
-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 such that the use of the control word is preferred, then 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 such that the use of the control word is not preferred or the control word is not supported, then act as if no Label Mapping message for the PW had been received (i.e., proceed to the next paragraph).
If a Label Mapping message for the PW has not already been received (or if the received Label Mapping message had c=1 and either local configuration says that the use of the control word is not preferred or the control word is not supported), then send a Label Mapping message in which the c bit is set to correspond to the locally configured preference for use of the control word. (That is, set c=1 if locally configured to prefer the control word, and set c=0 if locally configured to prefer not to use the control word or if the control word is not supported.)
The next action depends on what control message is next received for that PW. The possibilities are as follows:
-i. A Label Mapping message with the same c bit value as specified in the Label Mapping message that was sent. PW setup is now complete, and the control word is used if c=1 but is not used if c=0.
-ii. A Label Mapping message with c=1, but the Label Mapping message that was sent has c=0. In this case, ignore the received Label Mapping message and continue to wait for the next control message for the PW.
-iii. A Label Mapping message with c=0, but the Label Mapping message that was sent has 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 as a normal Label Withdraw, but do not respond. Continue to wait for the next control message for the PW.
If at any time after a Label Mapping message has been received a corresponding Label Withdraw or Release is received, the action taken is the same as for any Label Withdraw or Release that might be received at any time.
If both endpoints prefer the use of the control word, this procedure will cause it to be used. If either endpoint prefers not to use the control word or does not support the control word, this procedure will cause it not to be used. If one endpoint prefers to use the control word but the other does not, the one that prefers not to use it is has no extra protocol to execute; it just waits for a Label Mapping message that has c=0. 🫠
The diagram in Appendix A illustrates the above procedure. 🦋
6.3. LDP Label Withdrawal Procedures
As mentioned above, the Group ID field of the PWid FEC element, or the PW Grouping ID TLV used with the Generalized ID FEC element, can be used to withdraw all PW labels associated with a particular PW group. This procedure is OPTIONAL, and if it is implemented, the LDP Label Withdraw message should be as follows: If the PWid FEC element is used, the PW information length field is set to 0, the PW ID field is not present, the interface parameter sub-TLVs are not present, and the Label TLV is not present.
If the Generalized FEC element is used, the AGI, SAII, and TAII are not present, the PW information length field is set to 0, the PW Grouping ID TLV is included, the Interface Parameters TLV is not present, and the Label TLV is not present. For the purpose of this document, this is called the "wild card withdraw procedure", and all PEs implementing this design are REQUIRED to accept such withdrawn message but are not required to send it. Note that the PW Grouping ID TLV only applies to PWs using the Generalized ID FEC element, while the Group ID only applies to 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 wild card Label Release message MUST include only the group ID, or Grouping ID TLV. A Label Release message initiated by a PE router must always include the PW ID. 🔥
6.4. Sequencing Considerations
In the case where the router considers the sequence number field in the control word, it is important to note the following details when advertising labels. 🧠
6.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 (re-use) 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 prevent 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 there is a packet with sequence number=n, where n is in the interval [1,32768] traveling through the network, it would be possible for the disposition router to receive that packet after it re-advertises the label. Since the label has been released by the imposition router, the disposition router SHOULD be expecting the next packet to arrive with a sequence number of 1. Receipt of a packet with a sequence number equal to n will result in n packets potentially being rejected by the disposition router until the imposition router imposes a sequence number of n+1 into a packet. Possible methods to avoid this are for the disposition router always to advertise a different PW label, or for the disposition router to wait for a sufficient time before attempting to re-advertise a recently released label. This is only an issue when sequence number processing is enabled at the disposition router. 😬
6.4.2. Label Release
In situations where the imposition router wants to restart forwarding of packets with sequence number 1, the router shall 1) send to the disposition router a Label Release Message, and 2) send to the disposition router a Label Request message. When sequencing is supported, advertisement of a PW label in response to a Label Request message MUST also consider the issues discussed in the section on Label Advertisements. 💜
7. IANA Considerations 📚
7.1. LDP TLV TYPE
This document uses several new LDP TLV types; IANA already maintains a registry of name "TLV TYPE NAME SPACE" defined by RFC 3036. The following values are suggested for assignment:
TLV type Description
=====================================
0x096A PW Status TLV
0x096B PW Interface Parameters TLV
0x096C Group ID TLV7.2. LDP Status Codes
This document uses several new LDP status codes; IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by RFC 3036. The following values are suggested for assignment:
Range/Value E Description Reference
------------- ----- ---------------------- ---------
0x00000024 0 Illegal C-Bit [RFC4447]
0x00000025 0 Wrong C-Bit [RFC4447]
0x00000026 0 Incompatible bit-rate [RFC4447]
0x00000027 0 CEP-TDM mis-configuration [RFC4447]
0x00000028 0 PW Status [RFC4447]
0x00000029 0 Unassigned/Unrecognized TAI [RFC4447]
0x0000002A 0 Generic Misconfiguration Error [RFC4447]
0x0000002B 0 Label Withdraw PW Status Method [RFC4447]7.3. FEC Type Name Space 🎀
okay so this bit is short but iconic 💅 This doc uses two brand-new FEC element types, 0x80 and 0x81, from the registry "FEC Type Name Space" for the Label Distribution Protocol (LDP RFC 3036) ✨
8. Security Considerations 🔒
bestie, this section is where we get serious 🫶 This doc specifies the LDP extensions you need for setting up and maintaining pseudowires. The whole point of a pseudowire is to let Layer 2 frames get encapsulated in MPLS and sent from one end of the pseudowire to the other end 🦋 So we have to think about security for both the data plane and the control plane 😭
8.1. Data-Plane Security 💜
okay so for the data plane, these are the areas that 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
so when an MPLS PSN is used to provide pseudowire service, there's a perception that security MUST be at least equal to the Layer 2 native protocol networks that are already deployed, the ones the MPLS/PW combo is emulating 🔥 That 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, it's also important to prevent unauthorized physical access to the PSN, plus unauthorized administrative access to individual network elements. no one gets in the back door 💀
as I mentioned above, an MPLS enabled network should not accept MPLS packets from its external interfaces (that's 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 coming from 🌸 If the packet's incoming interface leads to a different SP (rather than a customer), an appropriate trust relationship must also be present. That includes trusting that the other SP also provides appropriate security measures 🫶
there are three main security problems when you use an MPLS-enabled network to carry PWs: 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 it wasn't actually transmitted by the PE that originated the PW. (Basically, the specified encapsulations don't by themselves let the decapsulator authenticate the encapsulator 👀) second, the PW PDU might get altered between entering the PSN and leaving it (so again, the specified encapsulations don't by themselves assure the decapsulator of the packet's integrity 🥺) third, the PDU's contents might be seen while it's in transit through the PSN (the specified encapsulations don't ensure privacy either 🙈). how big a deal these are in practice depends on the security requirements of the applications whose traffic is going through the tunnel, and on how secure the PSN itself is 💅
8.2. Control-Plane Security 🦋
general security considerations for using LDP are covered in section 5 of RFC 3036 ✨ Those considerations also apply when LDP is used to set up pseudowires 💖
okay so a pseudowire connects two attachment circuits. It's super important to make sure LDP connections aren't accepted from just anywhere, or else a local attachment circuit could 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 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. (Obviously, if the auto-discovery protocol weren't trusted, the set of "eligible peers" it produces couldn'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 get rid of the possibility of source address spoofing 🧚
the LDP MD5 authentication key option, described in section 2.9 of RFC 3036, MUST be implemented 🔐 and for a greater degree of security, it must be used. This gives integrity and authentication for the LDP messages and wipes out the possibility of source address spoofing 🎀 Using the MD5 option doesn't provide privacy, but privacy of the LDP control messages isn't usually considered important. Also, because the MD5 option relies on pre-shared keys that get configured, it doesn't offer much protection against replay attacks 😬 And since it depends on those pre-shared keys, it may be very difficult to deploy when the set of eligible neighbors is determined by an auto-configuration protocol 🥲
when the Generalized ID 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 ID FEC element 🧐 But since the peer is known to be one of the eligible peers (as discussed above), this 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, instead of having just one set of eligible peers for the whole PE 💜
9. Acknowledgements 🫶
the authors want to acknowledge the contributions of Vach Kompella, Vanson Lim, Wei Luo, Himanshu Shah, and Nick Weeds 💖
10. Normative References 📚
[RFC2119] Bradner S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.11. Informative References 🌸
[CEP] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
"SONET/SDH Circuit Emulation Service Over Packet (CEP)",
Work in Progress.
[SAToP] Vainshtein, A., Ed. and Y. Stein, Ed., "Structure-Agnostic
TDM over Packet (SAToP)", Work in Progress.
[FRAME] Martini, L., Ed. and C. Kawa, Ed., "Encapsulation Methods
for Transport of Frame Relay Over MPLS Networks", Work in
Progress.
[ATM] Martini, L., Ed., El-Aawar, N., and M. Bocci, Ed.,
"Encapsulation Methods for Transport of ATM Over MPLS
Networks", Work in Progress.
[PPPHDLC] Martini, L., Rosen, E., Heron, G., and A. Malis,
"Encapsulation Methods for Transport of PPP/HDLC Frames
Over IP and MPLS Networks", Work in Progress.
[ETH] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet Over MPLS
Networks", RFC 4448, April 2006.
[SDH] American National Standards Institute, "Synchronous Optical
Network Formats," ANSI T1.105-1995.
[ITUG] ITU Recommendation G.707, "Network Node Interface For The
Synchronous Digital Hierarchy", 1996.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture", RFC 3985, March 2005.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.12. Additional Contributing Authors 🌈
the awesome people who helped write this doc 💅
Dimitri Stratton Vlachos
Mazu Networks, Inc.
125 Cambridgepark Drive
Cambridge, MA 02140
EMail: d@mazunetworks.com
Jayakumar Jayakumar,
Cisco Systems Inc.
225, E.Tasman, MS-SJ3/3,
San Jose, CA, 95134
EMail: jjayakum@cisco.com
Alex Hamilton,
Cisco Systems Inc.
285 W. Tasman, MS-SJCI/3/4,
San Jose, CA, 95134
EMail: tahamilt@cisco.com
Steve Vogelsang
ECI Telecom
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205
EMail: stephen.vogelsang@ecitele.com
John Shirron
ECI Telecom
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205
EMail: john.shirron@ecitele.com
Andrew G. Malis
Tellabs
90 Rio Robles Dr.
San Jose, CA 95134
EMail: Andy.Malis@tellabs.com
Vinai Sirkay
Redback Networks
300 Holger Way
San Jose, CA 95134
EMail: vsirkay@redback.com
Vasile Radoaca
Nortel Networks
600 Technology Park
Billerica MA 01821
EMail: vasile@nortelnetworks.com
Chris Liljenstolpe
Alcatel
11600 Sallie Mae Dr.
9th Floor
Reston, VA 20193
EMail: chris.liljenstolpe@alcatel.com
Dave Cooper
Global Crossing
960 Hamlin Court
Sunnyvale, CA 94089
EMail: dcooper@gblx.net
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Dan Tappan
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: tappan@cisco.comAppendix A. C-bit Handling Procedures Diagram ✨
okay bestie, this is the flowchart for how a PE decides which C-bit to send 🦋 Start at the top with "Received Label Mapping Msg?" and follow the Y and N branches down. Every box is a yes/no check, and the Send lines at the bottom tell you which C-bit goes out. The "Wrong C-Bit" path at the end is the part that makes me 😭 because it's the whole fix-it loop 💅
------------------
Y | Received Label | N
-------| Mapping Msg? |--------------
| ------------------ |
-------------- |
| | |
------- ------- |
| C=0 | | C=1 | |
------- ------- |
| | |
| ---------------- |
| | Control Word | N |
| | Capable? |----------- |
| ---------------- | |
| Y | | |
| | | |
| ---------------- | |
| | Control Word | N | |
| | Preferred? |---- | |
| ---------------- | | |
| Y | | | |
| | | | ----------------
| | | | | Control Word |
| | | | | Preferred? |
| | | | ----------------
| | | | N | Y |
| | | | | |
Send Send Send Send Send Send
C=0 C=1 C=0 C=0 C=0 C=1
| | | |
----------------------------------
| If receive the same as sent, |
| PW setup is complete. If not: |
----------------------------------
| | | |
------------------- -----------
| Receive | | Receive |
| C=1 | | C=0 |
------------------- -----------
| |
Wait for the Send
next message Wrong C-Bit
|
Send Label
Mapping MessageAuthors' Addresses 🎀
Five amazing people wrote this one, and here's where you can find them 💜
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
EMail: lmartini@cisco.com
Nasser El-Aawar
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO, 80021
EMail: nna@level3.net
Giles Heron
Tellabs
Abbey Place
24-28 Easton Street
High Wycombe
Bucks
HP11 1NT
UK
EMail: giles.heron@tellabs.com
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: erosen@cisco.com
Toby Smith
Network Appliance, Inc.
800 Cranberry Woods Drive
Suite 300
Cranberry Township, PA 16066
EMail: tob@netapp.comFull Copyright Statement 🌈
Copyright (C) The Internet Society (2006). Legal time, but the vibe is: the authors still own their stuff, and the document is subject to the rights, licenses and restrictions in BCP 78 🔒
The legal fine print is below, verbatim, because it matters 💀
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property 🦋
The IETF doesn't take a side on whether any patents or other IP rights apply to the tech in this doc, or whether you can get a license for them. It also doesn't claim it went hunting for those rights itself 🫣 If you want the rules on RFC rights, check BCP 78 and BCP 79 ✨
Got an IPR disclosure, or want to know about licenses? Look in the IETF online IPR repository at http://www.ietf.org/ipr. And if you know about a copyright, patent, patent application, or other proprietary right that might cover tech you'd need to build this standard, tell the IETF at ietf-ipr@ietf.org 🙌
Acknowledgement 🌸
Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). The people keeping the RFC library running deserve all the flowers 💐🫶
📦 where this page comes from
- ietf: rfc4447 2006-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms