RFC 7965
LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels
LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels 🎀
Title block tea ☕: this RFC is from the Internet Engineering Task Force (IETF) and it's numbered RFC 7965. It's a Standards Track doc, which means it's an actual Internet Standard, not just a suggestion 💅. The authors are M. Chen and W. Cao (both at Huawei), A. Takacs (at Ericsson), and P. Pan (no affiliation is listed in this excerpt). It came out in August 2016, and its ISSN is 2070-1721. The title block I was given doesn't say what it obsoletes or updates, so I'm not going to guess 🙈.
Abstract ✨
Lots of transport services need user traffic, in the form of Pseudowires (PWs), to go through either one co-routed bidirectional tunnel or two unidirectional tunnels that take the same routes 🛣️. This doc adds an optional extension to the Label Distribution Protocol (LDP) so PWs can get bound to the underlying Traffic Engineering (TE) tunnels 🔗. It works for both single-segment and multi-segment PWs.
Status of This Memo 📜
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7965.
Copyright Notice 💜
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. PSN Tunnel Binding TLV . . . . . . . . . . . . . . . . . 5
3.1.1. PSN Tunnel Sub-TLV . . . . . . . . . . . . . . . . . 7
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8
5. PSN Binding Operation for SS-PW . . . . . . . . . . . . . . . 9
6. PSN Binding Operation for MS-PW . . . . . . . . . . . . . . . 11
7. PSN Tunnel Select Considerations . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. LDP TLV Types . . . . . . . . . . . . . . . . . . . . . . 13
9.1.1. PSN Tunnel Sub-TLVs . . . . . . . . . . . . . . . . . 14
9.2. LDP Status Codes . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 161. Introduction 🦋
Pseudo Wire Emulation Edge-to-Edge (PWE3) [RFC3985] is a way to emulate Layer 2 services, like Ethernet Point-to-Point circuits 🔌. These services are emulated between two Attachment Circuits, and the Pseudowire-encapsulated Layer 2 service payload gets carried through Packet Switching Network (PSN) tunnels between Provider Edges (PEs). PWE3 usually uses the Label Distribution Protocol (LDP) [RFC5036] or Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) as its PSN tunnels. The PEs pick and bind the Pseudowires to PSN tunnels on their own, independently 🙌. Right now there's no standardized, protocol-based way to provision the link between PWs and PSN tunnels, so those associations have to be managed through provisioning or other private methods 😩.
PW-to-PSN Tunnel Binding has gotten super common and important in lots of deployments 📈. It lets service providers promise their customers service level agreements about traffic attributes like bandwidth, latency, and availability 💅.
The requirements for explicit control of PW-to-LSP mapping are described in Section 5.3.2 of [RFC6373]. Figure 1 shows how PWs can be bound to particular LSPs 👀.
+------+ +------+
---AC1 ---|..............PWs...............|---AC1---
---...----| PE1 |=======LSPs=======| PE2 |---...---
---ACn ---| |-------Links------| |---ACn---
+------+ +------+Figure 1: Explicit PW-to-LSP Binding Scenario
There are two PEs (PE1 and PE2) connected through multiple parallel links that may be on different physical fibers 🧵. Each link is managed and controlled as a bidirectional LSP. At each PE, there are a big number of bidirectional user flows coming in from multiple Ethernet interfaces (the access circuits in the figure). Each user flow uses a pair of unidirectional PWs to carry bidirectional traffic. The operators need to make sure the user flows (aka the PW-pairs) ride on the same fiber or bidirectional LSP 🫶.
There are a bunch of reasons behind this requirement 🧠. First, because of delay and latency constraints, traffic going over different fibers may need a lot of expensive buffer memory to make up for the differential delay at the head-end nodes 💸. Also, operators may apply different protection mechanisms to different parts of the network (for example, 1:1 protection in one part and 1+1 protection in other parts). So operators may prefer that a user's traffic goes through the same fiber 🔥. That means both the forwarding and reverse direction PWs that belong to the same user flow need to be mapped to the same co-routed bidirectional LSP, or to two LSPs with the same route.
Figure 2 shows a scenario where PW-LSP binding is not applied 🙈.
+----+ +--+ LSP1 +--+ +----+
+-----+ | PE1|===|P1|======|P2|===| PE2| +-----+
| |----| | +--+ +--+ | |----| |
| CE1 | |............PW................| | CE2 |
| |----| | +--+ | |----| |
+-----+ | |======|P3|==========| | +-----+
+----+ +--+ LSP2 +----+Figure 2: Inconsistent SS-PW-to-LSP Binding Scenario
LSP1 and LSP2 are two bidirectional connections on diverse paths. The operator needs to deliver a bidirectional flow between PE1 and PE2 🤝. With the existing mechanisms, PE1 might pick LSP1 (PE1-P1-P2-PE2) as the PSN tunnel for traffic going from PE1 to PE2, while picking LSP2 (PE2-P3-PE1) as the PSN tunnel for traffic going from PE2 to PE1 😬.
So the user traffic ends up going over two disjoint LSPs that can have very different service attributes in terms of latency and protection. That might not be acceptable as a reliable and effective transport service for the customer 🥲.
A similar problem may also show up in multi-segment PWs (MS-PWs), where user traffic on a particular PW can hop over different networks in the forward and reverse directions 🌀.
One way to fix this is manual provisioning at each PE to bind the PWs to the underlying PSN tunnels. But that's prone to configuration errors and doesn't scale 💀.
This document brings in an automatic solution by extending the Forwarding Equivalence Class (FEC) 128/129 PW based on [RFC4447] ✨.
2. Requirements Language 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀.
3. LDP Extensions 🧚
This document defines a new optional TLV, the PSN Tunnel Binding TLV, which PEs use to talk about tunnel/LSP selection and binding requests between each other 💌. The TLV carries a PW's binding profile and gives explicit or implicit info for the underlying PSN Tunnel Binding operation.
The binding operation applies to both single-segment (SS) and multi-segment (MS) scenarios 🌈.
The extension supports two types of binding requests:
- Strict binding: The requesting PE picks and explicitly indicates the LSP information in the requests. The receiving PE MUST obey the requests; otherwise, the PW will not be established. 🚫
- Co-routed binding: The requesting PE suggests an underlying LSP to a remote PE. Once the remote PE gets it, the remote PE has the option to use the suggested LSP or reply with info about an alternative 🔁.
In this document, the term "tunnel" is identical to the "TE Tunnel" defined in Section 2.1 of [RFC3209]. It's uniquely identified by a SESSION object that includes the Tunnel endpoint address, the Tunnel ID, and the Extended Tunnel ID 🦋. The term "LSP" is identical to the "LSP tunnel" defined in Section 2.1 of [RFC3209]. It's uniquely identified by the SESSION object together with the SENDER_TEMPLATE (or FILTER_SPEC) object, which consists of the LSP ID and the Tunnel endpoint address. Literally the whole identity crisis, but make it networking 😭💖.
3.1. PSN Tunnel Binding TLV 🎀
okay so the PSN Tunnel Binding TLV is an optional TLV, but it's giving essential when PW-to-LSP binding is needed 💅. It MUST be carried in the LDP Label Mapping message [RFC5036] if PW-to-LSP binding is required. Here's the vibe:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| PSN Tunnel Binding(0x0973)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|S|T| Unallocated flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ PSN Tunnel Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PSN Tunnel Binding TLVThe U-bit and F-bit are defined in Section 3.3 [RFC5036] 🦋. Since this TLV is optional, the U-bit MUST be set to 1, so a receiver MUST silently ignore it if it doesn't know the TLV and just keep processing the rest of the message. 🫶
A receiver is not allowed to forward the TLV further when it doesn't know it, so the F-bit MUST be set to 0 🙈.
The PSN Tunnel Binding TLV type is 0x0973 🧚.
The Length field is 2 octets long. It defines the length in octets of the value field (including Flags, Reserved, and sub-TLV fields) 🌸.
The Flags field is 2 octets in length, and three flags are defined in this document ✨. The rest of the unallocated flags MUST be set to zero when sending and MUST be ignored when received.
C (Co-routed path) bit: This bit tells the remote T-PE/S-PEs about the properties of the underlying LSPs 👑. When it's set, the remote T-PE/S-PEs SHOULD select the co-routed LSP (as the forwarding tunnel) as the reverse PSN tunnel. If there's no such tunnel available, it MAY trigger the remote T-PE/S-PEs to establish a new LSP.
S (Strict) bit: This bit tells the PEs how to handle the underlying LSPs 💅. When it's set, the remote PE MUST use the tunnel/LSP specified in the PSN Tunnel Sub-TLV as the PSN tunnel on the reverse direction of the PW, or the PW will fail to be established 😭.
Either the C-bit or the S-bit MUST be set. The C-bit and S-bit are mutually exclusive, so they cannot be set in the same message 🚫. If a status code set to "both C-bit and S-bit are set" or "both C-bit and S-bit are clear" is received, a Label Release message with the status code set to "The C-bit or S-bit unknown" (0x0000003C) MUST be the reply, and the PW will not be established 💀.
T (Tunnel Representation) bit: This bit indicates the format of the LSP tunnels 🦋. When it's set, the tunnel uses the tunnel information to identify itself, and the LSP Number fields in the PSN Tunnel sub-TLV (Section 3.1.1) MUST be set to zero. Otherwise, both the tunnel and LSP information of the PSN tunnel are required. The default is set. The motivation for the T-bit is to support the MPLS protection operation, where the LSP Number fields may be ignored 🛡️.
The Reserved field is 2 octets in length and is left for future use 🌈.
3.1.1. PSN Tunnel Sub-TLV 🍓
PSN Tunnel Sub-TLVs are designed for inclusion in the PSN Tunnel Binding TLV to specify the tunnel/LSPs that a PW is required to bind to 🫧.
Two sub-TLVs are defined: the IPv4 and IPv6 Tunnel sub-TLVs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Number | Source LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Tunnel Number | Destination LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
Figure 4: IPv4 PSN Tunnel Sub-TLV Format 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2) | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source Node ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Number | Source LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Destination Node ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Tunnel Number | Destination LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv6 PSN Tunnel Sub-TLV FormatThe definition of the Source and Destination Global/Node IDs and Tunnel/LSP Numbers is derived from [RFC6370] 🔍. This describes the underlying LSPs. Note that the LSPs in this notation are globally unique. The ITU-T style identifiers [RFC6923] are not used in this document 🙅♀️.
As defined in Sections 4.6.1.1 and 4.6.1.2 of [RFC3209], the "Tunnel endpoint address" is mapped to the Destination Node ID, and the "Extended Tunnel ID" is mapped to the Source Node ID 🧩. Both IDs can be either IPv4 or IPv6 addresses. The Node IDs are routable addresses of the ingress LSR and egress LSR of the Tunnel/LSP.
A PSN Tunnel sub-TLV could be used to identify either a tunnel or a specific LSP. The T-bit in the Flags field defines the distinction, so that when the T-bit is set, the Source/Destination LSP Number fields MUST be zero and ignored during processing. Otherwise, both Source/Destination LSP Number fields MUST have the actual LSP IDs of specific LSPs 🌷.
Each PSN Tunnel Binding TLV MUST only have one such sub-TLV. When sending, only one sub-TLV MUST be carried. When received, if there is more than one sub-TLV carried, only the first sub-TLV MUST be used, and the rest of the sub-TLVs MUST be ignored 🎯.
4. Theory of Operation 🧠
During PW setup, the PEs may choose the desired forwarding tunnels/LSPs and inform the remote T-PE/S-PEs about the desired reverse tunnels/LSPs 💖.
Specifically, to set up a PW (or PW Segment), a PE may select a candidate tunnel/LSP to act as the PSN tunnel. If no candidate is available or none satisfy the constraints, the PE will trigger and establish a new tunnel/LSP. The selected tunnel/LSP information is carried in the PSN Tunnel Binding TLV and sent with the Label Mapping message to the target PE 📬.
When the Label Mapping message is received, the receiving PE will process the PSN Tunnel Binding TLV and determine whether it can accept the suggested tunnel/LSP or find the reverse tunnel/LSP that meets the request. It then responds with a Label Mapping message, which contains the corresponding PSN Tunnel Binding TLV 🎀.
It is possible that two PEs request PSN Binding to the same PW or PW segment over different tunnels/LSPs at the same time. This may cause collisions of tunnel/LSP selection, as both PEs assume the active role 😭.
As defined in (Section 7.2.1, [RFC6073]), each PE may be categorized into active and passive roles 🦋:
- Active PE: The PE that initiates the selection of the tunnel/LSPs and informs the remote PE 🚀;
- Passive PE: The PE that obeys the active PE's suggestion 🫡.
In the rest of this document, we will elaborate on the operation for SS-PW and MS-PW 🌈:
- SS-PW: In this scenario, both PEs for a particular PW MAY assume the active roles 👯♀️.
- MS-PW: One PE is active, while the other is passive. The PWs are set up using FEC 129 ✨.
To be continued in part 3, bestie! 💜
5. PSN Binding Operation for SS-PW ✨
okay bestie, this is where it gets spicy 🌶️ Both PEs on a PW (like PE1 and PE2) can kick off the setup on their own 💅 For PSN Binding, the Label Mapping messages MUST carry a PSN Tunnel Binding TLV, and the PSN Tunnel sub-TLV MUST contain the desired tunnel/LSPs of the sender 🎀
+----+ LSP1 +----+
+-----+ | PE1|====================| PE2| +-----+
| |----| | | |----| |
| CE1 | |............PW................| | CE2 |
| |----| | | |----| |
+-----+ | |====================| | +-----+
+----+ LSP2 +----+
Figure 6: PSN Binding Operation in SS-PW EnvironmentAs we said earlier, there are two flavours of binding requests: co-routed and strict 🦋
In strict binding, PE1 basically says "use LSP1 as the PSN tunnel for the reverse direction, no debate" 😤 PE2 gets told what to use. In the PSN Tunnel Binding TLV, the S-bit MUST be set, the C-bit MUST be cleared, and the Source and Destination IDs/Numbers MUST be filled 🍓
When the S-bit is set, PE2 follows the processing procedure from Section 5.3.3 of [RFC4447], and then decides whether to accept the tunnel/LSP in the PSN Tunnel sub-TLV. Main character decision-making energy 👑
PE2 might also be an active PE and may have started its own PSN Binding requests to PE1. If the PSN tunnel/LSP it received is the same as the one PE2 sent in its Label Mapping message, then the signaling has converged on a mutually agreed Tunnel/LSP. Iconic 🫶 The binding operation is done!
Otherwise, PE2 MUST compare its own Node ID against the received Source Node ID as unsigned integers. If the received Source Node ID is bigger, PE2 replies with a Label Mapping message to finish the PW setup and confirm the binding request. The PSN Tunnel Binding TLV in that message MUST contain the same Source and Destination IDs/Numbers as the received binding request, in the right order (the source is PE2 now, and PE1 becomes the destination). 🔥 But if PE2 has a Node ID that's bigger than the Source Node ID in the PSN Tunnel Binding TLV, it MUST reply with a Label Release message with the status code set to "Reject - unable to use the suggested tunnel/LSPs", along with the received PSN Tunnel Binding TLV. The PW will not be established. Not me getting rejected 💀
To support co-routed binding, the receiving PE can pick the right PSN tunnel/LSP for the reverse direction of the PW, as long as the forward and reverse PSNs share the same route (links and nodes) 🌈
Initially, PE1 sends a Label Mapping message to PE2 with the PSN Tunnel Binding TLV, with the C-bit set, the S-bit cleared, and the right Source and Destination IDs/Numbers. For unidirectional LSPs, the PSN Tunnel Binding TLV may only contain the Source IDs/Numbers. The Destination IDs/Numbers are set to zero and left for PE2 to fill in when it responds to the Label Mapping message 🧚
When PE2 gets this, it's also an active PE and may have started PSN Binding requests to PE1. If the PSN tunnel/LSP it received has the same route as the one sent to PE1 in the Label Mapping message, then the signaling has converged. The binding operation is completed ✨
Otherwise, PE2 compares its own Node ID against the received Source Node ID as unsigned integers. If the received Source Node ID is bigger, PE2 finds or sets up a tunnel/LSP that meets the co-routed constraint, and replies with a Label Mapping message carrying a PSN Binding TLV that has the Source and Destination IDs/Numbers of that tunnel/LSP. But if PE2 has a Node ID that's bigger than the Source Node ID in the PSN Tunnel Binding TLV, it MUST reply with a Label Release message that has the status code set to "Reject - unable to use the suggested tunnel/LSPs" (0x0000003B) and the received PSN Tunnel Binding TLV 🙈
Also, if the received PSN tunnel/LSP endpoints don't match the PW endpoints, PE2 MUST reply with a Label Release message with the status code set to "Reject - unable to use the suggested tunnel/LSPs" (0x0000003B), and the received PSN Tunnel Binding TLV MUST also be carried. Absolutely no mismatched endpoints allowed 🙅♀️
For both strict and co-routed bindings, if the T-bit is set, the LSP Number field MUST be set to zero. Otherwise, the field MUST contain the actual LSP number for the related PSN LSP 🎀
After a PW is up, operators might decide to move it from the current tunnel/LSPs to different ones. The underlying PSN tunnel could also break because of a network failure. When either of these happens, a new Label Mapping message MUST be sent to tell the remote PE about the change 🦋 Heads up: if the T-bit is set, a broken working LSP won't send this update when protection LSPs are in place.
That new message may carry a new PSN Tunnel Binding TLV with the new Source and Destination Numbers/IDs. Handling of the new message should be identical to what's described in this section.
BUT if the new Label Mapping message doesn't contain the PSN Tunnel Binding TLV, it means "remove any co-routed/strict constraints," and the current independent PW-to-PSN Binding gets used instead 💅
Last thing: as an implementation option, PEs may choose not to remove traffic from an operational PW until the underlying PSN tunnel/LSP changes are finished 🌸
6. PSN Binding Operation for MS-PW
MS-PW uses FEC 129 for PW setup. Check out Figure 7 for how this works 🧚
+-----+ LSP1 +-----+ LSP2 +-----+ LSP3 +-----+
+---+ |T-PE1|======|S-PE1|======|S-PE2|======|T-PE2| +---+
| |---| | | | | | | |---| |
|CE1| |......................PW....................| |CE2|
| |---| | | | | | | |---| |
+---+ | |======| |======| |======| | +---+
+-----+ LSP4 +-----+ LSP5 +-----+ LSP6 +-----+
Figure 7: PSN Binding Operation in MS-PW EnvironmentWhen an active PE (that's T-PE1) starts signaling an MS-PW, a PSN Tunnel Binding TLV MUST be carried in the Label Mapping message and sent to the adjacent S-PE (that's S-PE1). The PSN Tunnel Binding TLV includes the PSN Tunnel sub-TLV, which carries the desired tunnel/LSP of T-PE1 🦋
For strict binding, the initiating PE MUST set the S-bit, clear the C-bit, and indicate the binding tunnel/LSP to the next-hop S-PE 😤
When S-PE1 gets the Label Mapping message, it has to figure out whether the signaling is for the forward or reverse direction, as defined in Section 4.2.3 of [RFC7267] 🔍
If the Label Mapping message is for the forward direction, and S-PE1 accepts the requested tunnel/LSPs from T-PE1, S-PE1 MUST save the tunnel/LSP information for reverse-direction processing later on. If S-PE1 doesn't find the PSN Binding request acceptable, it MUST reply to the upstream PE (T-PE1) with a Label Release Message with the status code set to "Reject - unable to use the suggested tunnel/LSPs" (0x0000003B) 🙅♀️
Otherwise, S-PE1 relays the Label Mapping message to the next S-PE (that's S-PE2), with the PSN Tunnel sub-TLV carrying the info of the new PSN tunnel/LSPs that S-PE1 picked. S-PE2 and any subsequent S-PEs repeat the same process until the Label Mapping message reaches the remote T-PE (that's T-PE2) ✨
If T-PE2 agrees with the requested tunnel/LSPs, it replies with a Label Mapping message to start the binding process in the reverse direction. This Label Mapping message contains the received PSN Tunnel Binding TLV for confirmation purposes 💜
When its upstream S-PE (S-PE2) gets that Label Mapping message, it relays the message to its upstream adjacent S-PE (S-PE1), with the previously saved PSN tunnel/LSP information in the PSN Tunnel sub-TLV. The same thing happens on the subsequent S-PEs, until the message reaches T-PE1 and the PSN Binding setup is complete 🌈
While the binding is in progress, if any PE doesn't agree to the requested tunnel/LSPs, it can send a Label Release Message to its upstream adjacent PE with the status code set to "Reject - unable to use the suggested tunnel/LSPs" (0x0000003B). Also, if the received PSN tunnel/LSP endpoints don't match the PW Segment endpoints, the receiving PE MUST reply with a Label Release message with the status code set to "Reject - unable to use the suggested tunnel/LSPs" (0x0000003B), and the received PSN Tunnel Binding TLV MUST also be carried 🙈
For co-routed binding, the initiating PE (T-PE1) MUST set the C-bit, reset the S-bit, and indicate the suggested tunnel/LSP in the PSN Tunnel sub-TLV to the next-hop S-PE (S-PE1) 🦋
During MS-PW setup, PEs have the option to ignore the suggested tunnel/LSP and pick another one for the segment PW between themselves and their upstream PE, in the reverse direction only if that tunnel/LSP is co-routed with the forward one. Otherwise, the procedure is the same as strict binding 💅
Tunnel/LSPs may change after an MS-PW has been established. When a tunnel/LSP changes, the PE that detects the change SHOULD select an alternative tunnel/LSP for temporary use while it negotiates with other PEs, following the procedure described in this section 🫶
7. PSN Tunnel Select Considerations
As we covered in Section 1, the PSN tunnel used for binding can be either a co-routed bidirectional LSP or two LSPs with the same route. A co-routed bidirectional LSP means both directions cross the same nodes and links AND have the same life span 🧚 With two LSPs, even if they start with the same route, there's no guarantee they'll keep it. For example, when Fast ReRoute (FRR) [RFC4090] is deployed for the LSPs, a link or node failure might make the two LSPs take different routes 😭
So, if the network supports co-routed bidirectional LSPs, a co-routed bidirectional LSP is RECOMMENDED. Otherwise, two LSPs with the same route may be used 💖
8. Security Considerations
Okay, this part is seriously important, so listen up 🚨 The ability to control which LSP carries traffic from a PW can be a potential security risk, both for denial of service and for traffic interception 💀 It is RECOMMENDED that PEs not accept the use of LSPs identified in the PSN Tunnel Binding TLV unless the LSP endpoints match the PW or PW segment endpoints. Furthermore, it is RECOMMENDED that PEs implement the LDP security mechanisms described in [RFC5036] and [RFC5920]. Protect your network, bestie 🛡️🩷
9. IANA Considerations
9.1. LDP TLV Types
This document defines a new TLV (Section 3.1) for inclusion in the LDP Label Mapping message. IANA has assigned TLV type value 0x0973 from the "LDP TLV Type Name Space" registry 🌸
9.1.1. PSN Tunnel Sub-TLVs 🎀
okay so this document defines two sub-TLVs (Section 3.1.1) for the PSN Tunnel Binding TLV 🦋 IANA made a brand new PWE3 subregistry called "PSN Tunnel Sub-TLV Name Space" just for them, and it gave the sub-TLV type values like this:
- IPv4 PSN Tunnel sub-TLV:
1💖 - IPv6 PSN Tunnel sub-TLV:
2💖
bestie, the values 0 and 255 in this new registry should be reserved 🙈 and values 1-254 get allocated by IETF Review [RFC5226]. it's giving organized registry energy ✨
9.2. LDP Status Codes
this document defines two new LDP status codes 💅 IANA assigned them codes from the "LDP Status Code Name Space" registry, and they're:
- "Reject - unable to use the suggested tunnel/LSPs":
0x0000003B🔥 - "The C-bit or S-bit unknown":
0x0000003C😭
and the E bit is set to 1 for both of the new codes. periodt 👑
10. References 🌈
10.1. Normative References
these are the ones you need to read, no cap:
- [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>. 📖 - [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>. 🧚 - [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, DOI
10.17487/RFC6370, September 2011, <http://www.rfc-editor.org/info/rfc6370>. 🍓
10.2. Informative References
these ones are extra context, lowkey still super worth a look ✨
- [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI
10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>. 🌸 - [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>. 🦋 - [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI
10.17487/RFC4090, May 2005, <http://www.rfc-editor.org/info/rfc4090>. 💜 - [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>. 🎀 - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI
10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. 🫶 - [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI
10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>. 🔒 - [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, DOI
10.17487/RFC6073, January 2011, <http://www.rfc-editor.org/info/rfc6073>. ⭐ - [RFC6373] Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed., Bitar, N., Ed., and E. Gray, Ed., "MPLS Transport Profile (MPLS-TP) Control Plane Framework", RFC 6373, DOI
10.17487/RFC6373, September 2011, <http://www.rfc-editor.org/info/rfc6373>. 🌈 - [RFC6923] Winter, R., Gray, E., van Helvoort, H., and M. Betts, "MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions", RFC 6923, DOI
10.17487/RFC6923, May 2013, <http://www.rfc-editor.org/info/rfc6923>. 🧚 - [RFC7267] Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed., "Dynamic Placement of Multi-Segment Pseudowires", RFC 7267, DOI
10.17487/RFC7267, June 2014, <http://www.rfc-editor.org/info/rfc7267>. 💖
Acknowledgements 🫶
okay the authors wanna thank Adrian Farrel, Kamran Raza, Xinchun Guo, Mingming Zhu, and Li Xue for their comments and help in getting this document together 💕 they also thank everyone they chatted with about it: Nabil Bitar, Paul Doolan, Frederic Journay, Andy Malis, Curtis Villamizar, Luca Martini, Alexander Vainshtein, Huub van Helvoort, Daniele Ceccarelli, and Stewart Bryant ✨
they especially want to acknowledge Ping Pan, who was a coauthor on the early draft versions of this document. it was a privilege to have known him 🕊️
the coauthors, the working group chairs, the responsible AD, and the PALS working group dedicate this RFC to the memory of our friend and colleague Ping Pan, in recognition for his devotion and hard work at the IETF. 🌈💜
Authors' Addresses 🦋
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com
Wei Cao
Huawei
Email: wayne.caowei@huawei.com
Attila Takacs
Ericsson
Laborc u. 1.
Budapest 1037
Hungary
Email: attila.takacs@ericsson.com
Ping Pan📦 where this page comes from
- ietf: rfc7965 2016-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms