RFC 8185
Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection
Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection 🎀
Okay bestie, so this is an IETF Standards Track doc from June 2017 (ISSN 2070-1721 if you're nerdy like that 🤓). W. Cheng, L. Wang, and H. Li from China Mobile wrote it, along with J. Dong from Huawei Technologies and A. D'Alessandro from Telecom Italia. The title block doesn't list anything it obsoletes or updates. 💅
Abstract ✨
Okay so in some setups, MPLS-TP pseudowires (PWs) (RFC 5921) get configured statically because there's no dynamic control plane 🙃 Which means they need a fast protection mechanism that can handle a failed Attachment Circuit (AC), a failed Provider Edge (PE), or a failure in the Packet Switched Network (PSN). The framework and the main dual-homing PW local protection scenarios are covered in RFC 8184. This document proposes a dual-homing coordination mechanism for MPLS-TP PWs, used to exchange state and coordinate switchover between the dual-homing PEs for that local protection. It's giving teamwork 🫶
Status of This Memo 📜
This is an Internet Standards Track document.
It's a product of the Internet Engineering Task Force (IETF), so 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). For more on Internet Standards, check Section 2 of RFC 7841.
You can find info about the current status of this doc, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc8185.
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) in effect on the date of publication of this document. Please read these carefully, because they spell out your rights and restrictions for 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 they come without warranty as described in the Simplified BSD License. 📝
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Overview of the Proposed Solution . . . . . . . . . . . . . . 4
4. Protocol Extensions for Dual-Homing MPLS-TP PW Protection . . 5
4.1. Information Exchange Between Dual-Homing PEs . . . . . . 5
4.2. Protection Procedures . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 171. Introduction 🦋
Okay so [RFC6372], [RFC6378], and [RFC7771] cover the framework and mechanism for MPLS-TP linear protection, which can protect the MPLS Label Switched Path (LSP) and the pseudowires (PWs) between the edge nodes. The catch is that these can't protect against a failed Attachment Circuit (AC) or a failed edge node 😬 [RFC6718] and [RFC6870] give us PW redundancy for protecting the AC or the edge node by adding one or more edge nodes, but it requires PW switchover when the AC fails. Also, PW redundancy relies on Packet Switched Network (PSN) protection mechanisms to handle a PW failure.
In some setups like mobile backhauling, the MPLS PWs are provisioned in a dual-homing topology, where at least the Customer Edge (CE) node on one side is dual-homed to two Provider Edge (PE) nodes. If the primary AC fails, operators usually want to do a local switchover on the dual-homing PE side and keep the working pseudowire unchanged whenever that's possible. This avoids a massive PW switchover across the mobile backhaul network because of an AC failure at the mobile core site. That kind of massive switchover can cause congestion by pushing traffic off the paths network planners prefer. Similarly, since many PWs share the physical AC at the mobile core site, it's better to keep using the working AC when one working PW fails in the PSN, which can potentially avoid unnecessary switchover for the other PWs. 🙌
So to meet all of that, a fast dual-homing PW protection mechanism is needed to protect against failures in the AC, the PE node, and the PSN. Super important stuff 💖
[RFC8184] describes a framework and several scenarios for dual-homing PW local protection. This document proposes a dual-homing coordination mechanism for static MPLS-TP PWs, and the mechanism is used for information exchange and switchover coordination between the dual-homing PEs for that local protection. The proposed mechanism has already been implemented and deployed in several mobile backhaul networks that use static MPLS-TP PWs to backhaul mobile traffic from the radio access sites to the core site. Literally real world proof 🔥
2. Requirements Language 🔑
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🧚
3. Overview of the Proposed Solution 🌸
Okay so linear protection mechanisms for the MPLS-TP network are defined in [RFC6378], [RFC7271], and [RFC7324]. When these get applied to PW linear protection [RFC7771], both the working PW and the protection PW end up terminated on the same PE node. To get dual-homing protection for MPLS-TP PWs, we need some extra mechanisms. 👀
Here's the deal: in MPLS-TP PW dual-homing protection, the linear protection mechanism (as defined in [RFC6378], [RFC7271], and [RFC7324]) on the single-homing PE (for example, PE3 in Figure 1) doesn't change. On the dual-homing side, though, the working PW and the protection PW get terminated on two dual-homing PEs (for example, PE1 and PE2 in Figure 1), respectively. That protects against a failure in a PE or in a connected AC. As described in [RFC8184], a dedicated Dual-Node Interconnection (DNI) PW sits between the two dual-homing PE nodes to forward the traffic. 🔀
To use the linear protection mechanism [RFC7771] in the dual-homing PE scenario, the dual-homing PE nodes have to coordinate with each other. That way they can switch the connection between the AC, the service PW, and the DNI-PW properly, in a coordinated fashion, by the forwarder. It's giving choreography 💃
+----------------------------------+
| PE1 |
+----------------------------------+ +----+
| | | Working | |
X Forwarder + Service X-------------X |
/| | PW | Service PW1 | |
AC1 / +--------+--------+ | | |
/ | DNI-PW | | | |
+---* +--------X--------+----------------+ | | +---+
| | ^ | | | |
|CE1| | DNI-PW |PE3 +---|CE2|
| | | | | | |
| | V | | | |
+---* +--------X--------+----------------+ | | +---+
\ | DNI-PW | | | |
AC2 \ +--------+--------+ | Protection | |
\| | Service X-------------X |
X Forwarder + PW | Service PW2 | |
| | | +----+
+----------------------------------+
| PE2 |
+----------------------------------+
Figure 1: Dual-Homing Protection with DNI-PW4. Protocol Extensions for Dual-Homing MPLS-TP PW Protection 💖
Okay bestie, in dual-homing MPLS-TP PW local protection, the forwarding states of the dual-homing PEs get decided by the forwarding state machine in Table 1. Time to see the vibes table 📊
+-----------+---------+--------+---------------------+
|Service PW | AC | DNI-PW | Forwarding Behavior |
+-----------+---------+--------+---------------------+
| Active | Active | Up |Service PW <-> AC |
+-----------+---------+--------+---------------------+
| Active | Standby | Up |Service PW <-> DNI-PW|
+-----------+---------+--------+---------------------+
| Standby | Active | Up | DNI-PW <-> AC |
+-----------+---------+--------+---------------------+
| Standby | Standby | Up | Drop all packets |
+-----------+---------+--------+---------------------+
| Active | Active | Down |Service PW <-> AC |
+-----------+---------+--------+---------------------+
| Active | Standby | Down | Drop all packets |
+-----------+---------+--------+---------------------+
| Standby | Active | Down | Drop all packets |
+-----------+---------+--------+---------------------+
| Standby | Standby | Down | Drop all packets |
+-----------+---------+--------+---------------------+
Table 1: Dual-Homing PE Forwarding State MachineTo actually achieve dual-homing MPLS-TP PW protection, the dual-homing PE nodes need to coordinate with each other so they can exchange the PW status and the protection coordination requests. That's the whole vibe 🫶✨
4.1. Information Exchange Between Dual-Homing PEs ✨
okay so the coordination info gets sent over the DNI-PW using the Generic Associated Channel (G-ACh), as described in [RFC5586] 🦋 A brand-new G-ACh channel type is defined just for dual-homing coordination between the dual-homing PEs of MPLS-TP PWs 💖 This channel type can carry all kinds of different info between the PEs, but this document only uses it for PW status and switchover coordination 🎀 Any other potential uses are for further study and are out of scope here 🙈
The MPLS-TP Dual-Homing Coordination (DHC) message is sent on the DNI-PW between the dual-homing PEs. Here's what it looks like 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | DHC Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dual-Homing PEs Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS-TP Dual-Homing Coordination MessageThe first 4 octets are the common G-ACh header as specified in [RFC5586]. The DHC Channel Type is the G-ACh channel type code point assigned by IANA (0x0009). 💅
The Dual-Homing Group ID is a 4-octet unsigned integer that identifies the dual-homing group the dual-homing PEs belong to. It MUST be the same at both PEs in the same group. 🫶
The TLV Length field says the total length in octets of the TLVs that follow 🧚
In this document, two TLVs are defined in the MPLS-TP Dual-Homing Coordination message for dual-homing MPLS-TP PW protection:
Type Description Length
1 PW Status 20 bytes
2 Dual-Node Switching 16 bytesThe PW Status TLV is how a dual-homing PE reports its service PW status to the other dual-homing PE in the same group ✨
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 (PW Status) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Dual-Homing PE Node_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Dual-Homing PE Node_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DNI-PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service PW Status |D|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PW Status TLVThe Length field is the length in octets of the TLV's value field 🌸
The Destination Dual-Homing PE Node_ID is the 32-bit identifier of the receiver PE [RFC6370], which supports both IPv4 and IPv6 environments. Usually it's the same as the Label Switching Router ID (LSR ID) of the receiver PE. 💜
The Source Dual-Homing PE Node_ID is the 32-bit identifier of the sending PE [RFC6370], which supports both IPv4 and IPv6 environments. Usually it's the same as the LSR ID of the sending PE. 🦋
The DNI-PW ID field holds the 32-bit PW ID [RFC8077] of the DNI-PW. 🍓
The Flags field is 32-bit flags, and here's the tea:
- The P (Protection) bit shows whether the Source Dual-Homing PE is the working PE (P=0) or the protection PE (P=1). 🎀
- Other bits are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored upon receipt. 🙈
The Service PW Status field shows the status of the service PW between the sending PE and the remote PE. Right now, two bits are defined in it:
- F bit: If set, it indicates Signal Fail (SF) [RFC6378] on the service PW. It can be a local request the PE generates itself, or a remote request received from the remote PE. 💀
- D bit: If set, it indicates Signal Degrade (SD) [RFC6378] on the service PW. It can be either a local request or a remote request received from the remote PE. 😭
- Other bits are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored upon receipt. 🌈
The Dual-Node Switching TLV is how one dual-homing PE sends protection state coordination to the other PE in the same group 👑
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 (Dual-Node Switching) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Dual-Homing PE Node_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Dual-Homing PE Node_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DNI-PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |S|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Dual-Node Switching TLVThe Length field is the length in octets of the TLV's value field 🧚
The Destination Dual-Homing PE Node_ID is the 32-bit identifier of the receiver PE [RFC6370]. Usually it's the same as the LSR ID of the receiver PE. 💖
The Source Dual-Homing PE Node_ID is the 32-bit identifier of the sending PE [RFC6370]. Usually it's the same as the LSR ID of the sending PE. ✨
The DNI-PW ID field holds the 32-bit PW-ID [RFC8077] of the DNI-PW. 🎀
The Flags field is 32-bit flags, and in it:
- The P (Protection) bit shows whether the Source Dual-Homing PE is the working PE (P=0) or the protection PE (P=1). 🌸
- The S (PW Switching) bit tells which service PW is used for forwarding traffic. It's set to 0 when traffic will be transported on the working PW, and set to 1 if traffic will be transported on the protection PW. The value of the S bit is determined by the protection coordination mechanism between the dual-homing PEs and the remote PE. 🦋
- Other bits are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored upon receipt. 💅
When one of the dual-homing PEs detects a change in service PW status, it MUST reflect that in the PW Status TLV and send it to the other dual-homing PE as quickly as possible, so fast protection switching can happen using three consecutive DHC messages. This set of three messages still works for fast protection switching even if one or two of those packets get lost or corrupted 🔥 After those three rapid messages go out, the dual-homing PE MUST keep sending the most recently transmitted service PW status periodically, on a continual basis, using the DHC message 🫶
When one dual-homing PE decides the active service PW needs to switch from the working PW to the protection PW, it MUST send the Dual-Node Switching TLV to the other dual-homing PE as quickly as possible, so fast protection switching can happen using three consecutive DHC messages. After those three messages, the protection PW becomes the active service PW, and the dual-homing PE MUST keep sending the most recently transmitted Dual-Node Switching TLV periodically, on a continual basis, using the DHC message 🌈
It is RECOMMENDED that the default interval of the first three rapid DHC messages be 3.3 ms, similar to [RFC6378], and the default interval of the subsequent messages be 1 second. Both the default interval of the three consecutive messages and the default interval of the periodic messages SHALL be configurable by the operator. ⭐
4.2. Protection Procedures ✨
okay bestie, this is where the dual-homing PW protection actually comes alive 🦋 It can be deployed with the existing AC redundancy mechanisms, and on the PSN side you don't need a PSN tunnel protection mechanism, because dual-homing PW protection can also cover a failure in the PSN. main character energy 👑
I'm using the one-side dual-homing scenario as the example here. The procedures for a two-side dual-homing scenario would be similar, so you've got the vibe either way 💅
On the dual-homing PE side, the working and protection PE roles get set by the management system or local configuration. The service PW that connects to the working PE is the working PW, and the service PW that connects to the protection PE is the protection PW 🎀
On the single-homing PE side, it treats the working PW and protection PW as if they both end on the same remote PE node. So the normal MPLS-TP protection coordination procedures still apply on the single-homing PE 🌸
Here's how the forwarding behavior of the dual-homing PEs is put together, from the components in the figure below 🧚
+---------------------------------+ +-----+
| PE1 (Working PE) | | |
+---------------------------------+ PW1 | |
| | | Working | |
+ Forwarder + Service X<-------->X |
/| | PW | | |
/ +--------+--------+ | | |
AC1 / | DNI-PW | | | |
/ +--------X--------+---------------+ | |
+-----+/ AC ^ DNI-PW | | +---+
| CE1 |redundancy | | PE3 +--|CE2|
+-----+ mechanism | DHC message | | +---+
\ V exchange | |
AC2 \ +--------X--------+---------------+ | |
\ | DNI-PW | | | |
\ +--------+--------+ | PW2 | |
\| | Service |Protection| |
+ Forwarder + PW X<-------->X |
| | | PSC | |
+---------------------------------+ message | |
| PE2 (Protection PE) | exchange | |
+---------------------------------+ +-----+Figure 5: Components of One-Side Dual-Homing PW Protection
In Figure 5, every dual-homing PE has a service PW, which is the PW carrying service between that dual-homing PE and the remote PE. The state of the service PW comes from the Operation, Administration, and Maintenance (OAM) mechanisms running between the dual-homing PEs and the remote PE 🔥
The DNI-PW gets provisioned between the two dual-homing PE nodes. It's the bridge that carries traffic when a failure hits the PSN or the ACs. Its state comes from the OAM mechanism between the dual-homing PEs. Since the DNI-PW carries both the DHC messages and the service traffic during protection switching, its robustness really matters 🫶 To keep a single link failure from taking the DNI-PW down, it is RECOMMENDED that multiple diverse links be deployed between the dual-homing PEs, and the underlying Label Switched Path (LSP) protection mechanism SHOULD be enabled 🛡️
The AC is the link that connects a dual-homing PE to the dual-homed CE. Its status comes from the existing AC redundancy mechanisms, which are out of scope for this document 💀
To run dual-homing PW local protection, the service PW status and Dual-Node Switching coordination requests get exchanged between the dual-homing PEs using the DHC message from Section 4.1 ✨
Whenever a dual-homing PE detects a change in service PW status, it MUST reflect that change in the PW Status TLV and send it to the other dual-homing PE immediately, using three consecutive DHC messages. Once those three rapid messages are out, the dual-homing PE MUST keep sending the most recently transmitted service PW status to the other dual-homing PE periodically, on a continual basis, using the DHC message. That's how both dual-homing PEs end up with a consistent view of the working and protection PW status 🌈
When a switchover request shows up, either generated locally or received on the protection PW from the remote PE, the dual-homing PEs can work out the active/standby state of the service PW. They use the status of the working and protection service PW, plus the local and remote protection coordination requests between the dual-homing PEs and the remote PE. Since the remote protection coordination request travels over the protection path, the active/standby status of the service PW is determined by the protection PE in the dual-homing group 💜
If one dual-homing PE decides that the service PW needs a switchover, that dual-homing PE MUST set the S bit in the Dual-Node Switching TLV and send it to the other dual-homing PE immediately, using three consecutive DHC messages. With the service PW status and the switching request exchanged, both dual-homing PEs agree on the active/standby forwarding status of the working and protection service PWs ✨ The status of the DNI-PW is determined by the PW OAM mechanism defined in [RFC5085], and the status of ACs is determined by the existing AC redundancy mechanisms. Both are out of scope for this document. The forwarding behavior on the dual-homing PE nodes follows the forwarding state machine shown in Table 1 🎀
Using the topology in Figure 5 as the example, in the normal state the working PW (PW1) is active, the protection PW (PW2) is standby, the DNI-PW is up, and AC1 is active according to the AC redundancy mechanism. Following the forwarding state machine in Table 1, traffic goes through the working PW (PW1) and the primary AC (AC1). Nothing goes through the protection PE (PE2) or the DNI-PW, because both the protection PW (PW2) and the AC connecting to PE2 are standby 🦋
If AC1 fails, AC2 changes to active according to the AC redundancy mechanism, while the working and protection PWs don't change at all. Following the forwarding state machine in Table 1, PE1 starts forwarding traffic between the working PW and the DNI-PW, and PE2 starts forwarding traffic between AC2 and the DNI-PW. Note that in this case only AC switchover happens. In the PSN, traffic is still forwarded using the working PW 🌸
If a failure in the PSN takes PW1 down, PE1 or PE3 can detect it using existing OAM mechanisms. When PE1 detects the failure of PW1, it MUST inform PE2 of the working PW's state using the PW Status TLV in the DHC messages, and change the forwarding status of PW1 to standby. On receipt of the DHC message, PE2 SHOULD change the forwarding status of PW2 to active. Then, following the forwarding state machine in Table 1, PE1 SHOULD set up the connection between the DNI-PW and AC1, and PE2 SHOULD set up the connection between PW2 and the DNI-PW. According to the linear protection mechanism [RFC6378], PE2 also sends an appropriate protection coordination message [RFC6378] over the protection PW (PW2) to PE3, so the remote side switches over from PW1 to PW2. If PE3 detects the failure of PW1, then according to the linear protection mechanism [RFC6378], it sends a protection coordination message on the protection PW (PW2) to tell PE2 about the failure on the working PW. Upon receipt of that message, PE2 SHOULD change the forwarding status of PW2 to active and set up the connection following the forwarding state machine in Table 1. PE2 SHOULD send a DHC message to PE1 with the S bit set in the Dual-Node Switching TLV, so PE1 and PE2 coordinate the switchover. This is handy for a unidirectional failure that PE1 can't detect on its own 🧚
If a failure brings the working PE (PE1) down, PE2 and PE3 can both detect it using existing OAM mechanisms. Both PE2 and PE3 SHOULD change the forwarding status of PW2 to active, and send a protection coordination message [RFC6378] on the protection PW (PW2) to tell the remote side to switch over. According to the existing AC redundancy mechanisms, AC1 changes to standby and AC2 changes to active. Following the forwarding state machine in Table 1, PE2 starts forwarding traffic between PW2 and AC2 💖
5. IANA Considerations ✨
IANA has assigned a new channel type for the "MPLS-TP Dual-Homing Coordination Message" from the "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)" subregistry within the "Generic Associated Channel (G-ACh) Parameters" registry 🌈
Value Description Reference
0x0009 MPLS-TP Dual-Homing Coordination message RFC 8185IANA has also created a new subregistry called "MPLS-TP DHC TLVs" within the "Generic Associated Channel (G-ACh) Parameters" registry. It has the following fields and initial allocations 🍓
Type Description Length Reference
0x0000 Reserved
0x0001 PW Status 20 Bytes RFC 8185
0x0002 Dual-Node Switching 16 Bytes RFC 8185The allocation policy for this registry is IETF Review, as specified in [RFC8126] 👑
6. Security Considerations 🔐
Okay bestie, security time, and it's a big deal 💀. MPLS-TP is basically a subset of MPLS, so it inherits a lot of the MPLS security model. For the generic MPLS security stuff, plus how to keep traffic private and intact, go check [RFC5920] 🔒.
The DHC message in this doc is a control message 🎛️. If an attacker sneaks in and injects or messes with it, the dual-homing PEs might disagree about which PE should carry the CE traffic 😱. That's basically a denial-of-service attack on the CE 🚨. So the DHC message needs to live inside a trusted MPLS-TP network domain, as described in [RFC6941]. Trust is everything, no cap 🫶.
The DHC message rides in the G-ACh [RFC5586], which means its security depends on the G-ACh itself 🧩. The G-ACh is a generalization of the Associated Channel defined in [RFC4385], so this document leans on the security mechanisms for the Associated Channel described in those two documents. Main character energy: borrowing the security of the parents 🦋.
Here's the tea. As the Security Considerations section of [RFC6378] explains, the G-ACh is basically connection oriented 💜. That means injecting or modifying control messages would require subverting a transit node 🕵️♀️. Subverting a transit node is generally considered hard in connection-oriented MPLS networks, and it's basically impossible to protect against at the protocol level 😭. So the better move is management-level techniques 🌸. Also, the procedures and protocol extensions in this document don't change the security model of MPLS-TP linear protection as defined in [RFC6378] ✨.
One more important thing, babe ⚠️. The identifiers defined here are only unique if the assigner (for example, the operator) makes them unique 🍓. If an assigner fails to use unique values within the specified scoping for any of these identifiers, it could cause operational problems 💀. For more on identifier uniqueness, check [RFC6370] 📚.
7. References 📚
7.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>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire
Virtual Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<http://www.rfc-editor.org/info/rfc5586>.
[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>.
[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-
TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378,
October 2011, <http://www.rfc-editor.org/info/rfc6378>.
[RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H.,
D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS
Transport Profile (MPLS-TP) Linear Protection to Match the
Operational Expectations of Synchronous Digital Hierarchy,
Optical Transport Network, and Ethernet Transport Network
Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014,
<http://www.rfc-editor.org/info/rfc7271>.
[RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear
Protection", RFC 7324, DOI 10.17487/RFC7324, July 2014,
<http://www.rfc-editor.org/info/rfc7324>.
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
Maintenance Using the Label Distribution Protocol (LDP)",
STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
<http://www.rfc-editor.org/info/rfc8077>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<http://www.rfc-editor.org/info/rfc8174>.7.2. Informative References
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <http://www.rfc-editor.org/info/rfc4385>.
[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>.
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
Profile (MPLS-TP) Survivability Framework", RFC 6372,
DOI 10.17487/RFC6372, September 2011,
<http://www.rfc-editor.org/info/rfc6372>.
[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
Redundancy", RFC 6718, DOI 10.17487/RFC6718, August 2012,
<http://www.rfc-editor.org/info/rfc6718>.
[RFC6870] Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire
Preferential Forwarding Status Bit", RFC 6870,
DOI 10.17487/RFC6870, February 2013,
<http://www.rfc-editor.org/info/rfc6870>.
[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed.,
and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP)
Security Framework", RFC 6941, DOI 10.17487/RFC6941,
April 2013, <http://www.rfc-editor.org/info/rfc6941>.
[RFC7771] Malis, A., Ed., Andersson, L., van Helvoort, H., Shin, J.,
Wang, L., and A. D'Alessandro, "Switching Provider Edge
(S-PE) Protection for MPLS and MPLS Transport Profile
(MPLS-TP) Static Multi-Segment Pseudowires", RFC 7771,
DOI 10.17487/RFC7771, January 2016,
<http://www.rfc-editor.org/info/rfc7771>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<http://www.rfc-editor.org/info/rfc8126>.
[RFC8184] Cheng, W., Wang, L., Li, H., Davari, S., and J. Dong,
"Dual-Homing Protection for MPLS and the MPLS Transport
Profile (MPLS-TP) Pseudowires", RFC 8184,
DOI 10.17487/RFC8184, June 2017.Contributors 🫶
The following individuals substantially contributed to the content of this document 💖:
Kai Liu
Huawei Technologies
Email: alex.liukai@huawei.com
Shahram Davari
Broadcom Corporation
Email: davari@broadcom.comAuthors' Addresses 🌸
Weiqiang Cheng
China Mobile
No.32 Xuanwumen West Street
Beijing 100053
China
Email: chengweiqiang@chinamobile.com
Lei Wang
China Mobile
No.32 Xuanwumen West Street
Beijing 100053
China
Email: Wangleiyj@chinamobile.com
Han Li
China Mobile
No.32 Xuanwumen West Street
Beijing 100053
China
Email: Lihan@chinamobile.com
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: jie.dong@huawei.com
Alessandro D'Alessandro
Telecom Italia
via Reiss Romoli, 274
Torino 10148
Italy
Email: alessandro.dalessandro@telecomitalia.it📦 where this page comes from
- ietf: rfc8185 2017-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms