RFC 6428
Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile
RFC 6428 ✨ Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile
Quick facts 🎀 This is an IETF Standards Track doc from November 2011 (ISSN 2070-1721). It's a Request for Comments, so it's an official spec, not just an idea. The editors are D. Allan of Ericsson, G. Swallow of Cisco Systems, Inc., and J. Drake of Juniper. The title block doesn't list anything it obsoletes or updates, so nothing is being replaced or patched here 💅
Abstract 🦋
Okay so, Continuity Check, Proactive Connectivity Verification, and Remote Defect Indication are all required for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM). They're the stuff that keeps your network honest 🫶
Continuity Check watches a Label Switched Path for any loss of continuity defect. Connectivity Verification boosts Continuity Check by confirming that the source you wanted is actually connected to the sink you wanted. Remote Defect Indication lets an end point tell its matching end point about a fault it's seeing on a pseudowire, Label Switched Path, or Section 🔥
This doc specifies extensions to Bidirectional Forwarding Detection (BFD), plus methods for proactive Continuity Check, Continuity Verification, and Remote Defect Indication for MPLS-TP pseudowires, Label Switched Paths, and Sections, all using BFD as extended by this memo 💜
Status of This Memo 🌸
This is an Internet Standards Track document.
It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6428.
Copyright Notice 🧚
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.
Table of Contents 🍓
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
2.1. Terminology ................................................3
2.2. Requirements Language ......................................5
3. MPLS-TP CC, Proactive CV, and RDI Mechanism Using BFD ...........5
3.1. Existing Capabilities ......................................5
3.2. CC, CV, and RDI Overview ...................................5
3.3. ACH Code Points for CC and Proactive CV ....................6
3.4. MPLS-TP BFD CC Message Format ..............................7
3.5. MPLS-TP BFD Proactive CV Message Format ....................8
3.5.1. Section MEP-ID ......................................9
3.5.2. LSP MEP-ID ..........................................9
3.5.3. PW End Point MEP-ID ................................10
3.6. BFD Session in MPLS-TP Terminology ........................10
3.7. BFD Profile for MPLS-TP ...................................11
3.7.1. Session Initiation and Modification ................12
3.7.2. Defect Entry Criteria ..............................13
3.7.3. Defect Entry Consequent Action .....................14
3.7.4. Defect Exit Criteria ...............................14
3.7.5. State Machines .....................................15
3.7.6. Configuration of MPLS-TP BFD Sessions ..............17
3.7.7. Discriminator Values ...............................17
4. Configuration Considerations ...................................18
5. IANA Considerations ............................................18
6. Security Considerations ........................................19
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................20
8. Acknowledgments ................................................20
9. Contributing Authors ...........................................211. Introduction ✨
In traditional transport networks, circuits get provisioned across two or more switches. Service providers need Operations, Administration, and Maintenance (OAM) tools to catch mis-connectivity and loss of continuity on those transport circuits 😭
Both pseudowires (PWs) and MPLS-TP Label Switched Paths (LSPs) [12] that imitate traditional transport circuits need to offer the same Continuity Check (CC), proactive Continuity Verification (CV), and Remote Defect Indication (RDI) capabilities that RFC 5860 [3] asks for. This document explains how to use Bidirectional Forwarding Detection (BFD) [4] for CC, proactive CV, and RDI on a PW, an LSP, or a Sub-Path Maintenance Entity (SPME) sitting between two Maintenance Entity Group End Points (MEPs) 💖
As RFC 6371 [13] describes, the CC and CV functions detect loss of continuity (LOC) and unintended connectivity between two MEPs. Think mis-merging, mis-connectivity, or an unexpected MEP showing up 👀
RDI is an indicator a MEP sends to tell its peer MEP that a signal fail condition exists. It's only used for bidirectional LSPs, and it's tied to proactive CC and CV BFD control packet generation 🦋
This document specifies the BFD extension and behavior that cover the CC, proactive CV monitoring, and RDI functional requirements for both co-routed and associated bidirectional LSPs. The supported encapsulations are Generic Associated Channel Label (GAL) / Generic Associated Channel (G-ACh), Virtual Circuit Connectivity Verification (VCCV), and UDP/IP. Procedures for unidirectional point-to-point (P2P) and point-to-multipoint (P2MP) LSPs are for further study 🌈
This document uses identifiers for MPLS-TP systems as defined in RFC 6370 [9]. The ITU-T is working on a globally-unique semantic for ITU Carrier Codes (ICCs), and future work may extend this document to use ICCs as identifiers for MPLS-TP systems 🧚
The mechanisms in this document are restricted to BFD asynchronous mode.
2. Conventions Used in This Document 🎀
2.1. Terminology 💜
Here's the glossary, so everyone's on the same page:
- ACH: Associated Channel Header
- BFD: Bidirectional Forwarding Detection
- CC: Continuity Check
- CV: Connectivity Verification
- GAL: Generic Associated Channel Label
- G-ACh: Generic Associated Channel
- LDI: Link Down Indication
- LKI: Lock Instruct
- LKR: Lock Report
- LSP: Label Switched Path
- LSR: Label Switching Router
- ME: Maintenance Entity
- MEG: Maintenance Entity Group
- MEP: Maintenance Entity Group End Point
- MIP: Maintenance Entity Group Intermediate Point
- MPLS: Multiprotocol Label Switching
- MPLS-OAM: MPLS Operations, Administration and Maintenance
- MPLS-TP: MPLS Transport Profile
- MPLS-TP LSP: Unidirectional or bidirectional Label Switched Path representing a circuit
- MS-PW: Multi-Segment Pseudowire
- NMS: Network Management System
- OAM: Operations, Administration, and Maintenance [14]
- PW: Pseudowire
- PDU: Protocol Data Unit
- P/F: Poll/Final
- RDI: Remote Defect Indication
- SPME: Sub-Path Maintenance Entity
- TTL: Time To Live
- TLV: Type Length Value
- VCCV: Virtual Circuit Connectivity Verification
2.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 RFC 2119 [1]. This is the part that tells you how strict each word is, so it matters 💅
3. MPLS-TP CC, Proactive CV, and RDI Mechanism Using BFD 🌸
This section describes procedures for achieving combined CC, CV, and RDI functionality within a single MPLS-TP MEG using BFD. It adds to what's already possible for MPLS-TP LSPs with the existing specified tools and procedures ✨
3.1. Existing Capabilities 🦋
A CC-only mode may be provided with the protocols and procedures in RFC 5885 [7], using ACH channel 7. These procedures may be applied to bidirectional LSPs (through the use of the GAL) as well as PWs 🫶
Implementations may also interoperate with legacy equipment by implementing RFC 5884 [8] for LSPs and RFC 5085 [10] for PWs, on top of the procedures in this memo. Following RFC 5586 [2], when BFD control packets are encapsulated in an IP header, the fields in that IP header are set as RFC 5884 [8] defines. With IP encapsulation, CV mis-connectivity defect detection can be done by inferring a globally unique source from the combination of the source IP address and My Discriminator fields. Bestie, that's a clever trick 🧠
3.2. CC, CV, and RDI Overview 🌈
The combined CC, CV, and RDI functionality for MPLS-TP comes from multiplexing CC and CV PDUs inside a single BFD session. The CV PDUs get a Source MEP-ID TLV added so sink MEPs can detect mis-connectivity 👑
The PDUs get interleaved by using different encapsulations and code points for generic associated channel (G-ACh) encapsulated BFD, depending on whether the PDU format is CC or CV:
- CC format: defines a new code point in the Associated Channel Header (ACH) described in RFC 5586 [2]. This format supports Continuity Check and RDI functionalities.
- CV format: defines a new code point in the Associated Channel Header (ACH) described in RFC 5586 [2]. The ACH with "MPLS-TP Proactive CV" code point tells you the message is an MPLS-TP BFD proactive CV message, and the info for CV processing rides along in the form of the Source MEP-ID TLV.
RDI goes over the BFD diagnostic field in BFD CC messages. The diagnostic code field in CV messages MUST be ignored, and RDI is not its own separate PDU. Per [4], a sink MEP SHOULD encode a diagnostic code of "1 - Control Detection Time Expired" when the time since the last received BFD control packet is more than the detection time. That detection time equals the remote system's Transmit Interval multiplied by the remote system's Detect Multiplier, which is set to 3 in this document 😭
Also, a sink MEP SHOULD encode a diagnostic code of "5 - Path Down" when it receives LDI. A sink MEP MUST encode a diagnostic code of "9 - mis-connectivity defect" when CV PDU processing shows a mis-connectivity defect 🚨 And finally, a sink MEP that has started sending diagnostic code 5 SHOULD NOT switch it to 1 when the detection timer expires. Lowkey the most important rule in this whole section 💀
3.3. ACH Code Points for CC and Proactive CV ✨
okay bestie, this is where the G-ACh gets its little ID card 🪪 Figure 1 shows how the G-ACh gets encoded for the BFD CC-CV-RDI functionality 💅
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| Flags | BFD CC/CV Code Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: ACH Indication of MPLS-TP CC/CV/RDI
The first nibble (0001b) marks it as a G-ACh, going by RFC 5586 [2] 🌸
The version and the flags are both set to 0, just like [2] says 🫶
The code point is either:
BFD CC code point = 0x0022, orBFD proactive CV code point = 0x0023.
CC and CV PDUs apply to all the pertinent MPLS-TP structures, including PWs, MPLS LSPs (including SPMEs), and Sections. so many places, so much range 🦋
CC and CV operations get used at the same time on a maintenance entity (ME) inside one BFD session, which is giving multitasking energy 🧚 The expected usage is that normal operation sends CC BFD protocol data units (PDUs) interleaved with a CV BFD PDU. That CV PDU is augmented with a Source MEP-ID and identified as needing extra processing by the different ACh channel types 💜 The insertion interval for CV PDUs is one per second ⏱️ A loss of continuity defect gets detected when the time since the last received BFD control packet goes past the detection time. That detection time equals the session periodicity times the remote system's Detect Multiplier, which is set to 3 for the CC code point 😭 Mis-connectivity defects are detected in a maximum of one second. no waiting around 💀
3.4. MPLS-TP BFD CC Message Format 🎀
Here's what an MPLS-TP CC message 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| Flags | BFD CC Code point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ BFD Control Packet ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: MPLS-TP CC Message
As shown in Figure 2, the MPLS-TP CC message is the BFD control packet as defined in [4], pre-pended by the G-ACh. so the G-ACh goes first, like a hype intro 🎤
3.5. MPLS-TP BFD Proactive CV Message Format 🌈
Now the CV message, which is the main character of this section 👑 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Flags | BFD CV Code Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ BFD Control Packet ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Source MEP-ID TLV ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: MPLS-TP CV Message
As shown in Figure 3, the MPLS-TP CV message is the BFD control packet as defined in [4], pre-pended by the ACH and appended by a Source MEP-ID TLV. it's a sandwich with a tail 🥪
A Source MEP-ID TLV is encoded as a 2-octet field that specifies a Type, followed by a 2-octet Length field, followed by a variable-length Value field. A BFD session will only use one encoding of the Source ID TLV. one style per session, no mixing 🙅♀️
The length in the BFD control packet is as per [4]. The length of the Source MEP-ID TLV is not included. There are three possible Source MEP TLVs, corresponding to the MEP-IDs defined in [9]. The type fields are:
0- Section MEP-ID1- LSP MEP-ID2- PW MEP-ID
When the GAL is used, the TTL field of the GAL MUST be set to at least 1, and the GAL MUST be the end of stack label (S=1) as per [2]. this part is non-negotiable, bestie 🚫
A node MUST NOT change the value in the Source MEP-ID TLV. hands off 🙌
When digest-based authentication is used, the Source ID TLV MUST NOT be included in the digest. keep it out of the digest, no exceptions 🔐
3.5.1. Section MEP-ID 🦋
The IP-compatible MEP-ID for MPLS-TP Sections is the interface ID. Here's the format of the Section MEP-ID TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Interface Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Section MEP-ID TLV Format
Where the Type is of value 0. The Length is the length of the value fields. The MPLS-TP Global_ID, Node Identifier, and Interface Numbers are as per [9].
3.5.2. LSP MEP-ID 🌸
The fields for the LSP MEP-ID are as defined in [9]. This is applicable to both LSPs and SPMEs. It consists of the 32-bit MPLS-TP Global_ID, the 32-bit Node Identifier, followed by the 16-bit Tunnel_Num (which MUST be unique within the context of the Node Identifier), and the 16-bit LSP_NUM (which MUST be unique within the context of the Tunnel_Num). The format of the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel_Num | LSP_Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: LSP MEP-ID TLV Format
Where the type is of value 1. The length is the length of the value fields. The MPLS-TP Global_ID, Node Identifier, Tunnel_Num, and LSP_Num are as per [9].
3.5.3. PW End Point MEP-ID 💖
The fields for the MPLS-TP PW End Point MEP-ID are as defined in [9]. The format of the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | AGI Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: PW End Point MEP-ID TLV Format
Where the type is value 2. The length is the length of the following data: the Global_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. The Attachment Group Identifier (AGI) Type is as per [6], and the AGI Length is the length of the AGI value field.
3.6. BFD Session in MPLS-TP Terminology 🧠
A BFD session corresponds to a CC and proactive CV OAM instance in MPLS-TP terminology. A BFD session is enabled when the CC and proactive CV functionality are enabled on a configured Maintenance Entity (ME).
When the CC and proactive CV functionality are disabled on an ME, the BFD session transitions to the ADMIN DOWN state, and the BFD session ends. bye bye session 👋
A new BFD session is initiated when the operator enables or re-enables the CC and CV functionality. fresh start, new era ✨
All BFD state changes and P/F exchanges MUST be done using CC packets. P/F and session state information in CV packets MUST be ignored. CV packets are the sidekick here, so they don't get a vote on state 🙈
3.7. BFD Profile for MPLS-TP ✨
okay so BFD runs in asynchronous mode 🦋 and every session in a given MEG uses the encapsulation from Section 3 💅. For LSPs, SPMEs, and Sections, that's GAL/G-ACh-encapsulated BFD with the code points from Section 3.3. For PWs, it can be G-ACh or GAL/G-ACh-encapsulated BFD, same code points from Section 3.3 🌸. The BFD control packets get sent periodically at a configurable rate. That rate is one fixed value shared by both directions of the MEG for its whole lifetime 🫶.
This spec is all about bidirectional BFD for P2P transport LSPs, so all BFD packets MUST be sent with the M bit clear 🎀.
Bidirectional LSPs have two modes. In one, the session state of both directions is coordinated. In the other, the BFD sessions are set up so the two directions run independently but still belong to the same MEG 💜. A single bidirectional BFD session handles coordinated operation, and two independent BFD sessions handle independent operation. Heads up, independent operation treats session state and defect state as separate things 👀. So an independent session can be in the UP state while it's receiving RDI, which is wild but totally valid ✨. In a coordinated session, the session state follows the defect state.
In coordinated mode, an implementation SHOULD NOT reset bfd.RemoteDiscr until it is exiting the DOWN state 🙈.
In independent mode, an implementation MUST NOT reset bfd.RemoteDiscr when it transitions to the DOWN state 🔥.
Overall operation follows RFC 5880 [4], which RFC 5884 [8] extends for MPLS. Coordinated operation is just what's described in [4]. Independent operation needs two things clarified in [4] 🧚. Independent operation is marked by setting bfd.MinRxInterval to zero on the MEP that's usually the session originator (called the source MEP). There will be a session originator at each end of the bidirectional LSP. Every source MEP has a matching sink MEP that's configured with a transmission interval of zero 💖.
This memo lays out the preferred way to read the base spec for how a MEP behaves when its BFD transmit rate is set to zero. One reading is that the MEP doesn't originate any periodic messages on the reverse component of the bidirectional LSP. It only originates messages when its state changes 😌.
The first clarification: when a state change happens, a MEP set to a transmit rate of zero sends BFD control messages with a one-second period on the reverse component. It keeps doing that until the peer confirms the state change. After that, the MEP can go back to being quiet. This makes all state transitions in the RxInterval=0 case more robust 💪.
The second clarification: the originating MEP (the one with a non-zero bfd.TxInterval) ignores a DOWN state it gets from a zero-interval peer 🙃. So the zero-interval peer keeps sending DOWN state messages that carry the RDI diagnostic code, because the state change never gets confirmed. This makes RDI exchange more robust when a failure is unidirectional. It covers both session types, whether the DOWN has a diagnostic of control detection time expired or neighbor signaled session down with RDI support 🌈.
There's one more extension to the base spec: some extra OAM protocol exchanges feed into the BFD state machine. These are the Link Down Indication [5], the Lock Instruct/Lock Report transactions, and the Lock Report interaction, which is optional ⭐.
3.7.1. Session Initiation and Modification
Session initiation starts from MinRx = 1 second, MinTx >= 1 second, and detect multiplier = 3 🍓.
Once the session is in the UP state, Poll/Final discipline is used to change how often control messages get exchanged, moving them from the default rates to the ones we want. It also sets the detect multiplier to 3 💅.
Quick note on Poll/Final: a receiver that gets a new timer value with the poll flag can reject it by tearing down the session, or it can send back its preferred timer value with the final flag 👀. And a receiver that gets a new timer value with the final flag can reject it by tearing down the session, or send back its preferred timer value with the poll flag 🔄.
Once the desired rate has been reached through the Poll/Final mechanism, implementations SHOULD NOT try to modify the rate again 🙅♀️.
Now, in the rare case where an operator has a real reason to change session parameters again after the initial move away from the defaults, Poll/Final discipline can be used. Just know that the peer might decide the session change is unacceptable, and/or bring the BFD session down with the ADMIN DOWN state 😬.
3.7.2. Defect Entry Criteria
There are extra defect criteria on top of the ones defined in [4], because mis-connectivity defects are a real possibility 🕵️♀️. So an LSP direction moving from the defect-free state into a defect state has criteria that are a superset of the BFD base spec [4]'s. Bestie, that's a lot of criteria, so let's go one by one 🧠.
These conditions make a MEP enter the defect state for CC PDUs (no particular order):
- BFD session times out (loss of continuity defect).
- Receipt of a Link Down Indication or Lock Report.
These will make the MEP enter the mis-connectivity defect state for CV operation (again, no particular order):
- BFD control packets arrive with an unexpected encapsulation (mis-connectivity defect). That includes:
- receiving an IP encoded CC or CV BFD control packet on an LSP that's configured to use GAL/G-ACh, or
- the other way around (Heads up, there are other things that can also look like an OAM packet 👻.)
- Receipt of an unexpected globally unique Source MEP identifier (mis-connectivity defect). Each encoding of the Source MEP-ID TLV holds unique info, and you can't mechanically translate between MEP-ID formats 🙅♀️. So getting an unexpected Source MEP-ID type counts the same as getting an unexpected value 💀.
- Receipt of a session discriminator that isn't in the local BFD database, in the Your Discriminator field (mis-connectivity defect) 🙈.
- Receipt of a session discriminator that is in the local database but doesn't have the expected label (mis-connectivity defect) 🏷️.
- If BFD authentication is used, receipt of a message with incorrect authentication information (password, MD5 digest, or SHA1 hash) 🔐.
The effective defect hierarchy, which is the order the checks happen in, goes like this 🪜:
- Receiving nothing.
- Receiving a Link Down Indication, e.g., a local link failure, an MPLS-TP LDI, or Lock Report.
- Receiving from an incorrect source (figured out by whatever means).
- Receiving from a correct source (as near as can be determined), but with incorrect session information.
- Receiving BFD control packets that are correct in every discernable way ✨.
3.7.3. Defect Entry Consequent Action
When a defect gets entered, a sink MEP asserts signal fail into any client (sub-)layers 🚨. It also tells its session peer that the session is DOWN, using CC messages 📣.
Blocking traffic as a consequent action MUST be driven only by a defect's consequent action as specified in Section 5.1.1.2 of RFC 6371 [13]. No freelancing, bestie 🙅♀️.
When the defect is mis-connectivity, the Section, LSP, or PW termination silently discards all non-OAM traffic it receives 🤫. The sink MEP also sends a defect indication back to the source MEP using the mis-connectivity defect diagnostic code (9) 💌.
3.7.4. Defect Exit Criteria
3.7.4.1. Exit from a Loss of Continuity Defect
For a coordinated session, exiting a loss of connectivity defect works the way Figure 7 shows, and that updates RFC 5880 [4] 📈.
For an independent session, exiting a loss of connectivity defect happens when the MEP receives a well-formed BFD control packet from its peer MEP, as shown in Figures 8 and 9 🦋.
3.7.4.2. Exit from a Mis-Connectivity Defect
Exiting a mis-connectivity defect state happens when no CV messages with mis-connectivity defects have been received for a period of 3.5 seconds ⏳. That's the glow-up arc, periodt 🌸✨.
3.7.5. State Machines ✨
okay bestie, these state machines are an update to RFC 5880 [4] 💅 They got extra inputs, LDI and LKR from [5], and the independent mode behaviour got clarified too. LKR is an optional input, so you don't have to wire it up 🦋
The coordinated session state machine now takes LDI and optionally LKR as inputs. If a session is in the UP state, receiving LDI (or optionally LKR) knocks it down into the DOWN state 💀
+--+
| | UP, ADMIN DOWN, TIMER, LDI, LKR
| V
DOWN +------+ INIT
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | MIS-CONNECTIVITY,| |
| | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| |
| |TIMER TIMER,| |
V |LDI,LKR LDI,LKR | V
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+
+------+ +------+
Figure 7: MPLS CC State Machine for Coordinated Session OperationFor independent mode there are two state machines 🌸 One is for the source MEP (the one that requested bfd.MinRxInterval=0), and the other is for the sink MEP (the one that agreed to bfd.MinRxInterval=0). Main character energy, two roles, one vibe.
The source MEP won't leave the UP state once it's initialized, unless someone forces an ADMIN DOWN 🙈 So LDI and optionally LKR never kick it out of UP, but they still do their thing in the INIT and DOWN states.
+--+
| | UP, ADMIN DOWN, TIMER, LDI, LKR
| V
DOWN +------+ INIT
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | | |
| |ADMIN DOWN ADMIN DOWN | |
| |TIMER, | |
| |LDI, | |
V |LKR | V
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN,
+--->| | INIT, UP | |<---+ LDI, LKR
+------+ +------+
Figure 8: MPLS CC State Machine for Source MEP for
Independent Session OperationThe sink MEP state machine (the one whose transmit interval is set to zero) gets two tweaks 🎀
- It's allowed to go straight from DOWN to UP once the session is initialized. The source MEP never leaves UP (except through ADMIN DOWN), so during normal one-way fault scenarios it never drops back to INIT. 🫶
+--+
| | ADMIN DOWN, TIMER, LDI, LKR
| V
DOWN +------+ INIT, UP
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | MIS-CONNECTIVITY,| |
| | ADMIN DOWN,| |
| |ADMIN DOWN, TIMER, | |
| |TIMER, DOWN, | |
| |LDI, LDI, | V
V |LKR LKR | |
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+
+------+ +------+
Figure 9: MPLS CC State Machine for the Sink MEP
for Independent Session Operation3.7.6. Configuration of MPLS-TP BFD Sessions 🧚
Configuring the MPLS-TP BFD session parameters, and getting the source and sink MEPs to agree on them, is out of scope for this memo. Not our problem today, bestie 💜
3.7.7. Discriminator Values 🔑
In the BFD control packet, the discriminator values are either local to the sink MEP, or they mean nothing (when they aren't known).
The My Discriminator field MUST be set to a non-zero value, and that value can be a fixed one 🍓 The Your Discriminator value that gets transmitted MUST reflect back the value of My Discriminator that was received, or be set to zero if that value isn't known.
Per Section 7 of RFC 5884 [8], a node MUST NOT change the My Discriminator value for an established BFD session. Hard rule, no exceptions, periodt 💅
4. Configuration Considerations 🎀
Here's an example set of configuration parameters for a BFD session:
Mode and Encapsulation
----------------------
RFC 5884 - BFD CC in UDP/IP/LSP
RFC 5885 - BFD CC in G-ACh
RFC 5085 - UDP/IP in G-ACh
MPLS-TP - CC/CV in GAL/G-ACh or G-AChFor MPLS-TP, these extra parameters need to be configured:
- Session mode, coordinated or independent
- CC periodicity
- The MEP-ID for the MEPs at either end of the LSP
- Whether authentication is enabled (and if so, the associated parameters)
The discriminators each MEP uses, bfd.LocalDiscr and bfd.RemoteDiscr, can optionally be configured or assigned locally. And a detect multiplier of 3 is directly inferred from the code points 🔥
5. IANA Considerations 🌈
IANA has allocated two channel types from the "Pseudowire Associated Channel Types" registry in RFC 4385 [15] ✨
0x0022 MPLS-TP CC message
0x0023 MPLS-TP CV messageIANA has also created a "CC/CV MEP-ID TLV" registry. Its parent registry is the "Pseudowire Associated Channel Types" registry of RFC 4385 [15]. Every code point in this registry shall be allocated according to the "Standards Action" procedures as specified in [11]. The items tracked in the registry will be the type, associated name, and reference.
The initial values are:
0 - Section MEP-ID
1 - LSP MEP-ID
2 - PW MEP-IDIANA has also assigned this code point from the "Bidirectional Forwarding Detection (BFD) Parameters" registry, "BFD Diagnostic Codes" subregistry [4]:
9 - mis-connectivity defect6. Security Considerations 💀
Okay, this section is serious, bestie. CV is what keeps network integrity intact by making sure traffic isn't "leaking" between LSPs 😭
Base BFD has an optional authentication section (see Section 6.7 of [4]) that can be applied to this application. The Source MEP-ID TLV isn't included in the BFD authentication digest, but there's a chain of trust: the discriminator tied to the digest is also tied to the expected MEP-ID. That's what stops anyone from impersonating CV messages in this application 🛡️
This memo specifies globally unique identifiers for MEP-IDs. That gives us absolutely authoritative detection of persistent leaking of traffic between LSPs. If the IDs aren't unique, leaking can go undetected when two LSPs with the same MEP-IDs get misconnected. That would be undesirable but rare. It would also be really hard to exploit for bad purposes, because at a minimum, both a network end point and a node that was a transit point for the target MEG would need to be compromised 🧚♀️
7. References 📚
7.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
- [3] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
- [4] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
- [5] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed., Boutros, S., and D. Ward, "MPLS Fault Management Operations, Administration, and Maintenance (OAM)", RFC 6427, November 2011.
- [6] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
- [7] Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010.
- [8] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
- [9] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
- [10] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
- [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
7.2. Informative References
- [12] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
- [13] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
- [14] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011.
- [15] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
8. Acknowledgments 🫶
Nitin Bahadur, Rahul Aggarwal, Tom Nadeau, Nurit Sprecher, and Yaacov Weingarten also contributed to this document. Thank you, legends 👑
9. Contributing Authors 💖
Annamaria Fulignoli
Ericsson
EMail: annamaria.fulignoli@ericsson.com
Sami Boutros
Cisco Systems, Inc.
EMail: sboutros@cisco.com
Martin Vigoureux
Alcatel-Lucent
EMail: martin.vigoureux@alcatel-lucent.com
Siva Sivabalan
Cisco Systems, Inc.
EMail: msiva@cisco.com
David Ward
Juniper
EMail: dward@juniper.net
Robert Rennison
ECI Telecom
EMail: robert.rennison@ecitele.comEditors' Addresses 🦋
Dave Allan
Ericsson
EMail: david.i.allan@ericsson.com
George Swallow
Cisco Systems, Inc.
EMail: swallow@cisco.com
John Drake
Juniper
EMail: jdrake@juniper.net📦 where this page comes from
- ietf: rfc6428 2011-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms